Git自學之路（四）- git branch 分支

幾乎所有的版本控制系統都以某種形式支持分支。 使用分支意味著你可以把你的工作從開發主線上分離開來，以免影響開發主線。 在很多版本控制系統中，這是一個略微低效的過程——常常需要完全創建一個源代碼目錄的副本。對于大項目來說，這樣的過程會耗費很多時間。

有人把 Git 的分支模型稱為它的`‘必殺技特性’’，也正因為這一特性，使得 Git 從眾多版本控制系統中脫穎而出。 Git 處理分支的方式可謂是難以置信的輕量，創建新分支這一操作幾乎能在瞬間完成，并且在不同分支之間的切換操作也是一樣便捷。 與許多其它版本控制系統不同，Git 鼓勵在工作流程中頻繁地使用分支與合并，哪怕一天之內進行許多次。 理解和精通這一特性，你便會意識到 Git 是如此的強大而又獨特，并且從此真正改變你的開發方式。

分支簡介

Git 保存的不是文件的變化或者差異，而是一系列不同時刻的文件快照。

在進行提交操作時，Git 會保存一個提交對象（commit object）。知道了 Git 保存數據的方式，我們可以很自然的想到——該提交對象會包含一個指向暫存內容快照的指針。 但不僅僅是這樣，該提交對象還包含了作者的姓名和郵箱、提交時輸入的信息以及指向它的父對象的指針。首次提交產生的提交對象沒有父對象，普通提交操作產生的提交對象有一個父對象，而由多個分支合并產生的提交對象有多個父對象。

Git 的分支，騎士分支上僅僅是指向提交對象的可變指針。 Git的默認分支名字是?master?。在多次提交操作之后，你其實已經有一個指向最后那個提交對象的 master 分支。它會在每次的提交操作中自動向前移動。

注意： Git的 “master” 分支并不是一個特殊分支。它就跟其他分支完全沒有區別。之所以幾乎每一個倉庫都有 master 分支，是因為 git init 命令默認創建它，并且大多數人都懶得去改動它。

分支的創建

Git 創建新分支其實很簡單，它只是為你創建了一個可以移動的新的指針。例如，創建一個 testing 分支，你需要用 git branch 命令：

$ git branch testing
1

這會在當前所在的提交對象上創建一個指針。

那么，Git 是如何知道當前在哪一個分支上呢？ 也很簡單，它有一個名為 HEAD 的特殊指針。 請注意它和許多其它版本控制系統（如 Subversion 或 CVS）里的 HEAD 概念完全不同。 在 Git 中，它是一個指針，指向當前所在的本地分支（將 HEAD 想象為當前分支的別名）。 在本例中，你仍然在 master 分支上。 因為 git branch 命令僅僅創建一個新分支，并不會自動切換到新分支中去。

你可以簡單地使用 git log 命令查看各個分支當前所指的對象。 提供這一功能的參數是 –decorate。

$ git log --oneline --decorate
f30ab (HEAD, master, testing) add feature #32 - ability to add new
34ac2 fixed bug #1328 - stack overflow under certain conditions
98ca9 initial commit of my project
1
2
3
4

正如你所見，當前 “master” 和 “testing” 分支均指向校驗和以 f30ab 開頭的提交對象。

分支切換

要切換到一個已存在的分支，使用 git checkout 命令。現在我們切換到新創建的 testing 分支去：

$ git checkout testing
1

這樣 HEAD 就指向 testing 分支了。

那么，這樣的實現方式會給我們帶來什么好處呢？現在改動下在提交一次：

$ vim test.rb
$ git commit -a -m 'made a change'
1
2

如圖所示，你的 testing 分支向前移動了，但是 master 分支卻沒有，它仍然指向運行 git checkout 時所指的對象。 這就有意思了，現在我們切換回 master 分支看看：

$ git checkout master
1

這條命令做了兩件事。 一是使 HEAD 指回 master 分支，二是將工作目錄恢復成 master 分支所指向的快照內容。 也就是說，你現在做修改的話，項目將始于一個較舊的版本。 本質上來講，這就是忽略 testing 分支所做的修改，以便于向另一個方向進行開發。

分支切換會改變你工作目錄中的文件

在切換分支時，一定要注意你工作目錄里的文件會被改變。 如果是切換到一個較舊的分支，你的工作目錄會恢復到該分支最后一次提交時的樣子。 如果 Git 不能干凈利落地完成這個任務，它將禁止切換分支。

再稍微做些修改并提交：

$ vim test.rb
$ git commit -a -m 'made other changes'
1
2

現在，這個項目的提交歷史已經產生了分叉。 因為剛才創建了一個新分支，并切換過去進行了一些工作，隨后又切換回 master 分支進行了另外一些工作。 上述兩次改動針對的是不同分支，你可以在不同分支間不斷地來回切換和工作，并在時機成熟時將它們合并起來。 而所有這些工作，你需要的命令只有 branch、checkout 和 commit。

在使用 git log 命令查看分叉歷史。 運行 git log –oneline –decorate –graph –all ，它會輸出你的提交歷史、各個分支的指向以及項目的分支分叉情況。

$ git log --oneline --decorate --graph --all
* c2b9e (HEAD, master) made other changes
| * 87ab2 (testing) made a change
|/
* f30ab add feature #32 - ability to add new formats to the
* 34ac2 fixed bug #1328 - stack overflow under certain conditions
* 98ca9 initial commit of my project
1
2
3
4
5
6
7

由于 Git 的分支實質上僅是包含所指對象校驗和（長度為 40 的 SHA-1 值字符串）的文件，所以它的創建和銷毀都異常高效。 創建一個新分支就像是往一個文件中寫入 41 個字節（40 個字符和 1 個換行符），如此的簡單能不快嗎？

這與過去大多數版本控制系統形成了鮮明的對比，它們在創建分支時，將所有的項目文件都復制一遍，并保存到一個特定的目錄。 完成這樣繁瑣的過程通常需要好幾秒鐘，有時甚至需要好幾分鐘。所需時間的長短，完全取決于項目的規模。而在 Git 中，任何規模的項目都能在瞬間創建新分支。 同時，由于每次提交都會記錄父對象，所以尋找恰當的合并基礎（譯注：即共同祖先）也是同樣的簡單和高效。 這些高效的特性使得 Git 鼓勵開發人員頻繁地創建和使用分支。

分支的新建與合并

新建分支

創建新分支可以使用 git branch 命令，但想要在新建一個分支并同時切換到那個分支上怎么辦呢？可以運行一個帶有 -b 參數的 git checkout 命令，如你現在的線上系統出現一個 #10 問題，你可以專為這個問題創建一個分支進行修復：

$ git checkout -b issue10
Switched to a new branch "issue10"
1
2

它是下面兩條命令的簡寫：

$ git branch issue10
$ git checkout issue10
1
2

現在你就可以在 issue10 這個分支上進行你的修復工作而不影響 master 分支。在此過程中，issue10 分支會不斷向前推進，因為你已經切換到該分支。當然在這個過程中你也可以切換回 master 分支中開發。

合并分支

當你在 issue10 分支中修復之后就需要合并到 master 分支了，首先應該切換到 master 分支，但是，在切換之前，要留意你的工作目錄和暫存區里那些還沒有被提交的修改，它可能會和你即將檢出的分支產生沖突從而阻止 Git 切換到該分支。 最好的方法是，在你切換分支之前，保持好一個干凈的狀態。 有一些方法可以繞過這個問題（即，保存進度（stashing） 和 修補提交（commit amending））。 現在，我們假設你已經把你的修改全部提交了，這時你可以切換回 master 分支了：

$ git checkout master
1

當你切換回 master 后就可以使用 git merge 命令進行分支的合并工作了：

$ git merge issue10
1

執行上述命令后 Git 會很聰明的為你完成合并工作，Git 將此次合并的結果做一個新的快照并且自動創建一個新的提交指向它，一切就是這么簡單。

遇到沖突時的分支合并

一個在聰明的人也會有出錯的時候，Git 也一樣，有時候合并操作并不會如此順利。如果你在兩個不同的分支中，對同一個文件的同一個部分進行了不同的修改，Git 就沒法干凈的合并它們。 如果你在對 #10 問題的修改和在 master 的修改都涉及到同一個文件的同一處，在合并它們的時候就會產生合并沖突：

$ git merge issue10
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
1
2
3
4

此時 Git 做了合并，但是沒有自動地創建一個新的合并提交。 Git 會暫停下來，等待你去解決合并產生的沖突。 你可以在合并沖突后的任意時刻使用 git status 命令來查看那些因包含合并沖突而處于未合并（unmerged）狀態的文件。

任何因包含合并沖突而有待解決的文件，都會以未合并狀態標識出來。 Git 會在有沖突的文件中加入標準的沖突解決標記，這樣你可以打開這些包含沖突的文件然后手動解決沖突。 出現沖突的文件會包含一些特殊區段，看起來像下面這個樣子：

<<<<<<< HEAD:index.html
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">
 please contact us at support@github.com
</div>
>>>>>>> issue10:index.html
1
2
3
4
5
6
7

這表示 HEAD 所指示的版本（也就是你的 master 分支所在的位置，因為你在運行 merge 命令的時候已經檢出到了這個分支）在這個區段的上半部分（======= 的上半部分），而 issue10 分支所指示的版本在 ======= 的下半部分。 為了解決沖突，你必須選擇使用由 ======= 分割的兩部分中的一個，或者你也可以自行合并這些內容。 例如，你可以通過把這段內容換成下面的樣子來解決沖突：

<div id="footer">
please contact us at email.support@github.com
</div>
1
2
3

上述的沖突解決方案僅保留了其中一個分支的修改，并且 <<<<<<< , ======= , 和 >>>>>>> 這些行被完全刪除了。 在你解決了所有文件里的沖突之后，對每個文件使用 git add 命令來將其標記為沖突已解決。 一旦暫存這些原本有沖突的文件，Git 就會將它們標記為沖突已解決。

你可以再次運行 git status 來確認所有的合并沖突都已被解決，如果你對結果感到滿意，并且確定之前有沖突的的文件都已經暫存了，這時你可以輸入 git commit 來完成合并提交。

刪除分支

既然分支 issue10 的修復已經完全合并到 master 分支了，你已不在需要 issue10 分支了,刪除它并不會丟失任何東西。現在你可以使用帶參數 -d 的 git branch 命令進行分支的刪除工作：

$ git branch -d issue10
1

分支管理

git branch 命令不只是可以創建與刪除分支。 如果不加任何參數運行它，會得到當前所有分支的一個列表：

$ git branchiss53
* mastertesting
1
2
3
4

注意 master 分支前的 * 字符：它代表現在檢出的那一個分支（也就是說，當前 HEAD 指針所指向的分支）。 這意味著如果在這時候提交，master 分支將會隨著新的工作向前移動。 如果需要查看每一個分支的最后一次提交，可以運行 git branch -v 命令：

$ git branch -viss53   93b412c fix javascript issue
* master  7a98805 Merge branch 'iss53'testing 782fd34 add scott to the author list in the readmes
1
2
3
4

–merged 與 –no-merged 這兩個有用的選項可以過濾這個列表中已經合并或尚未合并到當前分支的分支。

當包含了還未合并的工作的分支，嘗試使用 git branch -d 命令刪除它時會失敗，如果真的想要刪除分支并丟掉那些工作，可以使用 -D 選項強制刪除它。

分支開發工作流

由于分支管理的便捷，因此衍生出一些典型的工作模式，可根據項目實際情況選擇使用。

長期分支

因為 Git 使用簡單的三方合并，所以就算在一段較長的時間內，反復把一個分支合并入另一個分支，也不是什么難事。 也就是說，在整個項目開發周期的不同階段，你可以同時擁有多個開放的分支；你可以定期地把某些特性分支合并入其他分支中。

許多使用 Git 的開發者都喜歡使用這種方式來工作，比如只在 master 分支上保留完全穩定的代碼——有可能僅僅是已經發布或即將發布的代碼。 他們還有一些名為 develop 或者 next 的平行分支，被用來做后續開發或者測試穩定性——這些分支不必保持絕對穩定，但是一旦達到穩定狀態，它們就可以被合并入 master 分支了。 這樣，在確保這些已完成的特性分支（短期分支，比如之前的 issue10 分支）能夠通過所有測試，并且不會引入更多 bug 之后，就可以合并入主干分支中，等待下一次的發布。

一些大型項目還有一個 proposed（建議） 或 pu: proposed updates（建議更新）分支，它可能因包含一些不成熟的內容而不能進入 next 或者 master 分支。 這么做的目的是使你的分支具有不同級別的穩定性；當它們具有一定程度的穩定性后，再把它們合并入具有更高級別穩定性的分支中。 再次強調一下，使用多個長期分支的方法并非必要，但是這么做通常很有幫助，尤其是當你在一個非常龐大或者復雜的項目中工作時。

特性分支

特性分支對任何規模的項目都適用。 特性分支是一種短期分支，它被用來實現單一特性或其相關工作。 也許你從來沒有在其他的版本控制系統（VCS）上這么做過，因為在那些版本控制系統中創建和合并分支通常很費勁。 然而，在 Git 中一天之內多次創建、使用、合并、刪除分支都很常見。

你在自己的特性分支（如 iss53 和 hotfix 分支）中提交了一些更新，并且在它們合并入主干分支之后，你又刪除了它們。 這項技術能使你快速并且完整地進行上下文切換（context-switch）——因為你的工作被分散到不同的流水線中，在不同的流水線中每個分支都僅與其目標特性相關，因此，在做代碼審查之類的工作的時候就能更加容易地看出你做了哪些改動。 你可以把做出的改動在特性分支中保留幾分鐘、幾天甚至幾個月，等它們成熟之后再合并，而不用在乎它們建立的順序或工作進度。

請牢記，當你做這么多操作的時候，這些分支全部都存于本地。 當你新建和合并分支的時候，所有這一切都只發生在你本地的 Git 版本庫中 —— 沒有與服務器發生交互。

遠程分支

遠程引用是對遠程倉庫的引用（指針），包括分支、標簽等等。 可通過 git ls-remote (remote) 來顯式地獲得遠程引用的完整列表，或者通過 git remote show (remote) 獲得遠程分支的更多信息。 然而，一個更常見的做法是利用遠程跟蹤分支。

遠程跟蹤分支是遠程分支狀態的引用。 它們是你不能移動的本地引用，當你做任何網絡通信操作時，它們會自動移動。 遠程跟蹤分支像是你上次連接到遠程倉庫時，那些分支所處狀態的書簽。

它們以 (remote)/(branch) 形式命名。假設你的網絡里有一個在 git.ourcompany.com 的 Git 服務器。 如果你從這里克隆，Git 的 clone 命令會為你自動將其命名為 origin，拉取它的所有數據，創建一個指向它的 master 分支的指針，并且在本地將其命名為 origin/master。 Git 也會給你一個與 origin 的 master 分支在指向同一個地方的本地 master 分支，這樣你就有工作的基礎。

“origin” 并無特殊含義?
遠程倉庫名字 “origin” 與分支名字 “master” 一樣，在 Git 中并沒有任何特別的含義一樣。 同時 “master” 是當你運行 git init 時默認的起始分支名字，原因僅僅是它的廣泛使用，“origin” 是當你運行 git clone 時默認的遠程倉庫名字。 如果你運行 git clone -o booyah，那么你默認的遠程分支名字將會是 booyah/master。

推送分支到遠程服務器

當你想要公開分享一個分支時，需要將其推送到有寫入權限的遠程倉庫上。 本地的分支并不會自動與遠程倉庫同步 - 你必須顯式地推送想要分享的分支。 這樣，你就可以把不愿意分享的內容放到私人分支上，而將需要和別人協作的內容推送到公開分支。

如果希望和別人一起在名為 serverfix 的分支上工作，你可以像推送第一個分支那樣推送它。 運行 git push (remote) (branch):

$ git push origin serverfix
Counting objects: 24, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (24/24), 1.91 KiB | 0 bytes/s, done.
Total 24 (delta 2), reused 0 (delta 0)
To https://github.com/schacon/simplegit* [new branch]      serverfix -> serverfix```Git 自動將 serverfix 分支名字展開為 refs/heads/serverfix:refs/heads/serverfix，那意味著，“推送本地的 serverfix 分支來更新遠程倉庫上的 serverfix 分支。”  下一次其他協作者從服務器上抓取數據時，他們會在本地生成一個遠程分支 origin/serverfix，指向服務器的 serverfix 分支的引用：  ```git
$ git fetch origin
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 3 (delta 0)
Unpacking objects: 100% (3/3), done.
From https://github.com/schacon/simplegit* [new branch]      serverfix    -> origin/serverfix<div class="se-preview-section-delimiter"></div>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

要特別注意的一點是當抓取到新的遠程跟蹤分支時，本地不會自動生成一份可編輯的副本（拷貝）。 換一句話說，這種情況下，不會有一個新的 serverfix 分支 - 只有一個不可以修改的 origin/serverfix 指針。

可以運行 git merge origin/serverfix 將這些工作合并到當前所在的分支。 如果想要在自己的 serverfix 分支上工作，可以將其建立在遠程跟蹤分支之上：

$ git checkout -b serverfix origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix'<div class="se-preview-section-delimiter"></div>
1
2
3
4
5
6
7
8
9

這會給你一個用于工作的本地分支，并且起點位于 origin/serverfix。

跟蹤分支

從一個遠程跟蹤分支檢出一個本地分支會自動創建一個叫做 “跟蹤分支”（有時候也叫做 “上游分支”）。 跟蹤分支是與遠程分支有直接關系的本地分支。 如果在一個跟蹤分支上輸入 git pull，Git 能自動地識別去哪個服務器上抓取、合并到哪個分支。

當克隆一個倉庫時，它通常會自動地創建一個跟蹤 origin/master 的 master 分支。 然而，如果你愿意的話可以設置其他的跟蹤分支 - 其他遠程倉庫上的跟蹤分支，或者不跟蹤 master 分支。 可運行 git checkout -b [branch] [remotename]/[branch]。 這是一個十分常用的操作所以 Git 提供了 –track 快捷方式：

$ git checkout --track origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix'<div class="se-preview-section-delimiter"></div>
1
2
3
4
5
6
7
8
9

將本地分支與遠程分支設置為不同名字:

$ git checkout -b sf origin/serverfix
Branch sf set up to track remote branch serverfix from origin.
Switched to a new branch 'sf'<div class="se-preview-section-delimiter"></div>
1
2
3
4
5
6
7
8
9

現在，本地分支 sf 會自動從 origin/serverfix 拉取。

設置已有的本地分支跟蹤一個剛剛拉取下來的遠程分支，或者想要修改正在跟蹤的上游分支，你可以在任意時間使用 -u 或 –set-upstream-to 選項運行 git branch 來顯式地設置。

$ git branch -u origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.<div class="se-preview-section-delimiter"></div>
1
2
3
4
5
6
7
8

查看設置的所有跟蹤分支，可以使用 git branch 的 -vv 選項。 這會將所有的本地分支列出來并且包含更多的信息，如每一個分支正在跟蹤哪個遠程分支與本地分支是否是領先、落后或是都有。

$ git branch -vviss53     7e424c3 [origin/iss53: ahead 2] forgot the bracketsmaster    1ae2a45 [origin/master] deploying index fix
* serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] this should do ittesting   5ea463a trying something new<div class="se-preview-section-delimiter"></div>
1
2
3
4
5
6
7
8
9
10
11

這里可以看到 iss53 分支正在跟蹤 origin/iss53 并且 “ahead” 是 2，意味著本地有兩個提交還沒有推送到服務器上。 也能看到 master 分支正在跟蹤 origin/master 分支并且是最新的。 接下來可以看到 serverfix 分支正在跟蹤 teamone 服務器上的 server-fix-good 分支并且領先 2 落后 1，意味著服務器上有一次提交還沒有合并入同時本地有三次提交還沒有推送。 最后看到 testing 分支并沒有跟蹤任何遠程分支。

需要重點注意的一點是這些數字的值來自于你從每個服務器上最后一次抓取的數據。 這個命令并沒有連接服務器，它只會告訴你關于本地緩存的服務器數據。 如果想要統計最新的領先與落后數字，需要在運行此命令前抓取所有的遠程倉庫。 可以像這樣做：$ git fetch –all; git branch -vv

拉取

當 git fetch 命令從服務器上抓取本地沒有的數據時，它并不會修改工作目錄中的內容。 它只會獲取數據然后讓你自己合并。 然而，有一個命令叫作 git pull 在大多數情況下它的含義是一個 git fetch 緊接著一個 git merge 命令。 如果有一個像之前章節中演示的設置好的跟蹤分支，不管它是顯式地設置還是通過 clone 或 checkout 命令為你創建的，git pull 都會查找當前分支所跟蹤的服務器與分支，從服務器上抓取數據然后嘗試合并入那個遠程分支。

由于 git pull 的魔法經常令人困惑所以通常單獨顯式地使用 fetch 與 merge 命令會更好一些。

刪除遠程分支

假設你已經通過遠程分支做完所有的工作了 - 也就是說你和你的協作者已經完成了一個特性并且將其合并到了遠程倉庫的 master 分支（或任何其他穩定代碼分支）。 可以運行帶有 –delete 選項的 git push 命令來刪除一個遠程分支。 如果想要從服務器上刪除 serverfix 分支，運行下面的命令：

git?
$ git push origin --delete serverfix?
To https://github.com/schacon/simplegit?
- [deleted] serverfix?


基本上這個命令做的只是從服務器上移除這個指針。 Git 服務器通常會保留數據一段時間直到垃圾回收運行，所以如果不小心刪除掉了，通常是很容易恢復的。

至此，你現在應該能自如地創建并切換至新分支、在不同分支之間切換以及合并本地分支，你現在應該也能通過推送你的分支至共享服務以分享它們、使用共享分支與他人協作。