6 分支管理
從其他分支分離出來，建立一個屬于自己的分支，别人看不到，還繼續在原來的分支上正常工作，而你在自己的分支上幹活，想送出就送出，直到開發完畢後，再一次性合并到原來的分支上，這樣，既安全，又不影響别人工作。其他版本控制系統如SVN等都有分支管理，但是用過之後你會發現，這些版本控制系統建立和切換分支比蝸牛還慢，簡直讓人無法忍受。但Git的分支是與衆不同的，無論建立、切換和删除分支，Git在1秒鐘之内就能完成！無論你的版本庫檔案的多少。
6.1建立與合并分支
在版本回退裡，每次送出，Git都把它們串成一條時間線，這條時間線就是一個分支。截止到目前，隻有一條時間線，在Git裡，這個分支叫主分支，即
master
分支。
HEAD
嚴格來說不是指向送出，而是指向
master
，
master
才是指向送出的，是以，
HEAD
指向的就是目前分支。
一開始的時候，
master
分支是一條線，Git用
master
指向最新的送出，再用
HEAD
指向
master
，就能确定目前分支，以及目前分支的送出點：
每次送出，
master
分支都會向前移動一步，這樣，随着你不斷送出，
master
分支的線也越來越長。
當我們建立新的分支，例如
dev
時，Git建立了一個指針叫
dev
，指向
master
相同的送出，再把
HEAD
指向
dev
，就表示目前分支在
dev
上：
Git建立一個分支很快，因為除了增加一個
dev
指針，改改
HEAD
的指向，工作區的檔案都沒有任何變化！
不過，從現在開始，對工作區的修改和送出就是針對
dev
分支了，比如新送出一次後，
dev
指針往前移動一步，而
master
指針不變：
假如我們在
dev
上的工作完成了，就可以把
dev
合并到
master
上。Git怎麼合并呢？最簡單的方法，就是直接把
master
指向
dev
的目前送出，就完成了合并：
是以Git合并分支也很快！就改改指針，工作區内容也不變！
合并完分支後，甚至可以删除
dev
分支。删除
dev
分支就是把
dev
指針給删掉，删掉後，我們就剩下了一條
master
分支：
下面開始實戰。
首先，我們建立
dev
分支，然後切換到
dev
分支：
$ git checkout -b dev
Switched to a new branch 'dev'
git checkout
指令加上
-b
參數表示建立并切換，相當于以下兩條指令：
$ git branch dev
$ git checkout dev
Switched to branch 'dev' 然後，用
git branch
指令檢視目前分支：
$ git branch
* dev
master
git branch
指令會列出所有分支，目前分支前面會标一個
*
号。
然後，我們就可以在
dev
分支上正常送出，比如對
readme.txt
做個修改，加上一行：
Creating a new branch is quick. 然後送出：
$ git add readme.txt
$ git commit -m "branch test"
[dev b17d20e] branch test
1 file changed, 1 insertion(+) 現在，
dev
分支的工作完成，我們就可以切換回
master
分支：
$ git checkout master
Switched to branch 'master' 切換回
master
分支後，再檢視一個
readme.txt
檔案，剛才添加的内容不見了！因為那個送出是在
dev
分支上，而
master
分支此刻的送出點并沒有變：
現在，我們把
dev
分支的工作成果合并到
master
分支上：
$ git merge dev
Updating d46f35e..b17d20e
Fast-forward
readme.txt | 1 +
1 file changed, 1 insertion(+)
git merge
指令用于合并指定分支到目前分支。合并後，再檢視
readme.txt
的内容，就可以看到，和
dev
分支的最新送出是完全一樣的。
注意到上面的
Fast-forward
資訊，Git告訴我們，這次合并是“快進模式”，也就是直接把
master
指向
dev
的目前送出，是以合并速度非常快。
當然，也不是每次合并都能
Fast-forward
，我們後面會講其他方式的合并。
合并完成後，就可以放心地删除
dev
分支了：
$ git branch -d dev
Deleted branch dev (was b17d20e). 删除後，檢視
branch
，就隻剩下
master
分支了：
$ git branch
* master 因為建立、合并和删除分支非常快，是以Git鼓勵你使用分支完成某個任務，合并後再删掉分支，這和直接在
master
分支上工作效果是一樣的，但過程更安全。
6.2解決沖突
建立分支，繼續我們的新分支開發：
$ git checkout -b learngitnew
Switched to a new branch 'learngitnew' 修改
readme.txt
最後一行，改為：
aaaaaa 在learngitnew分支上送出：
$ git add readme.txt
$ git commit -m "aaaaa"
[feature1 14096d0] aaaaa
1 file changed, 1 insertion(+), 1 deletion(-) 切換到
master
分支：
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits) Git還會自動提示我們目前
master
分支比遠端的
master
分支要超前1個送出。在
master
分支上把
readme.txt
檔案的最後一行改為：
bbbbb 送出：
$ git add readme.txt
$ git commit -m "bbbbb"
[master 5dc6824] bbbbb
1 file changed, 1 insertion(+), 1 deletion(-) 現在，
master
分支和learngitnew分支各自都分别有新的送出，變成了這樣：
這種情況下，Git無法執行“快速合并”，隻能試圖把各自的修改合并起來，但這種合并就可能會有沖突，我們試試看：
$ git merge learngitnew
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.
readme.txt
檔案存在沖突，必須手動解決沖突後再送出。
git status
也可以告訴我們沖突的檔案：
$ git status
On branch master
Your branch is ahead of 'origin/master' by 2 commits.
(use "git push" to publish your local commits)
You have unmerged paths.
(fix conflicts and run "git commit")
(use "git merge --abort" to abort the merge)
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: readme.txt
no changes added to commit (use "git add" and/or "git commit -a") 我們可以直接檢視readme.txt的内容：
<<<<<<< HEAD
bbbbbb
=======
aaaaa
>>>>>>> feature1 Git用
<<<<<<<
，
=======
，
>>>>>>>
标記出不同分支的内容，我們修改如下後儲存：
Creating a new branch is quick and simple. 再送出：
$ git add readme.txt
$ git commit -m "conflict fixed"
[master cf810e4] conflict fixed 現在，
master
分支和
feature1
分支變成了下圖所示：
用帶參數的
git log
也可以看到分支的合并情況：
$ git log --graph --pretty=oneline --abbrev-commit
* 8bdf9f3 (HEAD -> master) fixed conflict
|\
| * 611a226 (learngitnew) aaaaaa
* | 6b7d064 bbbbb
|/
* f011ebc dev add readme.txt
* 5e50a6c (origin/master) change xaxaxa
* 268f236 change fafaf
* 52947eb add file.c 6.3分支管理政策
通常，合并分支時，Git會用
Fast forward
模式，但這種模式下，删除分支後，會丢掉分支資訊。如果要強制禁用
Fast forward
模式，Git就會在merge時生成一個新的commit，這樣，從分支曆史上就可以看出分支資訊。
下面我們實戰一下
--no-ff
方式的
git merge
：
首先，仍然建立并切換
dev
分支：
$ git checkout -b dev
Switched to a new branch 'dev' 修改readme.txt檔案，并送出一個新的commit：
$ git add readme.txt
$ git commit -m "add merge"
[dev f52c633] add merge
1 file changed, 1 insertion(+) 現在，我們切換回
master
：
$ git checkout master
Switched to branch 'master' 準備合并
dev
分支，請注意
--no-ff
參數，表示禁用
Fast forward
：
$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
readme.txt | 1 +
1 file changed, 1 insertion(+) 因為本次合并要建立一個新的commit，是以加上
-m
參數，把commit描述寫進去。合并後，我們用
git log
看看分支曆史：
$ git log --graph --pretty=oneline --abbrev-commit
* e1e9c68 (HEAD -> master) merge with no-ff
|\
| * f52c633 (dev) add merge
|/
* cf810e4 conflict fixed
... 可以看到，不使用
Fast forward
模式，merge後就像這樣：
分支政策
在實際開發中，我們應該按照幾個基本原則進行分支管理：
首先，
master
分支應該是非常穩定的，也就是僅用來釋出新版本，平時不能在上面幹活；那在哪幹活呢？幹活都在
dev
分支上，也就是說，
dev
分支是不穩定的，到某個時候，比如1.0版本釋出時，再把
dev
分支合并到
master
上，在
master
分支釋出1.0版本；你和你的小夥伴們每個人都在
dev
分支上幹活，每個人都有自己的分支，時不時地往
dev
分支上合并就可以了。
是以，團隊合作的分支看起來就像這樣：
注意：合并分支時，加上
--no-ff
參數就可以用普通模式合并，合并後的曆史有分支，能看出來曾經做過合并，而
fast forward
合并就看不出來曾經做過合并。
6.4bug分支（git stash）
在修複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: f52c633 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.
(use "git push" to publish your local commits)
$ git checkout -b issue-101
Switched to a new branch 'issue-101' 現在修複bug，需要把“aaaaaa”改為“aaaaa”去掉一個a，然後送出：
$ git add readme.txt
$ git commit -m "fix bug 101"
[issue-101 4c805e2] 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 6 commits.
(use "git push" to publish your local 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(-) 太棒了，原計劃兩個小時的bug修複隻花了5分鐘！現在，是時候接着回到
dev
分支幹活了！
$ git checkout dev
Switched to branch 'dev'
$ git status
On branch dev
nothing to commit, working tree clean 工作區是幹淨的，剛才的工作現場存到哪去了？用
git stash list
指令看看：
$ git stash list
stash@{0}: WIP on dev: f52c633 add merge 工作現場還在，Git把stash内容存在某個地方了，但是需要恢複一下，有兩個辦法：
一是用
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} (5d677e2ee266f39ea296182fb2354265b91b3b2a) 再用
git stash list
檢視，就看不到任何stash内容了：
$ git stash list 你可以多次stash，恢複的時候，先用
git stash list
檢視，然後恢複指定的stash，用指令：
$ git stash apply stash@{0} 另外
在master分支上修複了bug後，我們要想一想，dev分支是早期從master分支分出來的，是以，這個bug其實在目前dev分支上也存在。那怎麼在dev分支上修複同樣的bug？重複操作一次，送出不就行了？有木有更簡單的方法？有！
同樣的bug，要在dev上修複，我們隻需要把
4c805e2 fix bug 101
這個送出所做的修改“複制”到dev分支。注意：我們隻想複制
4c805e2 fix bug 101
這個送出所做的修改，并不是把整個master分支merge過來。
為了友善操作，Git專門提供了一個
cherry-pick
指令，讓我們能複制一個特定的送出到目前分支：
$ git branch
* dev
master
$ git cherry-pick 4c805e2
[master 1d4b803] fix bug 101
1 file changed, 1 insertion(+), 1 deletion(-) Git自動給dev分支做了一次送出，注意這次送出的commit是
1d4b803
，它并不同于master的
4c805e2
，因為這兩個commit隻是改動相同，但确實是兩個不同的commit。用
git cherry-pick
，我們就不需要在dev分支上手動再把修bug的過程重複一遍。
有些聰明的童鞋會想了，既然可以在master分支上修複bug後，在dev分支上可以“重放”這個修複過程，那麼直接在dev分支上修複bug，然後在master分支上“重放”行不行？當然可以，不過你仍然需要
git stash
指令儲存現場，才能從dev分支切換到master分支。
6.5 Feature分支
軟體開發中，總有無窮無盡的新的功能要不斷添加進來。添加一個新功能時，你肯定不希望因為一些實驗性質的代碼，把主分支搞亂了，是以，每添加一個新功能，最好建立一個feature分支，在上面開發，完成後，合并，最後，删除該feature分支。現在，你終于接到了一個新任務：開發代号為Vulcan的新功能，該功能計劃用于下一代星際飛船。
于是準備開發：
$ git checkout -b feature-vulcan
Switched to a new branch 'feature-vulcan' 5分鐘後，開發完畢：
$ git add vulcan.py
$ git status
On branch feature-vulcan
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: vulcan.py
$ git commit -m "add feature vulcan"
[feature-vulcan 287773e] add feature vulcan
1 file changed, 2 insertions(+)
create mode 100644 vulcan.py 切回
dev
，準備合并：
$ git checkout dev 一切順利的話，feature分支和bug分支是類似的，合并，然後删除。
但是！就在此時，接到上級指令，因經費不足，新功能必須取消！雖然白幹了，但是這個包含機密資料的分支還是必須就地銷毀：
$ git branch -d feature-vulcan
error: The branch 'feature-vulcan' is not fully merged.
If you are sure you want to delete it, run 'git branch -D feature-vulcan'. 銷毀失敗。Git友情提醒，
feature-vulcan
分支還沒有被合并，如果删除，将丢失掉修改，如果要強行删除，需要使用大寫的
-D
參數。
現在我們強行删除：
$ git branch -D feature-vulcan
Deleted branch feature-vulcan (was 287773e). 6.6多人協作
多人協作的工作模式通常是這樣：
- 首先，可以試圖用
git push origin <branch-name>
- 如果推送失敗，則因為遠端分支比你的本地更新，需要先用
git pull
- 如果合并有沖突，則解決沖突，并在本地送出；
- 沒有沖突或者解決掉沖突後，再用
git push origin <branch-name>
如果
git pull
提示
no tracking information
，則說明本地分支和遠端分支的連結關系沒有建立，用指令
git branch --set-upstream-to <branch-name> origin/<branch-name>
。
這就是多人協作的工作模式，一旦熟悉了，就非常簡單。
小結
- 檢視遠端庫資訊，使用
git remote -v
- 本地建立的分支如果不推送到遠端，對其他人就是不可見的；
- 從本地推送分支，使用
git push origin branch-name
git pull
- 在本地建立和遠端分支對應的分支，使用
git checkout -b branch-name origin/branch-name
- 建立本地分支和遠端分支的關聯，使用
git branch --set-upstream branch-name origin/branch-name
- 從遠端抓取分支，使用
git pull
6.7 rebase
多人在同一個分支上協作時，很容易出現沖突。即使沒有沖突，後push的童鞋不得不先pull，在本地合并，然後才能push成功。
每次合并再push後，分支變成了這樣：
$ git log --graph --pretty=oneline --abbrev-commit
* d1be385 (HEAD -> master, origin/master) init hello
* e5e69f1 Merge branch 'dev'
|\
| * 57c53ab (origin/dev, dev) fix env conflict
| |\
| | * 7a5e5dd add env
| * | 7bd91f1 add new env
| |/
* | 12a631b merged bug fix 101
|\ \
| * | 4c805e2 fix bug 101
|/ /
* | e1e9c68 merge with no-ff
|\ \
| |/
| * f52c633 add merge
|/
* cf810e4 conflict fixed 總之看上去很亂，有強迫症的童鞋會問：為什麼Git的送出曆史不能是一條幹淨的直線？
其實是可以做到的！
Git有一種稱為rebase的操作，有人把它翻譯成“變基”。
先不要随意展開想象。我們還是從實際問題出發，看看怎麼把分叉的送出變成直線。
在和遠端分支同步後，我們對
hello.py
這個檔案做了兩次送出。用
git log
指令看看：
$ git log --graph --pretty=oneline --abbrev-commit
* 582d922 (HEAD -> master) add author
* 8875536 add comment
* d1be385 (origin/master) init hello
* e5e69f1 Merge branch 'dev'
|\
| * 57c53ab (origin/dev, dev) fix env conflict
| |\
| | * 7a5e5dd add env
| * | 7bd91f1 add new env
... 注意到Git用
(HEAD -> master)
和
(origin/master)
辨別出目前分支的HEAD和遠端origin的位置分别是
582d922 add author
和
d1be385 init hello
，本地分支比遠端分支快兩個送出。
現在我們嘗試推送本地分支：
$ git push origin master
To github.com:michaelliao/learngit.git
! [rejected] master -> master (fetch first)
error: failed to push some refs to '[email protected]:michaelliao/learngit.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details. 很不幸，失敗了，這說明有人先于我們推送了遠端分支。按照經驗，先pull一下：
$ git pull
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (1/1), done.
remote: Total 3 (delta 1), reused 3 (delta 1), pack-reused 0
Unpacking objects: 100% (3/3), done.
From github.com:michaelliao/learngit
d1be385..f005ed4 master -> origin/master
* [new tag] v1.0 -> v1.0
Auto-merging hello.py
Merge made by the 'recursive' strategy.
hello.py | 1 +
1 file changed, 1 insertion(+) 再用
git status
看看狀态：
$ git status
On branch master
Your branch is ahead of 'origin/master' by 3 commits.
(use "git push" to publish your local commits)
nothing to commit, working tree clean 加上剛才合并的送出，現在我們本地分支比遠端分支超前3個送出。
用
git log
看看：
$ git log --graph --pretty=oneline --abbrev-commit
* e0ea545 (HEAD -> master) Merge branch 'master' of github.com:michaelliao/learngit
|\
| * f005ed4 (origin/master) set exit=1
* | 582d922 add author
* | 8875536 add comment
|/
* d1be385 init hello
... 對強迫症童鞋來說，現在事情有點不對頭，送出曆史分叉了。如果現在把本地分支push到遠端，有沒有問題？
有！
什麼問題？
不好看！
有沒有解決方法？
有！
這個時候，rebase就派上了用場。我們輸入指令
git rebase
試試：
$ git rebase
First, rewinding head to replay your work on top of it...
Applying: add comment
Using index info to reconstruct a base tree...
M hello.py
Falling back to patching base and 3-way merge...
Auto-merging hello.py
Applying: add author
Using index info to reconstruct a base tree...
M hello.py
Falling back to patching base and 3-way merge...
Auto-merging hello.py 輸出了一大堆操作，到底是啥效果？再用
git log
看看：
$ git log --graph --pretty=oneline --abbrev-commit
* 7e61ed4 (HEAD -> master) add author
* 3611cfe add comment
* f005ed4 (origin/master) set exit=1
* d1be385 init hello
... 原本分叉的送出現在變成一條直線了！這種神奇的操作是怎麼實作的？其實原理非常簡單。我們注意觀察，發現Git把我們本地的送出“挪動”了位置，放到了
f005ed4 (origin/master) set exit=1
之後，這樣，整個送出曆史就成了一條直線。rebase操作前後，最終的送出内容是一緻的，但是，我們本地的commit修改内容已經變化了，它們的修改不再基于
d1be385 init hello
，而是基于
f005ed4 (origin/master) set exit=1
，但最後的送出
7e61ed4
内容是一緻的。
這就是rebase操作的特點：把分叉的送出曆史“整理”成一條直線，看上去更直覺。缺點是本地的分叉送出已經被修改過了。
最後，通過push操作把本地分支推送到遠端：
Mac:~/learngit michael$ git push origin master
Counting objects: 6, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (6/6), 576 bytes | 576.00 KiB/s, done.
Total 6 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 1 local object.
To github.com:michaelliao/learngit.git
f005ed4..7e61ed4 master -> master 再用
git log
看看效果：
$ git log --graph --pretty=oneline --abbrev-commit
* 7e61ed4 (HEAD -> master, origin/master) add author
* 3611cfe add comment
* f005ed4 set exit=1
* d1be385 init hello
...