下面的截圖取自SourceTree。我創建了一個簡單的git倉庫，其中包含一些提交。對於每一次提交，評論說明我進行提交時我在哪個分支上。爲什麼git分支圖不能正確地跟蹤分支？
正如你所看到的，樹圖是（可以說）次優的，該提交掌握都不盡相同的顏色，也不是在一個單一的車道。爲什麼是這樣？
（由GitHub上和到位桶得出的樹形圖看起來類似的問題受苦，所以它不只是SourceTree。）
顯然它沒有多大關係在這個簡單的例子，但在我的一些項目，我們使用git-flow的變體，並且在查看樹圖時通常很難跟蹤每個git-flow「泳道」。部分原因是因爲樹形圖不會隨着時間的推移保持每個泳道的顏色相同。
我懷疑是樹圖是（可以說）不理想的，因爲git的回購實際上並不包含足夠的信息來繪製樹圖我想要的方式。特別是，當兩個提交是一個普通提交（例如，當你分支）的子代時，git不知道父提交是否與子1或子2「在同一分支上」。或者換句話說，它不會不知道哪個小孩是樹枝，哪個小孩是樹幹的延續。我有這個權利嗎？
至於其他的答案也提到，這簡直混帳的性質：一個Git承諾不包含用戶是在何時作出的承諾哪一個分支的任何信息。 （這些信息不能從git確實維護的信息中可靠地推斷出來，這當然包括DAG。）這是git作者設計的選擇。 Mercurial相比之下，確實存儲每個提交的分支名稱。 Git的倡導者認爲這是一件壞事，因爲它不鼓勵創建可能臨時的分支來嘗試解決問題，而且分支名稱之間的衝突很容易出現。例如，參見The Differences Between Mercurial and Git。
Mercurial支持者認爲，將分支名稱與每次提交一起存儲是一件好事，因爲它可以更容易地維護可解釋的歷史記錄。 Mercurial存儲分支名稱，每個提交似乎是Why I Like Mercurial More Than Git的作者更喜歡Mercurial而不是Git的主要原因。
如果使用Mercurial的命名分支，Mercurial將在每次提交中存儲分支名稱。或者，如果想要類似git的行爲，可以使用Mercurial的書籤。 – 2015-06-19 19:25:07
在git中，「branches」實現爲指向變更集的指針。
這意味着，一個特定的變更可以同時「屬於」幾個分支。
也就是說 - 它在運行時解決，你刪除一個分支（或修改任何其他方式的圖）之後 - 你不能告訴它所在的分支致力於最初。
在你的情況下，94f458e變更集屬於master和release，所以圖是完全正確的。
這聽起來像你基本上同意我在問題最後一段中寫的內容。除此之外，你沒有看到Git目前的行爲是沒有那麼有用的，而不是假設性的。在這一點上，我會不同意：我可以想象一個假設的VCS能夠保持git當前拋棄的信息，我可以想象這些信息在某些設置中是有用的。比如，這個。 – 2014-11-06 00:11:32
對不起，如果我聽起來不愉快。我真的很感激你花時間回答這個問題！ – 2014-11-06 00:14:22
@Adam L. Taylor：好吧，git不會跟蹤變更集致力於哪個分支的信息。 Mercurial的確如此。 – zerkms 2014-11-06 03:03:03
提交不是「在」分支。分支只不過是您感興趣的提交的本地方便名稱。重要的是你的回購歷史的結構。專注於此。提交94f和18d都是這兩個分支的歷史記錄的一部分，他們的提交release和master提交的祖先。
如果您的公用事業已在左側繪製master，則其提交將以藍色繪製，並且所有release的祖先獨有的顏色都將爲洋紅色。
這是多了還是少了什麼@zerkms說過（我upvoted他的），只是從不同的角度。
「如果你的公用事業已經在左邊畫出了主人，那麼它的提交就會以藍色繪製，並且所有對於發佈的祖先來說都是獨特的。」是的，這正是我想如何繪製的。這似乎可以說是git中的一個設計缺陷，它沒有保留足夠的信息來按照我希望繪製的方式繪製樹。 – 2014-11-06 15:38:59
事實證明，通過丟失「分支」是某種重量級抽象的概念，您可以獲得相當多的信息，而不是將分支名稱視爲存儲庫中提交圖上的可移動標籤。承諾自己只是承諾。 – jthill 2014-12-05 04:38:11
承諾掌握所有在單個通道中的通道：在提交94f458e處從藍色變爲紫色的通道。至於爲什麼它們是不同的顏色，那麼對於源代碼來說，這比堆棧溢出更重要。也許開發人員選擇將按時間順序排列的最新提交的路徑視爲不分支的路徑？根據路徑的名稱提交功能請求以更改它。 – 2014-11-05 23:36:41
當我說「車道」時，我的意思是「列」。而我所希望的是，如果所有提交給主人的提交都在一個列中，而要發佈的提交到另一列中。我的意思是，如果你給了人類DAG，分支指針和提交列，他們可能不會像上面那樣繪製樹圖。 – 2014-11-06 15:37:50
儘管git並沒有要求用戶提供足夠的信息來繪製正確的泳道，但在許多情況下，通過使用提交消息作爲提示可以推斷出更好的繪圖。例如，合併消息通常開始「合併分支'B'到A」;在這種情況下，很明顯兩個源分支的名稱應該用於泳道目的。用戶可以輕鬆添加更多清晰度;例如，每當我創建一個分支時，我都會在其中創建一個空的提交「從'A'創建分支'B'」。圖形繪製程序可以提供更多的提示。 – 2017-01-17 02:53:26