Git Merge分支'master'的https://bitbucket.org/xxx/yyy

Question

我们在使用SVN多年后开始使用git，有时，我必须承认，这是令人困惑的。采取以下示例 -

• User1对a.java进行更改并推送到远程服务器。
• User2对b.java进行了更改。他无法直接推开（偏离SVN，但这没关系）。他需要先从远程服务器拔出，然后将他的更改推送到远程服务器。这将显示为单独的合并提交，并在here on stackoverflow itself
中得到了精美的解释
• 现在是有趣的部分。如果我们将其推断为多个文件，则可能与User2更改的文件之一发生冲突。这次，git无法进行自动提交。 User2必须解决冲突，然后提交此合并。

这是令人困惑的，因为没有对这么多文件进行更改的用户会对作为此合并提交的一部分提交它们持怀疑态度（特别是对于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选择了前者。