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

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 选择了前者。