git令人困惑的圖表。 master分支似乎有兩行？

Question

在運行git log時，我看到了奇怪的圖形。 我將進一步解釋。 以下是帶有圖形的git log的輸出。

$ git log --graph  --oneline
*   df1834d (HEAD -> master, tag: r-0.1, origin/master) Merge branch 'master' of https://github.com/samshers/graphql-hibernate
|\
| * d56a675 fixed country null issue
* | ee9bb70 fixed country null issue
|/
* 2617f2a hibernate cascade error issue. country field in state table set to null

如您所見，master本身具有兩個獨立的分支。 為了進一步確認這一點，我跑了

$ git branch --contains ee9bb706c8fcc329fac4acf69ad6b684f1069170
  joincolumn_issue
  ls
  mappedBy
* master

接着

$ git branch --contains d56a6751771b1f62d9ceb0bcce9a2391c004ee44
  joincolumn_issue
  ls
  mappedBy
* master

顯然，這兩個提交都存在於master上-那么為什么會有兩個圖。 我怎么知道更改是否兩個提交都存在於master上。 或者，如果只有其中之一的更改實際上存在於主服務器上，那么兩者中的哪一個呢？

編輯-根據RY和Mark的回復 （如果顏色代碼還具有其他含義，請也進行提示。）
因此，我將進一步嘗試理解為什么提交（Y）不基於先前的提交（X）（如果X在Y之前提交）。 git日志顯示d56a675和ee9bb70都同時提交。

commit ee9bb706c8fcc329fac4acf69ad6b684f1069170
Author: itsvamshers <itsvamshers@gmail.com>
Date:   Mon Sep 9 17:24:01 2019 +0530

    fixed country null issue

commit d56a6751771b1f62d9ceb0bcce9a2391c004ee44
Author: itsvamshers <itsvamshers@gmail.com>
Date:   Mon Sep 9 17:24:01 2019 +0530

    fixed country null issue

但是，進一步挖掘幾乎看不到任何區別。

$ git show -s --format="%ct" d56a6751771b1f62d9ceb0bcce9a2391c004ee44
1568030041

和

$  git show -s --format="%ct"  ee9bb706c8fcc329fac4acf69ad6b684f1069170
1568031643

並且此信息應足以使git正確地提交提交。 但是，如果不是這樣，那么我想它會更聰明，並且出於某種原因而做，只是試圖了解原因和原因。

Answer 1

d56a675在ee9bb70的歷史中不存在，並且ee9bb70在d56a675的歷史中不存在。 兩者都存在於master的歷史中，因為它們在df1834d中重新合並在一起。 所有這些就是為什么圖形中包含叉子的原因。

它們的兩個更改都存在於master的歷史中，但這並不意味着合並提交會按您想要的方式保存這些更改。 您必須查看當前狀態並進行比較。

git show d56a675
git show ee9bb70
git diff 2617f2a..df1834d

另外，如果兩個提交相同或一個是另一個的較新版本（其摘要表明），則將它們合並可能是一個錯誤。

Answer 2

聽起來好像是關於分支是什么，以及分支將“提交”包含在git中意味着什么的困惑。

分支只是指向提交的指針。 分支不是 git中的提交的集合，就像在某些工具中一樣。 git與“包含或不包含”提交的分支最接近的事情是，該分支“可到達”或“不可到達”的提交。 分支指向的提交是可到達的，通過遵循可達的提交的父指針（遞歸）找到的任何提交也是如此。

合並是具有兩個（或更多）父指針的提交。 因此，當您將一個分支合並到master ，該分支的所有提交都可以從master到達（通過合並提交的第二個父指針）。 因此，分支提交被“包含”在master中（即可從master到達），因為您已將它們合並到master中。 這是正常的git行為。

如果您只想知道在提交時處於“主”狀態的提交……好吧，git並不會真正跟蹤類似的事情，但是您可以

git log --graph --one-line --first-parent

現在，如果您做不同尋常的事情（例如，將master合並到分支中，然后將master快速轉發到結果合並中，僅作為一個示例），那么這仍然可能無法達到您的預期； 但是，如果您遵循合理的正常分支/合並策略（並堅持使用“瓷器”命令-供最終用戶使用的命令），則它應該看起來更像您期望的那樣。

默認情況下，合並到兩個分支之后的log的這種行為是--graph選項對IMO有用的主要原因。

無論如何，示例圖中顯示的所有提交所做的更改都顯示在master中，因為這些更改均顯示為可從master到達。 有一個陷阱-假設合並提交是兩個分支的合理合並。 如果您使用ours合並策略進行合並，則該分支不存在。 如果您對沖突解決所做的事情確實很怪異，但撤消了分支中的某些更改，那么您就有了有時稱為“邪惡合並”的內容，並且不存在未更改的更改。 如果您知道團隊中沒有人這樣做，那么您就不必擔心。

您可以依靠git log的歷史記錄簡化來告訴您分支在合並中是否被完全破壞（除非您提供--full-history類的選項，否則不應顯示該分支，因為log會決定它可以完全解釋當前狀態而未提及分支），但這可能不是100％可靠的，並且在任何情況下， log的邏輯都無法告訴您是否有惡意合並-因此在某些時候，您必須依靠這樣的想法：您和您的團隊遵循合理的流程。

或良好的工具和測試覆蓋范圍； 您也可以依靠它。