问使用git时，为什么不将提交合并到特性分支之后出现在历史记录中？

EN

对于没有任何冲突的提交，它们不应该出现在功能分支的历史记录中吗？在合并之后，特性分支历史记录中没有对主分支上完成的任何工作进行任何操作。

在您的问题中，您将讨论提交时发生的合并冲突。

在合并中，有许多其他提交没有任何冲突的文件。

Git不合并提交，它合并内容。对我来说，这表明你对Git的工作方式有一个误解( Git并不能消除这些错误，所以不用担心)。让我们在合并前勾勒出你的存储库是什么样子.

A - B - C - D - E - F [master]
         \
          1 - 2 - 3 [feature]

你有一个主分支来提交A，B，C.然后在C上有一个特性分支，提交1、2和3。您可以在git log --graph --decorate --all中看到这一点，也可以使用图形工具，如gitk或吉特-德夫

您希望将从master到feature的更改合并。Git通过接收主和特性的内容并创建一个将两者结合在一起的新提交来进行合并。

A - B - C - D - E - F [master]
         \           \
          1 - 2 - 3 - F3 [feature]

如何进行合并是另一个问题。。重要的是要实现的是Git合并了F的内容和3的内容。

从图中可以看出，特征和主人并不是交织在一起的。特写的历史与大师的历史是截然不同的。当你合并的时候，树枝不会消失。如果你继续致力于特写和掌握，他们会再次分歧。

A - B - C - D - E - F - G - H [master]
         \           \
          1 - 2 - 3 - F3 - 4 - 5 [feature]

这就是为什么主人的历史似乎没有出现在feature中，但现在F3的父母都是F和3。

再次说明没有任何冲突的提交，为什么在特性分支上运行git状态时这些文件会显示为被更改？

如前所述，当Git进行合并时，它将创建一个新提交，其中包含两个分支中的组合更改。这是一种正常的提交，就像任何其他的提交一样，除非它有多个父级。如果有冲突，吉特需要一个人来解决它。你只剩下吉特的未完成的工作了。任何Git能够成功合并的文件都将被更改和分阶段(添加)。任何有冲突的东西都会被改变(用冲突标记)，而不分阶段。这取决于您编辑冲突的文件，添加它们和提交。和正常的过程一样。

我认为关于Git的基本概念是：

在Git中，每个提交都表示特定时间点的整个目录树的快照。

当您发出像git show <commitref>这样的命令时，Git是将工作树的当前状态与工作树在完成提交时的状态进行比较，并向您显示净差异。

现在，当您合并两个分支时，比如A和B，您实际上是在合并目录树的快照，就像在分支A和分支B中进行最新提交时的快照一样，在本例中，是C3和C5。

C1 - C2 - C3 <-- A
      \       
       C4 - C5 <-- B

结果的合并提交表示C3和C5引用的目录树的两个快照的总和。换句话说，C5中的快照放在C3之上，生成一个名为C5'或"C5素数“的新快照。合并快照是特殊的，因为它有两个父级而不是一个。

C1 - C2 - C3 - C5' <-- A
      \       /
       C4 - C5 <-- B

如果两个快照都包含相同文件中相同行的不同版本，则会出现冲突。在这种情况下，您必须决定这些行在合并快照中的样子。

请记住，因为每个提交都是表示目录树之前经历的累积转换的快照，因此合并提交只是一个新快照，而不是快照序列。

这就是为什么您没有看到从您的主要分支提交到您的特性分支的列表。相反，您将得到一个合并提交，它表示在两个分支中对您的文件发生的转换的总和。为了使您能够通过这些早期的转换向后跟踪，合并提交包含对最新提交的引用，并将其相加在一起。