主要跟著https://gitee.com/progit/index.html來學習的，知識點來自這裡，新增自己的理解和標記。

檢視分支

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

要從該清單中篩選出你已經（或尚未）與當前分支合併的分支，可以用 --merge 和 --no-merged 選項（Git 1.5.6 以上版本）。

比如用 git branch --merge 檢視哪些分支已被併入當前分支（譯註：也就是說哪些分支是當前分支的直接上游。）：

$ 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 an ancestor of your current HEAD.
    If you are sure you want to delete it, run 'git branch -D testing'.

不過，如果你確實想要刪除該分支上的改動，可以用大寫的刪除選項 -D 強制執行，就像上面提示資訊中給出的那樣。

利用分支進行開發的工作流程

長期分支

由於 Git 使用簡單的三方合併，所以就算在較長一段時間內，反覆多次把某個分支合併到另一分支，也不是什麼難事。也就是說，你可以同時擁有多個開放的分支，每個分支用於完成特定的任務，隨著開發的推進，你可以隨時把某個特性分支的成果併到其他分支中。

許多使用 Git 的開發者都喜歡用這種方式來開展工作，比如僅在 master 分支中保留完全穩定的程式碼，即已經發布或即將釋出的程式碼。與此同時，他們還有一個名為 develop 或 next 的平行分支，專門用於後續的開發，或僅用於穩定性測試 — 當然並不是說一定要絕對穩定，不過一旦進入某種穩定狀態，便可以把它合併到 master 裡。這樣，在確保這些已完成的特性分支（短期分支，比如之前的 iss53 分支）能夠通過所有測試，並且不會引入更多錯誤之後，就可以併到主幹分支中，等待下一次的釋出。

本質上我們剛才談論的，是隨著提交物件不斷右移的指標。穩定分支的指標總是在提交歷史中落後一大截，而前沿分支總是比較靠前。

穩定分支總是比較老舊。

或者把它們想象成工作流水線，或許更好理解一些，經過測試的提交物件集合被遴選到更穩定的流水線（見圖 3-19）。

 

 想象成流水線可能會容易點。

你可以用這招維護不同層次的穩定性。某些大專案還會有個 proposed（建議）或 pu（proposed updates，建議更新）分支，它包含著那些可能還沒有成熟到進入 next 或 master 的內容。這麼做的目的是擁有不同層次的穩定性：當這些分支進入到更穩定的水平時，再把它們合併到更高層分支中去。再次說明下，使用多個長期分支的做法並非必需，不過一般來說，對於特大型專案或特複雜的專案，這麼做確實更容易管理。

特性分支

在任何規模的專案中都可以使用特性（Topic）分支。一個特性分支是指一個短期的，用來實現單一特性或與其相關工作的分支。可能你在以前的版本控制系統裡從未做過類似這樣的事情，因為通常建立與合併分支消耗太大。然而在 Git 中，一天之內建立、使用、合併再刪除多個分支是常見的事。

現在我們來看一個實際的例子。請看圖 ，由下往上，起先我們在 master 工作到 C1，然後開始一個新分支 iss91 嘗試修復 91 號缺陷，提交到 C6 的時候，又冒出一個解決該問題的新辦法，於是從之前 C4 的地方又分出一個分支 iss91v2，幹到 C8 的時候，又回到主幹 master 中提交了 C9 和 C10，再回到 iss91v2 繼續工作，提交 C11，接著，又冒出個不太確定的想法，從 master 的最新提交 C10 處開了個新的分支 dumbidea 做些試驗。

 

 擁有多個特性分支的提交歷史。

 

現在，假定兩件事情：我們最終決定使用第二個解決方案，即 iss91v2 中的辦法；另外，我們把 dumbidea 分支拿給同事們看了以後，發現它竟然是個天才之作。所以接下來，我們準備拋棄原來的 iss91 分支（實際上會丟棄 C5 和 C6），直接在主幹中併入另外兩個分支。最終的提交歷史將變成圖 3-21 這樣：

 

合併了 dumbidea 和 iss91v2 後的分支歷史。

請務必牢記這些分支全部都是本地分支，這一點很重要。當你在使用分支及合併的時候，一切都是在你自己的 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 分支相同的位置，你可以就此開始工作：

 

 一次 Git 克隆會建立你自己的本地分支 master 和遠端分支 origin/master，並且將它們都指向 origin 上的 master 分支。

 

如果你在本地 master 分支做了些改動，與此同時，其他人向 git.ourcompany.com 推送了他們的更新，那麼伺服器上的 master 分支就會向前推進，而於此同時，你在本地的提交歷史正朝向不同方向發展。不過只要你不和伺服器通訊，你的 origin/master 指標仍然保持原位不會移動（見圖 3-23）。

 

在本地工作的同時有人向遠端倉庫推送內容會讓提交歷史開始分流。

 

可以執行 git fetch origin 來同步遠端伺服器上的資料到本地。該命令首先找到 origin 是哪個伺服器（本例為 git.ourcompany.com），從上面獲取你尚未擁有的資料，更新你本地的資料庫，然後把 origin/master 的指標移到它最新的位置上。

 git fetch 命令會更新 remote 索引。

 

為了演示擁有多個遠端分支（在不同的遠端伺服器上）的專案是如何工作的，我們假設你還有另一個僅供你的敏捷開發小組使用的內部伺服器 git.team1.ourcompany.com。可以用第二章中提到的 git remote add 命令把它加為當前專案的遠端分支之一。我們把它命名為 teamone，以便代替完整的 Git URL 以方便使用。

把另一個伺服器加為遠端倉庫

 

現在你可以用 git fetch teamone 來獲取小組伺服器上你還沒有的資料了。由於當前該伺服器上的內容是你 origin 伺服器上的子集，Git 不會下載任何資料，而只是簡單地建立一個名為 teamone/master 的遠端分支，指向 teamone 伺服器上 master 分支所在的提交物件 31b8e。

你在本地有了一個指向 teamone 伺服器上 master 分支的索引。

 

推送本地分支

要想和其他人分享某個本地分支，你需要把它推送到一個你擁有寫許可權的遠端倉庫。你建立的本地分支不會因為你的寫入操作而被自動同步到你引入的遠端伺服器上，你需要明確地執行推送分支的操作。換句話說，對於無意分享的分支，你儘管保留為私人分支好了，而只推送那些協同工作要用到的特性分支。

如果你有個叫 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 [email protected]:schacon/simplegit.git
    * [new branch] serverfix -> serverfix

這裡其實走了一點捷徑。Git 自動把 serverfix 分支名擴充套件為 refs/heads/serverfix:refs/heads/serverfix，意為“取出我在本地的 serverfix 分支，推送到遠端倉庫的 serverfix 分支中去”。我們將在第九章進一步介紹 refs/heads/ 部分的細節，不過一般使用的時候都可以省略它。也可以執行 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 [email protected]: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 refs/remotes/origin/serverfix.
    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 refs/remotes/origin/serverfix.
    Switched to a new branch "serverfix"

要為本地分支設定不同於遠端分支的名字，只需在第一個版本的命令裡換個名字：

$ git checkout -b sf origin/serverfix
    Branch sf set up to track remote branch refs/remotes/origin/serverfix.
    Switched to a new branch "sf"

現在你的本地分支 sf 會自動將推送和抓取資料的位置定位到 origin/serverfix 了。

刪除遠端分支

如果不再需要某個遠端分支了，比如搞定了某個特性並把它合併進了遠端的 master 分支（或任何其他存放穩定程式碼的分支），可以用這個非常無厘頭的語法來刪除它：git push [遠端名] :[分支名]。如果想在伺服器上刪除 serverfix 分支，執行下面的命令：

$ git push origin :serverfix
    To [email protected]: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 分支的直接下游:

把 C3 裡產生的改變到 C4 上重演一遍。

 

現在回到 master 分支，進行一次快進合併：

 master 分支的快進。

 

現在的 C3' 對應的快照，其實和普通的三方合併，即上個例子中的 C5 對應的快照內容一模一樣了。雖然最後整合得到的結果沒有任何區別，但衍合能產生一個更為整潔的提交歷史。如果視察一個衍合過的分支的歷史記錄，看起來會更清楚：彷彿所有修改都是在一根線上先後進行的，儘管實際上它們原本是同時並行發生的。

一般我們使用衍合的目的，是想要得到一個能在遠端分支上乾淨應用的補丁 — 比如某些專案你不是維護者，但想幫點忙的話，最好用衍合：先在自己的一個分支裡進行開發，當準備向主專案提交補丁的時候，根據最新的 origin/master 進行一次衍合操作然後再提交，這樣維護者就不需要做任何整合工作（譯註：實際上是把解決分支補丁同最新主幹程式碼之間衝突的責任，化轉為由提交補丁的人來解決。），只需根據你提供的倉庫地址作一次快進合併，或者直接採納你提交的補丁。

請注意，合併結果中最後一次提交所指向的快照，無論是通過衍合，還是三方合併，都會得到相同的快照內容，只不過提交歷史不同罷了。衍合是按照每行的修改次序重演一遍修改，而合併是把最終結果合在一起。

有趣的衍合

衍合也可以放到其他分支進行，並不一定非得根據分化之前的分支。例，我們為了給伺服器端程式碼新增一些功能而建立了特性分支 server，然後提交 C3 和 C4。然後又從 C3 的地方再增加一個 client 分支來對客戶端程式碼進行一些相應修改，所以提交了 C8 和 C9。最後，又回到 server 分支提交了 C10。

從一個特性分支裡再分出一個特性分支的歷史。

 

假設在接下來的一次軟體釋出中，我們決定先把客戶端的修改併到主線中，而暫緩併入服務端軟體的修改（因為還需要進一步測試）。這個時候，我們就可以把基於 server 分支而非 master 分支的改變（即 C8 和 C9），跳過 server 直接放到 master 分支中重演一遍，但這需要用 git rebase的 --onto 選項指定新的基底分支 master：

$ git rebase --onto master server client

這好比在說：“取出 client 分支，找出 client 分支和 server 分支的共同祖先之後的變化，然後把它們在 master 上重演一遍”。是不是有點複雜？不過它的結果如圖 3-32 所示，非常酷（譯註：雖然 client 裡的 C8, C9 在 C3 之後，但這僅表明時間上的先後，而非在 C3 修改的基礎上進一步改動，因為 server 和 client 這兩個分支對應的程式碼應該是兩套檔案，雖然這麼說不是很嚴格，但應理解為在 C3 時間點之後，對另外的檔案所做的 C8，C9 修改，放到主幹重演。）：

 

 將特性分支上的另一個特性分支衍合到其他分支。

 

現在可以快進 master 分支了（見圖 3-33）：

$ git checkout master
    $ git merge client

 

快進 master 分支，使之包含 client 分支的變化。

 

現在我們決定把 server 分支的變化也包含進來。我們可以直接把 server 分支衍合到 master，而不用手工切換到 server 分支後再執行衍合操作 — git rebase [主分支] [特性分支] 命令會先取出特性分支 server，然後在主分支 master 上重演：

$ git rebase master server

於是，server 的進度應用到 master 的基礎上，如圖 3-34 所示：

 

圖 3-34. 在 master 分支上衍合 server 分支。

 

然後就可以快進主幹分支 master 了：

$ git checkout master
    $ git merge server

現在 client 和 server 分支的變化都已經整合到主幹分支來了，可以刪掉它們了。最終我們的提交歷史會變成圖 3-35 的樣子：

$ git branch -d client
    $ git branch -d server

 

圖 3-35. 最終的提交歷史

 

衍合的風險

呃，奇妙的衍合也並非完美無缺，要用它得遵守一條準則：

一旦分支中的提交物件釋出到公共倉庫，就千萬不要對該分支進行衍合操作。

如果你遵循這條金科玉律，就不會出差錯。否則，人民群眾會仇恨你，你的朋友和家人也會嘲笑你，唾棄你。

在進行衍合的時候，實際上拋棄了一些現存的提交物件而創造了一些類似但不同的新的提交物件。如果你把原來分支中的提交物件釋出出去，並且其他人更新下載後在其基礎上開展工作，而稍後你又用 git rebase 拋棄這些提交物件，把新的重演後的提交物件釋出出去的話，你的合作者就不得不重新合併他們的工作，這樣當你再次從他們那裡獲取內容時，提交歷史就會變得一團糟。

下面我們用一個實際例子來說明為什麼公開的衍合會帶來問題。假設你從一箇中央伺服器克隆然後在它的基礎上搞了一些開發，提交歷史類似圖 3-36 所示：

克隆一個倉庫，在其基礎上工作一番。

 

現在，某人在 C1 的基礎上做了些改變，併合並他自己的分支得到結果 C6，推送到中央伺服器。當你抓取併合並這些資料到你本地的開發分支中後，會得到合併結果 C7，歷史提交會變成圖 3-37 這樣：

抓取他人提交，併入自己主幹。

 

接下來，那個推送 C6 上來的人決定用衍合取代之前的合併操作；繼而又用 git push --force 覆蓋了伺服器上的歷史，得到 C4'。而之後當你再從伺服器上下載最新提交後，會得到：

有人推送了衍合後得到的 C4'，丟棄了你作為開發基礎的 C4 和 C6。

 

下載更新後需要合併，但此時衍合產生的提交物件 C4' 的 SHA-1 校驗值和之前 C4 完全不同，所以 Git 會把它們當作新的提交物件處理，而實際上此刻你的提交歷史 C7 中早已經包含了 C4 的修改內容，於是合併操作會把 C7 和 C4' 合併為 C8（見圖 3-39）:

你把相同的內容又合併了一遍，生成一個新的提交 C8。

 

C8 這一步的合併是遲早會發生的，因為只有這樣你才能和其他協作者提交的內容保持同步。而在 C8 之後，你的提交歷史裡就會同時包含 C4 和 C4'，兩者有著不同的 SHA-1 校驗值，如果用 git log 檢視歷史，會看到兩個提交擁有相同的作者日期與說明，令人費解。而更糟的是，當你把這樣的歷史推送到伺服器後，會再次把這些衍合後的提交引入到中央伺服器，進一步困擾其他人（譯註：這個例子中，出問題的責任方是那個釋出了 C6 後又用衍合發布 C4' 的人，其他人會因此反饋雙重歷史到共享主幹，從而混淆大家的視聽。）。

如果把衍合當成一種在推送之前清理提交歷史的手段，而且僅僅衍合那些尚未公開的提交物件，就沒問題。如果衍合那些已經公開的提交物件，並且已經有人基於這些提交物件開展了後續開發工作的話，就會出現叫人沮喪的麻煩。