https://bitbucket.org/xxx/yyy Git合并分支'主'

Question

我们在使用SVN好几年后有时候会混淆，我必须承认，这很混乱。以下面的示例 -

• User1对a.java进行更改并将其推送到远程服务器。
• User2对b.java进行了更改。他不能马上推（SVN的偏差，但没关系）。他需要先从远程服务器拉出，然后将其更改推送到远程服务器。这将显示为单独的合并提交，并在here on stackoverflow itself
• 中得到了很好的解释。现在是有趣的部分。如果我们推断这是多个文件，那么与User2更改的其中一个可能会发生冲突。这一次，git无法进行自动提交。用户2将不得不解决冲突，然后提交此合并。

这令人困惑，因为没有对这么多文件进行更改的用户会对将它们作为此合并提交（特别是SVN背景）的一部分进行提交持怀疑态度。如果此用户现在只提交他解决冲突并推送到远程的文件，Git将停止提供他未推送的最新版本的文件。这带来了我在团队其他人中失去了工作的感觉。

这段漫长的故事后，我的问题是，为什么它这样做？为什么GIT不应该保留其他文件的最新版本？作为自动合并的一部分，git是否应该知道用户没有提交所有带给用户机器的文件？有没有可以避免犯这个错误的机制？

Answer 1

首先，让我澄清一下，git pull不会在本地提交未触及的文件中导致合并冲突。所以用户只需要处理他实际上碰到的文件。

如果这些合并提交对您来说是个问题，您应该考虑切换您的工作流程。与git进行交互的方式并未陷入困境，并且已建立的工作流程存在很大差异。例如，PostgreSQL project完全没有任何合并提交与git一起工作。另一方面，有一个workflow that uses merge commits in a meaningful way。要获得类似于SVN工作流的行为，请将--rebase传递给git pull，但在此之前，请仔细阅读man git-rebase以了解其含义。或者，您可以在提交前使用git stash来提取远程更改，但这些选项中的任何一个都只是将冲突解决步骤置于不同的位置。

要检查您的最后一个问题：Git将工作树视为您项目的快照。如果它将较新的文件与较旧的文件混合在一起，则不同的文件将具有不同的版本，这对git来说是陌生的。如果你想要这样的功能，你需要寻找CVS（没有玩笑）。这里有一个权衡：任何版本控制系统都必须做出能够跟踪文件移动或能够跟踪不同版本的不同文件的决定。 Git选择了前者。