爲什麼Git不將分支名稱存儲爲提交的一部分？

Question

請注意：我不想重新啓動參數，無論Mercurial或Git是否更好，我只是有一個技術問題，作爲Mercurial用戶，我不明白。我也不確定SO是否是問這樣一個問題的合適地點，但它是編程相關的。

從用戶的角度（例如和http://felipec.wordpress.com/2011/01/16/mercurial-vs-git-its-all-in-the-branches/）已經討論了兩個版本控制系統Git和Mercurial的差異，主要區別在於處理分支。我已經閱讀了許多這些討論，但我一直在問自己這個問題：

爲什麼Git不將分支名稱存儲爲提交的一部分？

我真的沒有看到不這樣做的好理由;這意味着數據不能簡單地消失，因爲沒有任何引用（標籤，分支，或其他）指向它。

我看到將提交中的分支存儲爲Mercurial的一大優點，因爲這會使其更難以丟失數據。

Git支持Git分支模型的主要觀點是，您可以簡單地刪除分支，但並不妨礙Git將分支的名稱作爲每次提交的一部分進行存儲：如果分支的提交被刪除，對該分支的引用也是如此。它也不會干擾「廉價分支」的說法：分支機構管理起來不會更昂貴。我不認爲所需的額外存儲空間應該值得關注：每次提交只需幾個字節。

Answer 1

一個大約爲Git和水銀分支權威來源之一是SO問題：

「Git and Mercurial - Compare and Contrast」

在GIT中的引用（分支，遠程跟蹤分支和標籤）駐留的DAG外提交。

（這允許管理有關分支機構不同的命名空間，爲本地和遠程分支機構）

您有水銀帶書籤分支類似的看法（它可以推/拽）。

請注意，在Git中，由於沒有引用，數據不會「消失」：您仍然有reflog來檢索那些未引用的提交。

爲什麼Git不存儲分支名稱作爲提交的一部分？
我實在不明白一個很好的理由不這樣做，

的想法是從爲什麼米即從變化的背景下分開什麼已經改變（在提交）（名的分支）。
由於您可以在fast-forward merge分支，因此來自一個分支的提交可以隨時成爲另一個分支的一部分。

這就是爲什麼Jakub Narębski質疑水銀「命名的分支」（嵌入在變更元數據分支名稱）的設計，特別是與全球命名，不是很適合於分佈式版本控制系統。

您創建了一個分支來隔離開發工作（請參閱「When should you branch?」），但對於DVCS，應該在任何分支名稱下發布開發工作（該集合的提交）。一旦發佈到另一個Git倉庫，您定義的本地上下文（分支名稱）可能無效。

Answer 2

Mercurial的基本操作模型非常簡單，形成一個有向無環圖（DAG）的匿名分支，並且這樣的分支名稱沒有什麼重要性，您將會處理它們的次數更少。命名分支主要用於組織目的（發佈分支等），爲此我認爲全局名稱空間更有意義，或者至少不太令人反感。

Git有一個比Mercurial更復雜的託管分支模型，即使您的本地更改被視爲一個單獨的命名分支，並且面對如此衆多的命名分支時，您必須引入命名空間來管理它們。出於同樣的原因，Git具有快速合併的概念，因爲您不會在首位創建單獨的分支，所以不適用於Mercurial。

這兩個概念添加額外的複雜性，以及在像一起存儲分支名稱的同時區塊實用功能的承諾。這是因爲你不能存儲沒有全局空間的命名空間分支，而git沒有。

在該VonC以上引用的命名空間的觀點的缺陷在於，它假定有一個問題，如果你和我都創建一個名爲「X」的分支。沒有，就像創建一個命名分支時沒有問題一樣，將它合併，然後再創建另一個具有相同名稱的分支。一個精心挑選的名字描述了分支的作用，不管作者是誰，如果你需要更多的區分，作者將與分支名稱一起存儲，並且所有這些都是永久的。

我認爲這是Mercurial項目的一個非常好的決定，用於存儲分支名稱和提交。就像提交信息和作者一樣，作品（分支）的上下文是重要和有用的元信息。在查看歷史記錄時，它可以更容易地看到變更集的流程，因爲您可以看到它們的上下文。在Git中，如果沒有這些信息，歷史很快會變得雜亂無章，難以做到正面或反面。我認爲這非常值得沒有命名空間的權衡。

我認爲你可以說哲學上的區別是Mercurial將命名分支視爲永久元數據，它提供了關於一行提交的額外信息，而對於Git分支則是一個針對開發者的非版本管理系統DAG。順便說一下，Mercurial也在名稱'書籤'下面（版本1.8的核心功能），但它們實際上更像是一種跟蹤工具，並且像標籤而不是分支一樣對待。