GIT學習筆記（3）：分支管理

何謂分支

GIT是如何存儲數據的

　　GIT不是存儲文件差異或者變化量，而是一系列文件的快照。在Git提交時，會保存一個提交(commit)對象，該對象包含一個指向暫存內容快照的指針，它大概是這樣子的。

　　三個表示文件快照內容的 blob 對象；一個記錄著目錄樹內容及其中各個文件對應 blob 對象索引的 tree 對象；以及一個包含指向 tree 對象（根目錄）的索引和其他提交信息元數據的 commit 對象。

　　多個提交對象之間是鏈接關系，每個提交對象會指向上一個提交對象，如下圖所示：

引入分支

　　Git 中的分支，其實本質上僅僅是個指向 commit 對象的可變指針

創建一個新分支

　　創建一個新的分支很簡單，比如新建一個testing分支，可以使用命令git branch testing，此時將會有兩個分支指向當前commit對象。

　　那麽，Git 是如何知道你當前在哪個分支上工作的呢？其實答案也很簡單，它保存著一個名為 HEAD 的特別指針。它是一個指向你正在工作中的本地分支的指針（將 HEAD 想象為當前分支的別名。）。我們創建了新的分支，但是並不會自動切換到這個分支中去，所以我們依然在master分支中進行，我們可以使用git checkout testing命令，來轉換到新建的分支中

　　之後每次提交，HEAD將隨著分支一起向右移動，如下圖所示HEAD跟隨testing進行移動。

　　當然，我們可以使用checkout切換回matser分支，這樣再次提交就會產生不同的流向

分支的合並

通過上面內容，我們已經理解了分支的基本概念已經分支的新建切換步驟等等，下面我們來探討一下分支的合並。

分化分支的合並

　　如下圖所示，hotfix分支是master分支的分化分支，所謂分化，既是源於master，matser是其父級。　　　　　　

　　hotfix做了一些操作後，比如修復BUG，master認為hotfix修復了其關鍵故障，想合並hotfix分支，我們可以回到master，然後指向git merge hotfix命令。

　　此時發現master和hotfix指向了同一個commit對象。由於 master 分支所在的提交對象是要並入的 hotfix 分支的直接上遊，Git 只需把 master 分支指針直接右移。換句話說，如果順著一個分支走下去可以到達另一個分支的話，那麽 Git 在合並兩者時，只會簡單地把指針右移，因為這種單線的歷史分支不存在任何需要解決的分歧，所以這種合並過程可以稱為快進（Fast forward）。

　　這個時候，hotfix已經完成了歷史使命，可以刪掉了，使用git branch -d hotfix可以刪除不用的分支。

反思：看到這裏我們可以想一下實際的業務場景，比如我們matser版本出現問題，我們可以先創建一個新的分支進行修改，如果修復成功了，master合並即可，即使沒有成功，也不會對master有任何影響。

基於共同祖先的合並

　　比如maste分支r想要合並iss53分支，由於當前 master 分支所指向的提交對象（C4）並不是 iss53 分支的直接祖先，Git 不得不進行一些額外處理。就此例而言，Git 會用兩個分支的末端（C4 和 C5）以及它們的共同祖先（C2）進行一次簡單的三方合並計算。

　　即如下圖所示：

　　這次，Git 沒有簡單地把分支指針右移，而是對三方合並後的結果重新做一個新的快照，並自動創建一個指向它的提交對象（C6）。

　　既然之前的工作成果已經合並到 master 了，那麽 iss53 也就沒用了。你可以就此刪除它。

遇到沖突時的分支合並

　　有時候合並操作並不會如此順利。如果在不同的分支中都修改了同一個文件的同一部分，Git 就無法幹凈地把兩者合到一起，比如我們合並master與tesing分支。

　　此時會出現問題，因為他檢測出來兩個分支都對Test.java進行了操作，他對Test.java進行了合並，但沒有提交，它會停下來等你解決沖突。打開Test.java文件，我們發現它自動的把兩者的內容放在一起，讓我們做出選擇

　　我們自行做出修改，然後運行git add將其表示為已經解決狀態，最後提交即可。

　　到這裏分支管理的基礎內容已經講完了，關於遠程分支等內容我們將在下篇文章中詳細說明，謝謝關註！

GIT學習筆記（3）：分支管理