如何理解交叉Git日志？

Question

有人能告诉我0ab11dd和bd7278a之间发生了什么吗？也在27ac7b7和95b2c48之间？为什么在这些提交中存在交叉？

* xxxxxxx (HEAD -> f-1, origin/f-1) 
* xxxxxxx fix merge conflicts
*   13751d5 Merge branch 'master' into feature/DP-1
|\  
| *   f3efc9d (origin/master, origin/HEAD, master) Merge pull request #9 from fix
| |\  
| | * 83c0b15 (origin/fix) 
| |/  
| *   be24ce6 Merge pull request 
| |\  
| | *   0ab11dd merge
| | |\  
| | |/  
| |/|   
| * |   bd7278a Merge pull request 
| |\ \  
| | * | 14399e2 
| | | * xxxxxxx  
| | | * xxxxxxx 
| | | *   27ac7b7 merge
| | | |\  
| | |_|/  
| |/| |   
| | | * 95b2c48 (origin/f-3) 
| | | * xxxxxxx 

尤其是这个

| | |_|/  
| |/| |   

为什么有一个出分支但没有提交？

Answer 1

关于“交叉词”

这正是图形工具表示合并的方式:从右到左(左边的那个是“接收”合并的那个)。因此，当一个提交系列(而不是这里可能令人困惑的分支)必须合并到另一个当前以图形形式表示在其右侧的分支时，该工具就会绘制一条线，是的，它将与其他行交叉，从而使其从右侧连接到合并提交。

，所以这只是一个图形约定.

关于垂直行的(注释后)

分支(可选的，带有--装饰)添加到他们当前指向的提交图中，但不要忘记，您的回购树实际上并不需要它们中的任何一个。这些提交系列是你的树的主体，在那里“树枝”实际上只是提示，这就是隐喻被分解的地方……

(我承认这是一种非常低技术的代表，...but也承认，信息丰富的提交消息会使事情变得更加清晰。)

Answer 2

这将是一个评论，但没有空间，它需要格式化。

这一节的内容如下：

| | | *   27ac7b7 merge
| | | |\  
| | |_|/  
| |/| |   
| | | * 95b2c48 (origin/f-3) 
| | | * xxxxxxx 

不完整。如果您继续浏览该图表，它最终可能会像这样自行解决：

| | | * xxxxxxx 
| | |/
| | * yyyyyyy
| |/
| * zzzzzzz
|/
* sssssss

(但我们真的猜不出来，而且可能比这复杂得多)。

有了足够多的附加图表，我们可以更多地介绍提交27ac7b7。目前，我们只知道这是一个合并，有两个父级，第一个父级是95b2c48 (标记为origin/f-3)。我们在这里不能看到第二个父提交的散列ID，但是在图行之后，您最终会到达第二个父节点。

(您询问的第一次提交-0ab11dd-is是与父母xxxxxxx合并提交的结果，这是遵循对该提交的直接下行线的结果，并提交bd7278a，这是遵循最初向右下降的行的结果，然后立即反转并向下传递到bd7278a。git log --graph强调亲子关系的第一/第一关系，把非第一的关系拉向右边。有些图形绘制方法，包括我通常使用的方法，根本就没有区别。什么时候以及这种区别是否有用是另一个主题，但请参见git log的git log选项。)