主要跟着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' 的人，其他人會因此反饋雙重歷史到共享主幹，從而混淆大家的視聽。）。
如果把衍合當成一種在推送之前清理提交歷史的手段，而且僅僅衍合那些尚未公開的提交對象，就沒問題。如果衍合那些已經公開的提交對象，並且已經有人基於這些提交對象開展了後續開發工作的話，就會出現叫人沮喪的麻煩。