電影和電視把節目描繪成一種瘋狂的活動。**的計時器倒計時，那個書呆子的夥伴在那之前一直是個累贅，他在筆記本電腦上狂熱地工作。代碼在屏幕上飛過，直到她用一個令人滿意的咔嗒聲敲響了最後一個回車鍵！計時器停了，世界又恢復了正常。但編程不是這樣的。它包括設計文檔、UI模型和代碼評審。最重要的是，它涉及到反覆試驗，尤其是如果你是一個初學者（像我一樣）。

現在，您可能已經確信將編碼項目保持在源代碼控制中的價值。將所有這些嘗試和錯誤提交到您的存儲庫將導致一個龐大而不整潔的項目，並且有許多修訂。你所做的大多數承諾都會包含已損壞的內容，那麼為什麼要保存它呢？git分支特性有助於將所有這些混亂的代碼與您所知道的有用的東西隔離開來。

在本文中，我們將研究代碼分支的含義、方法以及管理“main”分支更新的方法。

創建git分支

通過對源代碼管理的介紹，我們瞭解到您可以在終端中使用以下命令創建新的存儲庫：

當您這樣做時，它會在您當前的路徑中創建一個名為“.git”的隱藏目錄。如果您看不到它，請參閱我們之前關於查看隱藏文件的一些文章。此目錄包含保存文件修訂歷史記錄所需的所有信息。一旦您將文件管理器設置為顯示隱藏文件，就可以打開.git文件夾並看到許多子目錄。其中一個稱為“refs”（如下圖所示），其“heads”子目錄包含項目中所有分支的列表。一開始你只有一個，叫做“大師”

refs目錄保存分支的記錄，但不保存分支本身。至少，不是你現在使用的分支。這些文件保存在工作目錄中（在上面的例子中是“~/Temp/post-programming git-branch”），因此您可以以正常的方式訪問它們。正是這樣，我們創建了第一個文件（名為“first-文件.txt），即在.git目錄之外。使用上一篇git簡介文章中的trusty命令檢查這一點：

現在我們可以看到工作目錄有兩個文件，一個是我們提交的，另一個是git自動創建的（它包含我們剛剛輸入的提交消息）。

現在，讓我們創建一個名為“testing”的新git分支：

檢查分支機構，並在其中工作

我們可以在不使用任何名稱的情況下發出上述命令，以獲取所有分支的列表，以及當前正在使用的分支（即“簽出”的分支）：

現在，如果我們檢查目錄結構，我們將看到“.git/refs/heads”現在有兩個文件，分別用於“master”和“testing”

每一個都是組成分支的提交列表。例如，如果我們使用“gitlog”命令檢查“master”分支，我們可以看到對該分支的每個提交都有一行。

“簽出”分支的過程意味著您對文件所做的更改將是該分支的一部分，而不是其他分支的一部分。例如，假設我們使用以下命令簽出測試git分支：

然後我們在第一行中添加一行文本-文件.txt，當然是事後提交。如果切換回主分支，您會發現文件仍然為空（cat命令在終端中顯示文件的內容）：

但是回到“testing”分支，該文件仍然有添加的文本：

但是我們在目錄中看到的只是一個文件“first”-文件.txt“那麼，同一個文件的這兩個備用版本在哪裡呢？.git目錄解釋了這些更改，但不是您所期望的那樣。

git如何存儲東西

如果您要檢查其他版本控制系統（如Subversion）的存儲庫，您會發現它們為每個單獨的文件維護每個版本的一個副本。這意味著如果您擁有一個文件的存儲庫，然後創建兩個分支，則repo包含該文件的兩個不同副本。實際上，您實際上使用“svn copy”作為命令在Subversion中創建分支！另一方面，git基於“變化”的概念進行操作

上面的輸出告訴我們“trunk”（SVN版本的“master”）的全部內容都被複制了。查看文件管理器可以確認這一點：

“.git/objects”目錄保存了所有這些小更改，每個更改都用一個ID進行跟蹤。例如，在下圖中，您將看到具有長ID樣式名稱的文件。每個文件夾都位於一個名為兩個十六進制字符（下面是8c和8d）的文件夾中。

這些文件夾和文件名一起構成了特定更改的ID（實際上是SHA1散列）。您可以使用git cat file命令瀏覽它們的內容。根據他們修改過的日期，我們可以看到以“8d”開頭的那個先出現了，它什麼也沒有顯示。而以“8c”開頭的包含我們在“testing”分支中添加到文件中的文本行。

要點是git分支（包括默認的“master”）不是包含文件副本的單獨的“文件夾”。相反，它們是隨著時間推移對文件所做更改的列表。這在存儲方面效率更高，但結果是一樣的。你做了什麼（打破？）在git中，分支會一直保留在那裡，直到您合併它。

合併回主分支的策略（刪除還是不刪除？）

假設您有一個現有的項目，其中包含許多文件，然後您將這些文件擴展到“測試”，並對其進行了一些工作。現在您需要將這些更改返回到“主”分支中。您可以從“主”分支執行以下操作：

如果沒有衝突，由新文本組成的更改將應用於“master”，結果是“first”-文件.txt“在兩個分支中都是相同的。然而，從來沒有真正的替代版本的文件。

現在問題來了，怎麼處理這個分支？與分支機構打交道有兩種常見的策略。

1. 一種是保留一個git分支，比如“testing”，以便在中運行（如上圖所示）。你試著做一些事情，如果你能讓它們工作的話，把修改合併回“master”中，然後你就可以結束對那個分支的工作，甚至完全擺脫它。這意味著您的“master”是最穩定的代碼版本，因為它應該只包含您知道可以工作的內容。您也可以將這種方法視為使用“功能分支”，這是因為它們的目的是細化代碼中的一個（或多個）特定的附加內容。
2. 另一種方法是在“主”分支中完成所有的主要工作，並在此過程中做出承諾。一旦你對這個功能滿意了，你就可以在裡面創建一個分支來修復bug等等。這將導致更多的“發佈分支”（如下所示），因為它們以發佈結束。這也意味著“主”分支通常是最不穩定的代碼版本。

用最適合你的方法

這裡的第一種方法在使用git時更為常見。它的其他特性（特別是標記）使得將代碼的特定快照標記為“穩定”變得很容易，它也更適合於更大的協作項目。但是當你在自己的個人項目上工作時，請隨意使用其中對你最有意義的一個。使用git最大的好處是，您可以捕獲所有更改，這樣您就可以隨時返回並找到一些東西。用git分支組織你的項目會讓這變得更容易。

你如何在你的項目中接近分支機構？你用它們做實驗，然後再把它們扔掉嗎？或者它們代表了你在這個項目上工作的詳細歷史？

如果你在git項目中有任何處理分支的聰明方法，請在下面的評論中告訴我們！