前面的話
幾乎每一種版本控制系統都以某種形式支持分支。使用分支意味著可以從開發主線上分離開來，然后在不影響主線的同時繼續工作。在很多版本控制系統中，這是個昂貴的過程，常常需要創建一個源代碼目錄的完整副本，對大型項目來說會花費很長時間
有人把Git的分支模型稱為“必殺技特性”，而正是因為它，將Git從版本控制系統家族里區分出來。Git有何特別之處呢？Git的分支可謂是難以置信的輕量級，它的新建操作幾乎可以在瞬間完成，并且在不同分支間切換起來也差不多一樣快。和許多其他版本控制系統不同，Git鼓勵在工作流程中頻繁使用分支與合并，哪怕一天之內進行許多次都沒有關系。理解分支的概念并熟練運用后，才會意識到為什么Git是一個如此強大而獨特的工具，并從此真正改變開發方式。本文將詳細介紹Git分支
定義
為了理解Git分支的實現方式，我們需要回顧一下Git是如何儲存數據的。Git保存的不是文件差異或者變化量，而只是一系列文件快照
在Git中提交時，會保存一個提交(commit)對象，該對象包含一個指向暫存內容快照的指針，包含本次提交的作者等相關附屬信息，包含零個或多個指向該提交對象的父對象指針：首次提交是沒有直接祖先的，普通提交有一個祖先，由兩個或多個分支合并產生的提交則有多個祖先
為直觀起見，我們假設工作目錄中有三個文件，準備將它們暫存后提交。暫存操作會對每一個文件計算校驗和，然后把當前版本文件快照保存到Git倉庫(Git使用blob類型的對象存儲這些快照)，并將校驗和加入暫存區域
$ git add README test.rb LICENSE $ git commit -m 'initial commit of my project'
當使用git commit新建一個提交對象前，Git會先計算每一個子目錄(本例中就是項目根目錄)的校驗和，然后在Git倉庫中將這些目錄保存為樹(tree)對象。之后Git創建的提交對象，除了包含相關提交信息以外，還包含著指向這個樹對象(項目根目錄)的指針，如此它就可以在將來需要的時候，重現此次快照的內容了
現在，Git倉庫中有五個對象：三個表示文件快照內容的blob對象；一個記錄著目錄樹內容及其中各個文件對應blob對象索引的tree對象；以及一個包含指向tree對象(根目錄)的索引和其他提交信息元數據的commit對象。概念上來說，倉庫中的各個對象保存的數據和相互關系看起來如下圖所示
做些修改后再次提交，那么這次的提交對象會包含一個指向上次提交對象的指針(即下圖中的parent對象)。兩次提交后，倉庫歷史會變成下圖的樣子
現在來談分支。Git中的分支，其實本質上僅僅是個指向commit對象的可變指針。Git會使用master作為分支的默認名字。在若干次提交后，其實已經有了一個指向最后一次提交對象的master分支，它在每次提交的時候都會自動向前移動
那么，Git又是如何創建一個新的分支的呢？答案很簡單，創建一個新的分支指針。比如新建一個testing分支，可以使用git branch命令：
$ git branch testing
這會在當前commit對象上新建一個分支指針
那么，Git是如何知道你當前在哪個分支上工作的呢？其實答案也很簡單，它保存著一個名為HEAD的特別指針。請注意它和你熟知的許多其他版本控制系統(比如Subversion或CVS)里的HEAD概念大不相同。在Git中，它是一個指向你正在工作中的本地分支的指針(可以將HEAD想象為當前分支的別名)。運行git branch命令，僅僅是建立了一個新的分支，但不會自動切換到這個分支中去，所以在這個例子中，我們依然還在master分支里工作
要切換到其他分支，可以執行git checkout命令。我們現在轉換到新建的testing分支
$ git checkout testing
這樣HEAD就指向了testing分支
這樣的實現方式會給我們帶來什么好處呢？好吧，現在不妨再提交一次：
$ git commit -a -m 'made a change'
非常有趣，現在testing分支向前移動了一格，而master分支仍然指向原先git checkout時所在的commit對象。現在我們回到master分支看看
$ git checkout master
這條命令做了兩件事。它把HEAD指針移回到master分支，并把工作目錄中的文件換成了master分支所指向的快照內容。也就是說，現在開始所做的改動，將始于本項目中一個較老的版本。它的主要作用是將testing分支里作出的修改暫時取消，這樣你就可以向另一個方向進行開發
$ git commit -a -m 'made other changes'
現在我們的項目提交歷史產生了分叉，因為剛才我們創建了一個分支，轉換到其中進行了一些工作，然后又回到原來的主分支進行了另外一些工作。這些改變分別孤立在不同的分支里：我們可以在不同分支里反復切換，并在時機成熟時把它們合并到一起。而所有這些工作，僅僅需要branch和checkout這兩條命令就可以完成
由于Git中的分支實際上僅是一個包含所指對象校驗和(40個字符長度SHA-1字串)的文件，所以創建和銷毀一個分支就變得非常廉價。說白了，新建一個分支就是向一個文件寫入41個字節(外加一個換行符)那么簡單，當然也就很快了
這和大多數版本控制系統形成了鮮明對比，它們管理分支大多采取備份所有項目文件到特定目錄的方式，所以根據項目文件數量和大小不同，可能花費的時間也會有相當大的差別，快則幾秒，慢則數分鐘。而Git的實現與項目復雜度無關，它永遠可以在幾毫秒的時間內完成分支的創建和切換。同時，因為每次提交時都記錄了祖先信息(即parent對象)，將來要合并分支時，尋找恰當的合并基礎(即共同祖先)的工作其實已經自然而然地擺在那里了，所以實現起來非常容易。Git鼓勵開發者頻繁使用分支，正是因為有著這些特性作保障
接下來看看，我們為什么應該頻繁使用分支
新建與合并
現在讓我們來看一個簡單的分支與合并的例子，實際工作中大體也會用到這樣的工作流程：
1、開發某個網站
2、為實現某個新的需求，創建一個分支
3、在這個分支上開展工作
假設此時，突然接到一個電話說有個很嚴重的問題需要緊急修補，那么可以按照下面的方式處理：
1、返回到原先已經發布到生產服務器上的分支
2、為這次緊急修補建立一個新分支，并在其中修復問題
3、通過測試后，回到生產服務器所在的分支，將修補分支合并進來，然后再推送到生產服務器上。
4、切換到之前實現新需求的分支，繼續工作
【新建與切換】
假設你正在項目中愉快地工作，并且已經提交了幾次更新
現在，決定要修補問題追蹤系統上的#53問題。順帶說明下，Git并不同任何特定的問題追蹤系統打交道。這里為了說明要解決的問題，才把新建的分支取名為iss53。要新建并切換到該分支，運行git checkout并加上-b參數
$ git checkout -b iss53 Switched to a new branch 'iss53'
$ git branch iss53
$ git checkout iss53
接著開始嘗試修復問題，在提交了若干次更新后，iss53分支的指針也會隨著向前推進，因為它就是當前分支(換句話說，當前的HEAD指針正指向iss53)
$ git commit -a -m 'added a new footer [issue 53]'
現在你就接到了那個網站問題的緊急電話，需要馬上修補。有了Git，我們就不需要同時發布這個補丁和iss53里作出的修改，也不需要在創建和發布該補丁到服務器之前花費大力氣來復原這些修改。唯一需要的僅僅是切換回master分支
不過在此之前，留心你的暫存區或者工作目錄里，那些還沒有提交的修改，它會和你即將檢出的分支產生沖突從而阻止Git為你切換分支。切換分支的時候最好保持一個清潔的工作區域。稍后會介紹幾個繞過這種問題的辦法(分別叫做stashing和commitamending)。目前已經提交了所有的修改，所以接下來可以正常轉換到master分支：
$ git checkout master Switched to branch 'master'
此時工作目錄中的內容和你在解決問題#53之前一模一樣，你可以集中精力進行緊急修補。這一點值得牢記：Git會把工作目錄的內容恢復為檢出某分支時它所指向的那個提交對象的快照。它會自動添加、刪除和修改文件以確保目錄的內容和你當時提交時完全一樣
接下來，你得進行緊急修補。我們創建一個緊急修補分支hotfix來開展工作，直到搞定
$ git checkout -b hotfix Switched to a new branch 'hotfix'
$ git commit -a -m 'fixed the broken email address' [hotfix 3a0874c] fixed the broken email address 1 files changed, 1 deletion(-)
有必要作些測試，確保修補是成功的，然后回到master分支并把它合并進來，然后發布到生產服務器。用git merge命令來進行合并
$ git checkout master $ git merge hotfix Updating f42c576..3a0874c Fast-forward README | 1 - 1 file changed, 1 deletion(-)
請注意，合并時出現了“Fast forward”的提示。由于當前master分支所在的提交對象是要并入的hotfix分支的直接上游，Git只需把master分支指針直接右移。換句話說，如果順著一個分支走下去可以到達另一個分支的話，那么Git在合并兩者時，只會簡單地把指針右移，因為這種單線的歷史分支不存在任何需要解決的分歧，所以這種合并過程可以稱為快進(Fast forward)
現在最新的修改已經在當前master分支所指向的提交對象中了，可以部署到生產服務器上去了
在那個超級重要的修補發布以后，你想要回到被打擾之前的工作。由于當前hotfix分支和master都指向相同的提交對象，所以hotfix已經完成了歷史使命，可以刪掉了。使用git branch 的-d選項執行刪除操作
$ git branch -d hotfix
Deleted branch hotfix (was 3a0874c).
現在回到之前未完成的#53問題修復分支上繼續工作
$ git checkout iss53 Switched to branch 'iss53'
$ git commit -a -m 'finished the new footer [issue 53]' [iss53 ad82d7a] finished the new footer [issue 53] 1 file changed, 1 insertion(+)
值得注意的是之前hotfix分支的修改內容尚未包含到iss53中來。如果需要納入此次修補，可以用git merge master把master分支合并到iss53；或者等iss53完成之后，再將iss53分支中的更新并入master
【分支的合并】
在問題#53相關的工作完成之后，可以合并回master分支。實際操作同前面合并hotfix分支差不多，只需回到master分支，運行git merge命令指定要合并進來的分支：
$ git checkout master $ git merge iss53 Auto-merging README Merge made by the 'recursive' strategy. README | 1 + 1 file changed, 1 insertion(+)
請注意，這次合并操作的底層實現，并不同于之前hotfix的并入方式。因為這次你的開發歷史是從更早的地方開始分叉的。由于當前master分支所指向的提交對象(C4)并不是iss53分支的直接祖先，Git不得不進行一些額外處理。就此例而言，Git會用兩個分支的末端(C4和C5)以及它們的共同祖先(C2)進行一次簡單的三方合并計算。下圖用紅框標出了Git用于合并的三個提交對象
這次，Git沒有簡單地把分支指針右移，而是對三方合并后的結果重新做一個新的快照，并自動創建一個指向它的提交對象(C6)。這個提交對象比較特殊，它有兩個祖先(C4和C5)
值得一提的是Git可以自己裁決哪個共同祖先才是最佳合并基礎；這和CVS或Subversion(1.5以后的版本)不同，它們需要開發者手工指定合并基礎。所以此特性讓Git的合并操作比其他系統都要簡單不少
既然之前的工作成果已經合并到master了，那么iss53也就沒用了。你可以就此刪除它，并在問題追蹤系統里關閉該問題
$ git branch -d iss53
【遇到沖突時的分支合并】
有時候合并操作并不會如此順利。如果在不同的分支中都修改了同一個文件的同一部分，Git就無法干凈地把兩者合到一起(邏輯上說，這種問題只能由人來裁決)。如果你在解決問題#53的過程中修改了hotfix中修改的部分，將得到類似下面的結果
$ git merge iss53 Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result.
Git作了合并，但沒有提交，它會停下來等你解決沖突。要看看哪些文件在合并時發生沖突，可以用git status查閱：
$ git status On branch master You have unmerged paths. (fix conflicts and run "git commit") Unmerged paths: (use "git add <file>..." to mark resolution) both modified: index.html no changes added to commit (use "git add" and/or "git commit -a")
任何包含未解決沖突的文件都會以未合并(unmerged)的狀態列出。Git會在有沖突的文件里加入標準的沖突解決標記，可以通過它們來手工定位并解決這些沖突。可以看到此文件包含類似下面這樣的部分：
<<<<<<< HEAD <div id="footer">contact : email.support@github.com</div> ======= <div id="footer"> please contact us at support@github.com </div> >>>>>>> iss53
可以看到=======隔開的上半部分，是HEAD(即master分支，在運行merge命令時所切換到的分支)中的內容，下半部分是在iss53分支中的內容。解決沖突的辦法無非是二者選其一或者由你親自整合到一起。比如你可以通過把這段內容替換為下面這樣來解決：
<div id="footer"> please contact us at email.support@github.com </div>
這個解決方案各采納了兩個分支中的一部分內容，而且我還刪除了<<<<<<<，=======和>>>>>>>這些行。在解決了所有文件里的所有沖突后，運行git add將把它們標記為已解決狀態(實際上就是將一次快照保存到暫存區域)。因為一旦暫存，就表示沖突已經解決。如果你想用一個有圖形界面的工具來解決這些問題，不妨運行git mergetool，它會調用一個可視化的合并工具并引導你解決所有沖突：
$ git mergetool This message is displayed because 'merge.tool' is not configured. See 'git mergetool --tool-help' or 'git help config' for more details. 'git mergetool' will now attempt to use one of the following tools: opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge Merging: index.html Normal merge conflict for 'index.html': {local}: modified file {remote}: modified file Hit return to start merge resolution tool (opendiff):
如果不想用默認的合并工具，你可以在上方"merge tool candidates"里找到可用的合并工具列表，輸入你想用的工具名
退出合并工具以后，Git會詢問你合并是否成功。如果回答是，它會為你把相關文件暫存起來，以表明狀態為已解決
再運行一次git status來確認所有沖突都已解決：
$ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: index.html
如果覺得滿意了，并且確認所有沖突都已解決，也就是進入了暫存區，就可以用git commit來完成這次合并提交。提交的記錄差不多是這樣：
Merge branch 'iss53' Conflicts: index.html # # It looks like you may be committing a merge. # If this is not correct, please remove the file # .git/MERGE_HEAD # and try again. #
如果想給將來看這次合并的人一些方便，可以修改該信息，提供更多合并細節。比如你都作了哪些改動，以及這么做的原因。有時候裁決沖突的理由并不直接或明顯，有必要略加注解
分支管理
git branch命令不僅僅能創建和刪除分支，如果不加任何參數，它會給出當前所有分支的清單
$ git branch iss53 * master testing
注意看master分支前的*字符：它表示當前所在的分支。也就是說，如果現在提交更新，master分支將隨著開發進度前移。若要查看各個分支最后一個提交對象的信息，運行git branch -v：
$ git branch -v iss53 93b412c fix javascript issue * master 7a98805 Merge branch 'iss53' testing 782fd34 add scott to the author list in the readmes
要從該清單中篩選出你已經(或尚未)與當前分支合并的分支，可以用--merged和--no-merged選項(Git1.5.6以上版本)。比如用git branch --merged查看哪些分支已被并入當前分支，也就是說哪些分支是當前分支的直接上游
$ git branch --merged
iss53
* master
之前我們已經合并了iss53，所以在這里會看到它。一般來說，列表中沒有*的分支通常都可以用git branch -d來刪掉。原因很簡單，既然已經把它們所包含的工作整合到了其他分支，刪掉也不會損失什么
另外可以用git branch --no-merged查看尚未合并的分支
$ git branch --no-merged
testing
它會顯示還未合并進來的分支。由于這些分支中還包含著尚未合并進來的工作成果，所以簡單地用 git branch -d刪除該分支會提示錯誤，因為那樣做會丟失數據：
$ git branch -d testing error: The branch 'testing' is not fully merged. If you are sure you want to delete it, run 'git branch -D testing'.
不過，如果你確實想要刪除該分支上的改動，可以用大寫的刪除選項-D強制執行，就像上面提示信息中給出的那樣
工作流程
由于分支管理的便捷，衍生出了這類典型的工作模式，可以根據項目的實際情況進行選擇
【長期分支】
由于Git使用簡單的三方合并，所以就算在較長一段時間內，反復多次把某個分支合并到另一分支，也不是什么難事。也就是說，你可以同時擁有多個開放的分支，每個分支用于完成特定的任務，隨著開發的推進，你可以隨時把某個特性分支的成果并到其他分支中
許多使用Git的開發者都喜歡用這種方式來開展工作，比如僅在master分支中保留完全穩定的代碼，即已經發布或即將發布的代碼。與此同時，他們還有一個名為develop或next的平行分支，專門用于后續的開發，或僅用于穩定性測試—當然并不是說一定要絕對穩定，不過一旦進入某種穩定狀態，便可以把它合并到master里。這樣，在確保這些已完成的特性分支(短期分支，比如之前的iss53分支)能夠通過所有測試，并且不會引入更多錯誤之后，就可以并到主干分支中，等待下一次的發布。
本質上我們剛才談論的，是隨著提交對象不斷右移的指針。穩定分支的指針總是在提交歷史中落后一大截，而前沿分支總是比較靠前
或者把它們想象成工作流水線，或許更好理解一些，經過測試的提交對象集合被遴選到更穩定的流水線
你可以用這招維護不同層次的穩定性。某些大項目還會有個proposed(建議)或pu(proposed updates，建議更新)分支，它包含著那些可能還沒有成熟到進入next或master的內容。這么做的目的是擁有不同層次的穩定性：當這些分支進入到更穩定的水平時，再把它們合并到更高層分支中去。再次說明下，使用多個長期分支的做法并非必需，不過一般來說，對于特大型項目或特復雜的項目，這么做確實更容易管理
【特性分支】
在任何規模的項目中都可以使用特性(Topic)分支。一個特性分支是指一個短期的，用來實現單一特性或與其相關工作的分支。可能你在以前的版本控制系統里從未做過類似這樣的事情，因為通常創建與合并分支消耗太大。然而在Git中，一天之內建立、使用、合并再刪除多個分支是常見的事
我們在上節的例子里已經見過這種用法了。我們創建了iss53和hotfix這兩個特性分支，在提交了若干更新后，把它們合并到主干分支，然后刪除。該技術允許你迅速且完全的進行語境切換——因為你的工作分散在不同的流水線里，每個分支里的改變都和它的目標特性相關，瀏覽代碼之類的事情因而變得更簡單了。你可以把作出的改變保持在特性分支中幾分鐘，幾天甚至幾個月，等它們成熟以后再合并，而不用在乎它們建立的順序或者進度
現在我們來看一個實際的例子，如下圖所示，由下往上，起先我們在master工作到C1，然后開始一個新分支iss91嘗試修復91號缺陷，提交到C6的時候，又冒出一個解決該問題的新辦法，于是從之前C4的地方又分出一個分支iss91v2，干到C8的時候，又回到主干master中提交了C9和C10，再回到iss91v2繼續工作，提交C11，接著，又冒出個不太確定的想法，從master的最新提交C10處開了個新的分支dumbidea做些試驗
現在，假定兩件事情：我們最終決定使用第二個解決方案，即iss91v2中的辦法；另外，我們把dumbidea分支拿給同事們看了以后，發現它竟然是個天才之作。所以接下來，我們準備拋棄原來的iss91分支(實際上會丟棄C5和C6)，直接在主干中并入另外兩個分支。最終的提交歷史將變成如下圖所示
請務必牢記這些分支全部都是本地分支，這一點很重要。當你在使用分支及合并的時候，一切都是在你自己的Git倉庫中進行的——完全不涉及與服務器的交互
遠程分支
遠程分支(remote branch)是對遠程倉庫中的分支的索引。它們是一些無法移動的本地分支；只有在Git進行網絡交互時才會更新。遠程分支就像是書簽，提醒著你上次連接遠程倉庫時上面各分支的位置
我們用(遠程倉庫名)/(分支名)這樣的形式表示遠程分支。比如我們想看看上次同origin倉庫通訊時master分支的樣子，就應該查看origin/master分支。如果你和同伴一起修復某個問題，但他們先推送了一個iss53分支到遠程倉庫，雖然你可能也有一個本地的iss53分支，但指向服務器上最新更新的卻應該是origin/iss53分支
可能有點亂，我們不妨舉例說明。假設你們團隊有個地址為git.ourcompany.com的Git服務器。如果你從這里克隆，Git會自動為你將此遠程倉庫命名為origin，并下載其中所有的數據，建立一個指向它的master分支的指針，在本地命名為origin/master，但你無法在本地更改其數據。接著，Git建立一個屬于你自己的本地master分支，始于origin上master分支相同的位置，你可以就此開始工作：
如果你在本地master分支做了些改動，與此同時，其他人向git.ourcompany.com推送了他們的更新，那么服務器上的master分支就會向前推進，而與此同時，你在本地的提交歷史正朝向不同方向發展。不過只要你不和服務器通訊，你的origin/master指針仍然保持原位不會移動
可以運行git fetch origin來同步遠程服務器上的數據到本地。該命令首先找到origin是哪個服務器(本例為git.ourcompany.com)，從上面獲取你尚未擁有的數據，更新你本地的數據庫，然后把origin/master的指針移到它最新的位置上
為了演示擁有多個遠程分支(在不同的遠程服務器上)的項目是如何工作的，我們假設你還有另一個僅供你的敏捷開發小組使用的內部服務器git.team1.ourcompany.com。可以用git remote add命令把它加為當前項目的遠程分支之一。我們把它命名為teamone，以便代替完整的Git URL以方便使用
現在你可以用git fetch teamone來獲取小組服務器上你還沒有的數據了。由于當前該服務器上的內容是你origin服務器上的子集，Git不會下載任何數據，而只是簡單地創建一個名為teamone/master的遠程分支，指向teamone服務器上master分支所在的提交對象31b8e
【推送本地分支】
要想和其他人分享某個本地分支，你需要把它推送到一個你擁有寫權限的遠程倉庫。你創建的本地分支不會因為你的寫入操作而被自動同步到你引入的遠程服務器上，你需要明確地執行推送分支的操作。換句話說，對于無意分享的分支，你盡管保留為私人分支好了，而只推送那些協同工作要用到的特性分支
如果你有個叫serverfix的分支需要和他人一起開發，可以運行git push (遠程倉庫名) (分支名)：
$ git push origin serverfix Counting objects: 20, done. Compressing objects: 100% (14/14), done. Writing objects: 100% (15/15), 1.74 KiB, done. Total 15 (delta 5), reused 0 (delta 0) To git@github.com:schacon/simplegit.git * [new branch] serverfix -> serverfix
這里其實走了一點捷徑。Git自動把serverfix分支名擴展為refs/heads/serverfix:refs/heads/serverfix，意為“取出我在本地的serverfix分支，推送到遠程倉庫的serverfix分支中去”
不過一般使用的時候都可以省略它。也可以運行git push origin serverfix:serverfix來實現相同的效果，它的意思是“上傳我本地的serverfix分支到遠程倉庫中去，仍舊稱它為serverfix分支”。通過此語法，你可以把本地分支推送到某個命名不同的遠程分支：若想把遠程分支叫作awesomebranch，可以用git push origin serverfix:awesomebranch來推送數據
接下來，當你的協作者再次從服務器上獲取數據時，他們將得到一個新的遠程分支origin/serverfix，并指向服務器上serverfix所指向的版本：
$ git fetch origin remote: Counting objects: 20, done. remote: Compressing objects: 100% (14/14), done. remote: Total 15 (delta 5), reused 0 (delta 0) Unpacking objects: 100% (15/15), done. From git@github.com:schacon/simplegit * [new branch] serverfix -> origin/serverfix
值得注意的是，在fetch操作下載好新的遠程分支之后，你仍然無法在本地編輯該遠程倉庫中的分支。換句話說，在本例中，你不會有一個新的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'
這會切換到新建的serverfix本地分支，其內容同遠程分支origin/serverfix一致，這樣就可以在里面繼續開發了
【跟蹤遠程分支】
從遠程分支checkout出來的本地分支，稱為跟蹤分支(tracking branch)。跟蹤分支是一種和某個遠程分支有直接聯系的本地分支。在跟蹤分支里輸入git push，Git會自行推斷應該向哪個服務器的哪個分支推送數據。同樣，在這些分支里運行git pull會獲取所有遠程索引，并把它們的數據都合并到本地分支中來。
在克隆倉庫時，Git通常會自動創建一個名為master的分支來跟蹤origin/master。這正是git push和git pull一開始就能正常工作的原因。當然，你可以隨心所欲地設定為其它跟蹤分支，比如origin上除了master之外的其它分支。剛才我們已經看到了這樣的一個例子：git checkout -b [分支名] [遠程名]/[分支名]。如果你有1.6.2以上版本的 Git，還可以用--track選項簡化：
$ git checkout --track origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix'
要為本地分支設定不同于遠程分支的名字，只需在第一個版本的命令里換個名字：
$ git checkout -b sf origin/serverfix Branch sf set up to track remote branch serverfix from origin. Switched to a new branch 'sf'
現在你的本地分支sf會自動將推送和抓取數據的位置定位到origin/serverfix了
【刪除遠程分支】
如果不再需要某個遠程分支了，比如搞定了某個特性并把它合并進了遠程的master分支(或任何其他存放穩定代碼的分支)，可以用這個非常無厘頭的語法來刪除它：git push [遠程名] :[分支名]。如果想在服務器上刪除serverfix分支，運行下面的命令
$ git push origin :serverfix To git@github.com:schacon/simplegit.git - [deleted] serverfix
服務器上的分支沒了。有種方便記憶這條命令的方法：記住我們不久前見過的 git push [遠程名] [本地分支]:[遠程分支] 語法，如果省略 [本地分支]，那就等于是在說“在這里提取空白然后把它變成[遠程分支]”
分支衍合
把一個分支中的修改整合到另一個分支的辦法有兩種：merge 和 rebase(rebase的翻譯為“衍合”或變基)
【基本的衍合操作】
在分支合并一節中，開發進程分叉到兩個不同分支，又各自提交了更新
最容易的整合分支的方法是merge命令，它會把兩個分支最新的快照(C3和C4)以及二者最新的共同祖先(C2)進行三方合并，合并的結果是產生一個新的提交對象(C5)
其實，還有另外一個選擇：你可以把在C3里產生的變化補丁在C4的基礎上重新打一遍。在Git里，這種操作叫做衍合(rebase)。有了rebase命令，就可以把在一個分支里提交的改變移到另一個分支里重放一遍
$ git checkout experiment
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command
它的原理是回到兩個分支最近的共同祖先，根據當前分支(也就是要進行衍合的分支experiment)后續的歷次提交對象(這里只有一個C3)，生成一系列文件補丁，然后以基底分支(也就是主干分支master)最后一個提交對象(C4)為新的出發點，逐個應用之前準備好的補丁文件，最后會生成一個新的合并提交對象(C3')，從而改寫experiment的提交歷史，使它成為master分支的直接下游
現在回到master分支，進行一次快進合并
現在的C3'對應的快照，其實和普通的三方合并，即上個例子中的C5對應的快照內容一模一樣了。雖然最后整合得到的結果沒有任何區別，但衍合能產生一個更為整潔的提交歷史。如果視察一個衍合過的分支的歷史記錄，看起來會更清楚：仿佛所有修改都是在一根線上先后進行的，盡管實際上它們原本是同時并行發生的
一般我們使用衍合的目的，是想要得到一個能在遠程分支上干凈應用的補丁——比如某些項目你不是維護者，但想幫點忙的話，最好用衍合：先在自己的一個分支里進行開發，當準備向主項目提交補丁的時候，根據最新的origin/master進行一次衍合操作然后再提交，這樣維護者就不需要做任何整合工作(實際上是把解決分支補丁同最新主干代碼之間沖突的責任，化轉為由提交補丁的人來解決)，只需根據你提供的倉庫地址作一次快進合并，或者直接采納你提交的補丁
[注意]合并結果中最后一次提交所指向的快照，無論是通過衍合，還是三方合并，都會得到相同的快照內容，只不過提交歷史不同罷了。衍合是按照每行的修改次序重演一遍修改，而合并是把最終結果合在一起
【有趣的衍合】
衍合也可以放到其他分支進行，并不一定非得根據分化之前的分支。以下圖為例，我們為了給服務器端代碼添加一些功能而創建了特性分支server，然后提交C3和C4。然后又從C3的地方再增加一個client分支來對客戶端代碼進行一些相應修改，所以提交了C8和C9。最后，又回到server分支提交了C10
假設在接下來的一次軟件發布中，我們決定先把客戶端的修改并到主線中，而暫緩并入服務端軟件的修改(因為還需要進一步測試)。這個時候，我們就可以把基于client分支而非server分支的改變(即C8和C9)，跳過server直接放到master分支中重演一遍，但這需要用git rebase的--onto選項指定新的基底分支master
$ git rebase --onto master server client
這好比在說：“取出client分支，找出client分支和server分支的共同祖先之后的變化，然后把它們在master上重演一遍”
雖然client里的C8,C9在C3之后，但這僅表明時間上的先后，而非在C3修改的基礎上進一步改動，因為server和client這兩個分支對應的代碼應該是兩套文件，雖然這么說不是很嚴格，但應理解為在C3時間點之后，對另外的文件所做的C8，C9修改，放到主干重演
現在可以快進master分支了
$ git checkout master
$ git merge client
現在我們決定把server分支的變化也包含進來。我們可以直接把server分支衍合到master，而不用手工切換到server分支后再執行衍合操作——git rebase [主分支] [特性分支]命令會先取出特性分支server，然后在主分支master上重演
$ git rebase master server
于是，server的進度應用到master的基礎上，如下圖所示
然后就可以快進主干分支master了
$ git checkout master
$ git merge server
現在client和server分支的變化都已經集成到主干分支來了，可以刪掉它們了。最終我們的提交歷史如下圖所示
【衍合的風險】
要用衍合得遵守一條準則：一旦分支中的提交對象發布到公共倉庫，就千萬不要對該分支進行衍合操作
在進行衍合的時候，實際上拋棄了一些現存的提交對象而創造了一些類似但不同的新的提交對象。如果你把原來分支中的提交對象發布出去，并且其他人更新下載后在其基礎上開展工作，而稍后你又用git rebase拋棄這些提交對象，把新的重演后的提交對象發布出去的話，你的合作者就不得不重新合并他們的工作，這樣當你再次從他們那里獲取內容時，提交歷史就會變得一團糟
下面我們用一個實際例子來說明為什么公開的衍合會帶來問題。假設你從一個中央服務器克隆然后在它的基礎上搞了一些開發，提交歷史如下圖所示
現在，某人在C1的基礎上做了些改變，并合并他自己的分支得到結果C6，推送到中央服務器。當你抓取并合并這些數據到你本地的開發分支中后，會得到合并結果C7
接下來，那個推送C6上來的人決定用衍合取代之前的合并操作；繼而又用git push --force覆蓋了服務器上的歷史，得到C4'。而之后當你再從服務器上下載最新提交后，會得到
下載更新后需要合并，但此時衍合產生的提交對象C4'的SHA-1校驗值和之前C4完全不同，所以Git會把它們當作新的提交對象處理，而實際上此刻你的提交歷史C7中早已經包含了C4的修改內容，于是合并操作會把C7和C4'合并為C8
C8這一步的合并是遲早會發生的，因為只有這樣你才能和其他協作者提交的內容保持同步。而在C8之后，你的提交歷史里就會同時包含C4和C4'，兩者有著不同的SHA-1校驗值，如果用git log查看歷史，會看到兩個提交擁有相同的作者日期與說明，令人費解。而更糟的是，當你把這樣的歷史推送到服務器后，會再次把這些衍合后的提交引入到中央服務器，進一步困擾其他人
這個例子中，出問題的責任方是那個發布了C6后又用衍合發布C4'的人，其他人會因此反饋雙重歷史到共享主干，從而混淆大家的視聽
如果把衍合當成一種在推送之前清理提交歷史的手段，而且僅僅衍合那些尚未公開的提交對象，就沒問題。如果衍合那些已經公開的提交對象，并且已經有人基于這些提交對象開展了后續開發工作的話，就會出現叫人沮喪的麻煩
保存現場
軟件開發中，bug就像家常便飯一樣。有了bug就需要修復，在Git中，由于分支是如此的強大，所以，每個bug都可以通過一個新的臨時分支來修復，修復后，合并分支，然后將臨時分支刪除。
當你接到一個修復一個代號101的bug的任務時，很自然地，你想創建一個分支issue-101來修復它，但是，等等，當前正在dev上進行的工作還沒有提交：
$ git status # On branch dev # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: hello.py # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: readme.txt #
并不是不想提交，而是工作只進行到一半，還沒法提交，預計完成還需1天時間。但是，必須在兩個小時內修復該bug，怎么辦？
幸好，Git還提供了一個stash功能，可以把當前工作現場“儲藏”起來，等以后恢復現場后繼續工作
$ git stash Saved working directory and index state WIP on dev: 6224937 add merge HEAD is now at 6224937 add merge
現在，用git status查看工作區，就是干凈的（除非有沒有被Git管理的文件），因此可以放心地創建分支來修復bug。
首先確定要在哪個分支上修復bug，假定需要在master分支上修復，就從master創建臨時分支
$ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 6 commits. $ git checkout -b issue-101 Switched to a new branch 'issue-101'
現在修復bug，需要把“Git is free software ...”改為“Git is a free software ...”，然后提交
$ git add readme.txt $ git commit -m "fix bug 101" [issue-101 cc17032] fix bug 101 1 file changed, 1 insertion(+), 1 deletion(-)
修復完成后，切換到master分支，并完成合并，最后刪除issue-101分支
$ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 2 commits. $ git merge --no-ff -m "merged bug fix 101" issue-101 Merge made by the 'recursive' strategy. readme.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) $ git branch -d issue-101 Deleted branch issue-101 (was cc17032).
現在，是時候接著回到dev分支
$ git checkout dev Switched to branch 'dev' $ git status # On branch dev nothing to commit (working directory clean)
工作區是干凈的，剛才的工作現場存到哪去了？用git stash list命令看看：
$ git stash list stash@{0}: WIP on dev: 6224937 add merge
一是用git stash apply恢復，但是恢復后，stash內容并不刪除，你需要用git stash drop來刪除；
另一種方式是用git stash pop，恢復的同時把stash內容也刪了
$ git stash pop # On branch dev # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: hello.py # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: readme.txt # Dropped refs/stash@{0} (f624f8e5f082f2df2bed8a4e09c12fd2943bdd40)
再用git stash list查看，就看不到任何stash內容了
$ git stash list
可以多次stash，恢復的時候，先用git stash list查看，然后恢復指定的stash，用命令
$ git stash apply stash@{0}
總結一下，修復bug時，我們會通過創建新的bug分支進行修復，然后合并，最后刪除；當手頭工作沒有完成時，先把工作現場git stash一下，然后去修復bug，修復后，再git stash pop，回到工作現場
文章列表
留言列表
