git - 我如何知道在没有 merge 来自第二个父项的更改的两个父项的 Git 提交中发生了什么？

Question

在 Gitk 中，我可以看到团队成员的提交 (X) 有两个父项，第一个父项是他自己之前的提交 (A)，另一个父项包含许多其他人的提交(1 到 5)。在他 merge 之后，其他人(1 到 5 和其他人)所做的所有更改都不再存在于 X、B、C 等...

A------------
              \
               X - B - C 
              /
1--2--3--4--5
           /
e--r--j--k
     /
l--m

如果我将提交 X 与提交 A 进行比较，它不会显示任何差异，如果我将提交 X 与提交 5 进行比较，它会显示所有缺失的更改。此外，在提交 X、B 或 C 时，git log 不会显示提交 1 到 5 中对文件所做的更改。但是，如果我执行 git log --full-history，那么历史记录会显示在 1 中所做的更改到 5，但这些更改仍未出现在实际文件中，并且历史记录未显示它们正在撤消。所以 git log --full-history 似乎与当前文件内容相矛盾。

我与提交 X 的用户进行了交谈。他说他没有进行重置或 rebase ，并且他说他在相关时间内没有还原任何提交。然而，他说他有时会做一个 pull origin master，导致其他人的更改被放入他的索引或工作树中，就好像他做了这些更改，而不是这些更改的实际作者。他说，当发生这种情况时，他做了一个新的克隆，并且没有将任何内容从本地存储库推送到 master，因为他认为 Git 做错了什么。

这两件事是否相关(错误的 pull 和错误的 merge )？

我怎样才能准确地说出发生了什么，以便我们将来可以避免这种情况？

是什么原因导致 Git 有时将从 origin master pull 的更改放置在本地工作目录或索引中，就好像它们是本地更改一样？

Answer 1

However, he says that he does sometimes do a pull origin master that results in everyone else's changes getting put in his index or working tree as if he had made those changes and not the actual authors of those changes.

听起来他遇到了 merge 冲突，但不明白它们是什么。这是一个极其常见的问题，不幸的是，我们不知道避免它的好方法(例如，切换回 SVN 并不能避免它)。

这到底是怎么发生的？

让我们称呼您的开发人员 Alice 和 Bob。 Alice 提交了 1-5，Bob 提交了 A 和 X。这是一个似是而非的历史。

1. Bob 提交 A。

2. Alice 提交 1-5，并将它们推送到中央存储库。

3. Bob 尝试推送 A，但无法推送，因为他的存储库已过时。

   $ git push
    ! [rejected]        master -> master (non-fast-forward)
   

4. Bob 然后他按照您告诉他的去做:他先 pull 。但是，他遇到了 merge 冲突，因为提交 A 和提交 1-5 触及了一些相同的代码。

   $ git pull
   Auto-merging file.txt
   CONFLICT (content): Merge conflict in file.txt
   Automatic merge failed; fix conflicts and then commit the result.
   

5. Bob 在他的工作目录中看到其他人所做的更改，但不明白为什么会出现这些更改。

   $ git status
       both modified:   file.txt
   

6. 他认为 Git 做错了什么，而实际上，Git 要求他解决 merge 冲突。他尝试 checkout 新副本，但出现错误:

   $ git checkout HEAD file.txt  
   error: path 'file.txt' is unmerged
   

7. 因为它不起作用，他尝试 -f:

   $ git checkout -f HEAD file.txt
   warning: path 'file.txt' is unmerged
   

8. 成功!他 promise 并 push 。

   $ git commit
   $ git push
   

变难的部分

有很多 git 工具。严重地。 Visual Studio 和 Xcode 都集成了 Git，还有其他几个 GUI，甚至还有多个命令行客户端。人们在描述他们如何使用 Git 的方式上也很草率，而且大多数开发人员对 Git 在“pull 提交推”工作流程之外的工作方式不太满意。

不久前有一篇关于这个主题的优秀论文(我很难找到它)。一些结论是(原谅我的内存):

• 除了一些非常简单的命令(提交、推送)之外，大多数开发人员并不真正了解如何使用源代码控制。

• 当源代码控制未按开发人员预期的方式运行时，他们会采取一些策略，例如复制粘贴一些他们不太了解的命令来“修复问题”，添加 -f 标记，或删除存储库并使用干净的副本重新开始。

• 在开发团队中，通常情况下只有首席开发人员才真正知道存储库中发生了什么。

所以这确实是一个教育挑战。

我认为 Bob 需要学习的关键教训是 git pull 实际上只是 git fetch 和 git merge，而且您可能会遇到 merge 冲突，并且在解决 merge 时需要以非常认真和有目的的方式行事。即使没有报告冲突，这也适用......但现在让 Bob 不要太过担心!

这里的另一个重要教训是，首席开发人员需要花时间确保团队中的每个人都能正确使用源代码控制，并了解 pull 、推送、分支和 merge 之间的关系。这是午餐时间讲座的绝佳机会:整理一些幻灯片，买披萨，并讨论 Git 的工作原理。