为什么Git在没有冲突的情况下无法在服务器端合并

Question

我已经在精简模式下使用 Git 很长时间了：分支、拉-提交-推、合并。主要是使用 SourceTree。这对于发展来说已经足够了。所以我是业余爱好者）

但现在我有了一个由 ArgoCD 监视的存储库，它从不同的 Gitlab 管道获取推送。 99.9% 的推送都会发送到他们自己的文件夹。说实话我从来没有注意到冲突。但随着管道数量的增加，我们会更频繁地遇到：

错误：无法将一些引用推送到“...”
更新被拒绝，因为当前分支的尖端位于其远程对应分支的后面。 > 在再次推送之前集成远程更改（例如“git pull ...”）。

所以问题是：为什么 Git 甚至不尝试将更改合并到远程分支，只有在存在真正的冲突时才会抛出此类错误？因为您所要做的就是拉取更改，它们不需要任何解决，然后重复推送。

Git 已有近 20 年历史，被认为是最先进的 VCS，所以我对这种行为感到惊讶。或者也许我搜索得不够彻底，除了残酷的力量之外还有其他东西可以处理这种情况？

Answer 1

我能想到原因。

1. Git 服务器被设计得“愚蠢”。
2. 您不知道自己刚刚分享了什么。

愚蠢的服务器

通过保持基本的 Git 推/拉协议简单，就不需要专用的 Git 服务器。 Git 可以使用许多不同的协议，包括本地文件，或者只需进行最少更改的 HTTP 服务器。有关更多信息，请参阅 Pro Git 的协议章节。

你可以为每个人打破主分支而不自知

确保主分支正常工作很重要。这样，每个人都可以在稳定的基础上工作。如果损坏的代码合并到主代码和共享代码中，那么现在项目中的其他人可能都在使用损坏的代码。

合并会导致新的提交和代码更改。如果合并是由服务器上的

git push

完成的，那么您不知道您刚刚共享了什么。没有冲突，但是有效吗？谁知道？您可能刚刚破坏了每个人的主分支。

所有工作都应在共享之前进行测试，以避免共享损坏的工作。这就是为什么工作是在分支中完成的，以便在合并之前可以在 CI 上安全地推送和测试它们。理想情况下，您将 main 合并到您的分支中，测试它，然后合并回 main。