創(chuàng)建合并分支
在 Git 中，每次提交，Git 都會把他們串成一條時間線段，這個時間線就是分支。如下圖，目前只有一條時間線，在 Git 里面這個分支就是主分支，即master分支。HEAD嚴格來說不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是當前分支。
一開始的時候，master分支是一條線，Git用master 指向最新的提交，再用HEAD指向master，就能確定當前分支，以及當前分支的提交點：
每次提交，master分支都會向前移動一步，這樣，隨著你不斷提交，master分支的線也越來越長：
當我們創(chuàng)建新的分支，例如dev時，Git新建了一個指針叫dev，指向master相同的提交，再把HEAD指向dev，就表示當前分支在dev上：
在Git 上創(chuàng)建一個分支很快，因為只是增加了一個 dev指針，更新HEAD的指向，工作區(qū)沒有任何變化。
不過從現(xiàn)在開始，對工作區(qū)的修改和提交就是針對dev分支了，比如新提交一次后，dev指針往前移動一步，而master指針不變。
當我們在dev 上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最簡單的方法，就是直接把master指向dev的當前提交，就完成了合并：
所以Git合并分支也很快！就改改指針，工作區(qū)內(nèi)容也不變！
合并完分支后，甚至可以刪除dev分支。刪除dev分支就是把dev指針給刪掉，刪掉后，我們就剩下了一條master分支：
下面開始練習一下：
首先，我們創(chuàng)建dev分支，然后切換到dev分支：
$ git checkout -b dev
Switched to a new branch 'dev'
git checkout 命令加上-b參數(shù)表示創(chuàng)建并切換，相當于以下兩條命令：
$ 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 fec145a] branch test 1 file changed, 1 insertion(+)
現(xiàn)在，dev分支的工作完成，我們就可以切換回master分支：
$ git checkout master
Switched to branch 'master'
切換回master分支后，再查看一個readme.txt文件，剛才添加的內(nèi)容不見了！因為那個提交是在dev分支上，而master分支此刻的提交點并沒有變：
現(xiàn)在，我們把dev分支的工作成果合并到master分支上：
$ git merge dev
Updating d17efd8..fec145a
Fast-forward
readme.txt | 1 + 1 file changed, 1 insertion(+)
git merge 命令用于合并指定分支到當前分支。合并后，再查看readme.txt的內(nèi)容，就可以看到，和dev
分支的最新提交是完全一樣的。注意到上面的Fast-forward信息，Git告訴我們，這次合并是“快進模式”，也就是直接把master指向dev的當前提交，所以合并速度非常快。
當然，也不是每次合并都能Fast-forward，我們后面會講其他方式的合并。
合并完成后，就可以放心地刪除dev分支了：
$ git branch -d devDeleted branch dev (was fec145a).
刪除后，查看branch，就只剩下master分支了：
$ git branch
* master
因為創(chuàng)建、合并和刪除分支非常快，所以Git鼓勵你使用分支完成某個任務，合并后再刪掉分支，這和直接在master
分支上工作效果是一樣的，但過程更安全。
小結(jié)
Git鼓勵大量使用分支：
- 查看分支：
git branch - 創(chuàng)建分支：
git branch <name> - 切換分支：
git checkout <name> - 創(chuàng)建+切換分支：
git checkout -b <name> - 合并某分支到當前分支：
git merge <name> - 刪除分支：
git branch -d <name>
解決沖突
合并分支往往有可能出現(xiàn)沖突
準備新的feature1分支，繼續(xù)我們的新分支開發(fā)：
$ git checkout -b feature1
Switched to a new branch 'feature1'
修改readme.txt最后一行，改為：Creating a new branch is quick AND simple.
在feature1分支上提交：
$ git add readme.txt
$ git commit -m "AND simple"
[feature1 75a857c] AND simple
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.
Git提示我們當前master分支比遠程的master分支要超前1個提交。
在master分支上把readme.txt文件的最后一行改為：Creating a new branch is quick & simple.
提交：
$ git add readme.txt
$ git commit -m "& simple"
[master 400b400] & simple
1 file changed, 1 insertion(+), 1 deletion(-)
現(xiàn)在，master分支和feature1分支各自都分別有新的提交，變成了這樣：
這種情況下，Git無法執(zhí)行“快速合并”，只能試圖把各自的修改合并起來，但這種合并就可能會有沖突，我們試試看：
$ git merge feature1
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.
Git提示，readme.txt文件存在沖突，必須手動解決沖突后再提交。git status也可以告訴我們沖突的文件：
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 2 commits.
## Unmerged paths:# (use "git add/rm <file>..." as appropriate to mark resolution)
## both modified: readme.txt
#no changes added to commit (use "git add" and/or "git commit -a")
我們可以直接查看readme.txt的內(nèi)容：
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1
Git用<<<<<<<，=======，>>>>>>>
標記出不同分支的內(nèi)容，我們修改如下后保存：Creating a new branch is quick and simple.
再提交：
$ git add readme.txt
$ git commit -m "conflict fixed"
[master 59bc1cb] conflict fixed
現(xiàn)在，master分支和feature1分支變成了下圖所示：
用帶參數(shù)的git log也可以看到分支的合并情況：
$ git log --graph --pretty=oneline --abbrev-commit
* 59bc1cb conflict fixed
|\
| * 75a857c AND simple
* | 400b400 & simple
|/
* fec145a branch test
...
最后，刪除feature1分支：
$ git branch -d feature1
Deleted branch feature1 (was 75a857c).
工作完成。
小結(jié)
當Git無法自動合并分支時，就必須首先解決沖突。解決沖突后，再提交，合并完成。
用git log --graph命令可以看到分支合并圖。
分支管理策略
通常，合并分支時，如果可能，Git會用Fast forward 模式，但這種模式下，刪除分支后，會丟掉分支信息。
如果要強制禁用Fast forward 模式，Git就會在merge時生成一個新的commit，這樣，從分支歷史上就可以看出分支信息。
下面我們使用一下--no-ff方式的git merge：
首先，仍然創(chuàng)建并切換dev分支：
$ git checkout -b dev
Switched to a new branch 'dev'
修改readme.txt文件，并提交一個新的commit：
$ git add readme.txt
$ git commit -m "add merge"
[dev 6224937] add merge 1 file changed, 1 insertion(+)
現(xiàn)在，我們切換回master：
$ git checkout master
Switched to branch 'master'
準備合并dev分支，請注意--no-ff參數(shù)，表示禁用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(+)
因為本次合并要創(chuàng)建一個新的commit，所以加上-m參數(shù)，把commit描述寫進去。
合并后，我們用git log看看分支歷史：
$ git log --graph --pretty=oneline --abbrev-commit
* 7825a50 merge with no-ff
|\
| * 6224937 add merge
|/
* 59bc1cb conflict fixed
...
可以看到，不使用Fast forward模式，merge后就像這樣：
分支策略
在實際開發(fā)中，我們應該按照幾個基本原則進行分支管理：
首先，master分支應該是非常穩(wěn)定的，也就是僅用來發(fā)布新版本，平時不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是說，dev分支是不穩(wěn)定的，到某個時候，比如1.0版本發(fā)布時，再把dev分支合并到master上，在master分支發(fā)布1.0版本；
你和你的小伙伴們每個人都在dev分支上干活，每個人都有自己的分支，時不時地往dev分支上合并就可以了。
所以，團隊合作的分支看起來就像這樣：
小結(jié)
Git分支十分強大，在團隊開發(fā)中應該充分應用。
合并分支時，加上--no-ff參數(shù)就可以用普通模式合并，合并后的歷史有分支，能看出來曾經(jīng)做過合并，而fast forward合并就看不出來曾經(jīng)做過合并。
Bug分支
軟件開發(fā)中，bug就像家常便飯一樣。有了bug就需要修復.
在Git中,每個bug都可以通過一個新的臨時分支來修復，修復后，合并分支，然后將臨時分支刪除。
當你接到一個修復一個代號101的bug的任務時，很自然地，你想創(chuàng)建一個分支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天時間。但是，必須在兩個小時內(nèi)修復該bug，怎么辦？
Git還提供了一個stash功能，可以把當前工作現(xiàn)場“儲藏”起來，等以后恢復現(xiàn)場后繼續(xù)工作：
$ git stash
Saved working directory and index state WIP on dev: 6224937 add merge
HEAD is now at 6224937 add merge
現(xiàn)在，用git status查看工作區(qū)，就是干凈的（除非有沒有被Git管理的文件），因此可以放心地創(chuàng)建分支來修復bug。
首先確定要在哪個分支上修復bug，假定需要在master分支上修復，就從master創(chuàng)建臨時分支：
$ 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'
現(xiàn)在修復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).
bug修復完成！現(xiàn)在，是時候接著回到dev分支干活了！
$ git checkout dev
Switched to branch 'dev'
$ git status
# On branch dev
nothing to commit (working directory clean)
工作區(qū)是干凈的，剛才的工作現(xiàn)場存到哪去了？用git stash list命令看看：
$ git stash list
stash@{0}: WIP on dev: 6224937 add merge
工作現(xiàn)場還在，Git把stash內(nèi)容存在某個地方了，但是需要恢復一下，有兩個辦法：
一是用git stash apply恢復，但是恢復后，stash內(nèi)容并不刪除，你需要用git stash drop來刪除；
另一種方式是用git stash pop，恢復的同時把stash內(nèi)容也刪了：
$ 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內(nèi)容了：
$ git stash list
你可以多次stash，恢復的時候，先用git stash list查看，然后恢復指定的stash，用命令：
$ git stash apply stash@{0}
小結(jié)
修復bug時，我們會通過創(chuàng)建新的bug分支進行修復，然后合并，最后刪除；
當手頭工作沒有完成時，先把工作現(xiàn)場 git stash一下，然后去修復bug，修復后，再git stash pop，回到工作現(xiàn)場。
Feature分支
軟件開發(fā)中，總有無窮無盡的新的功能要不斷添加進來。
添加一個新功能時，你肯定不希望因為一些實驗性質(zhì)的代碼，把主分支搞亂了，所以，每添加一個新功能，最好新建一個feature分支，在上面開發(fā)，完成后，合并，最后，刪除該feature分支。
現(xiàn)在，你終于接到了一個新任務：開發(fā)代號為Vulcan的新功能，該功能計劃用于下一代星際飛船。
于是準備開發(fā)：
$ git checkout -b feature-vulcan
Switched to a new branch 'feature-vulcan'
5分鐘后，開發(fā)完畢：
$ 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 756d4af] add feature vulcan
1 file changed, 2 insertions(+)
create mode 100644 vulcan.py
切回dev，準備合并：
$ git checkout dev
一切順利的話，feature分支和bug分支是類似的，合并，然后刪除。
但是，就在此時，接到上級命令，因經(jīng)費不足，新功能必須取消！
雖然白干了，但是這個分支還是必須就地銷毀：
$ 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分支還沒有被合并，如果刪除，將丟失掉修改，如果要強行刪除，需要使用命令git branch -D feature-vulcan。
現(xiàn)在我們強行刪除：
$ git branch -D feature-vulcan
Deleted branch feature-vulcan (was 756d4af).
終于刪除成功！
小結(jié)
開發(fā)一個新feature，最好新建一個分支；
如果要丟棄一個沒有被合并過的分支，可以通過git branch -D <name>強行刪除。
多人協(xié)作
當你從遠程倉庫克隆時，實際上Git自動把本地的master分支和遠程的master分支對應起來了，并且，遠程倉庫的默認名稱是origin。
要查看遠程庫的信息
要查看遠程庫的信息，用 git remote：
$ git remote
origin
或者，用git remote -v 顯示更詳細的信息：
$ git remote -vorigin
git@github.com:michaelliao/learngit.git (fetch)origin
git@github.com:michaelliao/learngit.git (push)
上面顯示了可以抓取和推送的origin的地址。如果沒有推送權限，就看不到push的地址。
推送分支
推送分支，就是把該分支上的所有本地提交推送到遠程庫。
推送時，要指定本地分支，這樣，Git就會把該分支推送到遠程庫對應的遠程分支上：
$ git push origin master
如果要推送其他分支，比如dev，就改成：
$ git push origin dev
但是，并不是一定要把本地分支往遠程推送，那么，哪些分支需要推送，哪些不需要呢？
master分支是主分支，因此要時刻與遠程同步；
dev分支是開發(fā)分支，團隊所有成員都需要在上面工作，所以也需要與遠程同步；
bug分支只用于在本地修復bug，就沒必要推到遠程了，除非老板要看看你每周到底修復了幾個bug；
feature分支是否推到遠程，取決于你是否和你的小伙伴合作在上面開發(fā)。
抓取分支
多人協(xié)作時，大家都會往master和dev分支上推送各自的修改。
現(xiàn)在，模擬一個你的小伙伴，可以在另一臺電腦（注意要把SSH Key添加到GitHub）或者同一臺電腦的另一個目錄下克隆：
$ git clone git@github.com:XXX/learngit.git
Cloning into 'learngit'...
remote: Counting objects: 46, done.
remote: Compressing objects: 100% (26/26), done.
remote: Total 46 (delta 16), reused 45 (delta 15)
Receiving objects: 100% (46/46), 15.69 KiB | 6 KiB/s, done.
Resolving deltas: 100% (16/16), done.
當你的小伙伴從遠程庫clone時，默認情況下，你的小伙伴只能看到本地的master分支。不信可以用git branch命令看看：
$ git branch
* master
現(xiàn)在，你的小伙伴要在dev分支上開發(fā)，就必須創(chuàng)建遠程origin的dev分支到本地，于是他用這個命令創(chuàng)建本地dev分支：
$ git checkout -b dev origin/dev
現(xiàn)在，他就可以在dev上繼續(xù)修改，然后，時不時地把dev分支push到遠程：
$ git commit -m "add /usr/bin/env"
[dev 291bea8] add /usr/bin/env
1 file changed, 1 insertion(+)
$ git push origin dev
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 349 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@github.com:michaelliao/learngit.git
fc38031..291bea8 dev -> dev
你的小伙伴已經(jīng)向origin/dev分支推送了他的提交，而碰巧你也對同樣的文件作了修改，并試圖推送：
$ git add hello.py
$ git commit -m "add coding: utf-8"
[dev bd6ae48] add coding: utf-8
1 file changed, 1 insertion(+)
$ git push origin dev
To git@github.com:michaelliao/learngit.git
! [rejected] dev -> dev (non-fast-forward)
error: failed to push some refs to 'git@github.com:michaelliao/learngit.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
推送失敗，因為你的小伙伴的最新提交和你試圖推送的提交有沖突，解決辦法也很簡單，Git已經(jīng)提示我們，先用 git pull 把最新的提交從origin/dev 抓下來，然后，在本地合并，解決沖突，再推送：
$ git pull
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 3 (delta 0)
Unpacking objects: 100% (3/3), done.
From github.com:michaelliao/learngit
fc38031..291bea8 dev -> origin/dev
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details
git pull <remote> <branch>
If you wish to set tracking information for this branch you can do so with:
git branch --set-upstream dev origin/<branch>
git pull 也失敗了，原因是沒有指定本地dev分支與遠程origin/dev分支的鏈接，根據(jù)提示，設置dev
和origin/dev的鏈接：
$ git branch --set-upstream dev origin/dev
Branch dev set up to track remote branch dev from origin.
再pull：
$ git pull
Auto-merging hello.py
CONFLICT (content): Merge conflict in hello.py
Automatic merge failed; fix conflicts and then commit the result.
這回git pull
成功，但是合并有沖突，需要手動解決，解決的方法和分支管理中的解決沖突
$ git commit -m "merge & fix hello.py"
[dev adca45d] merge & fix hello.py
$ git push origin dev
Counting objects: 10, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (6/6), 747 bytes, done.
Total 6 (delta 0), reused 0 (delta 0)
To git@github.com:michaelliao/learngit.git
291bea8..adca45d dev -> dev
因此，多人協(xié)作的工作模式通常是這樣：
首先，可以試圖用git push origin branch-name推送自己的修改；
如果推送失敗，則因為遠程分支比你的本地更新，需要先用git pull試圖合并；
如果合并有沖突，則解決沖突，并在本地提交；
沒有沖突或者解決掉沖突后，再用git push origin branch-name
推送就能成功！
如果git pull
提示“no tracking information”，則說明本地分支和遠程分支的鏈接關系沒有創(chuàng)建，用命令git branch --set-upstream branch-name origin/branch-name。
這就是多人協(xié)作的工作模式，一旦熟悉了，就非常簡單。
小結(jié)
- 查看遠程庫信息，使用
git remote -v - 本地新建的分支如果不推送到遠程，對其他人就是不可見的
- 從本地推送分支，使用
git push origin branch-name，如果推送失敗，先用git pull
抓取遠程的新提交 - 在本地創(chuàng)建和遠程分支對應的分支，使用
git checkout -b branch-name origin/branch-name，本地和遠程分支的名稱最好一致 - 建立本地分支和遠程分支的關聯(lián)，使用
git branch --set-upstream branch-name origin/branch-name - 從遠程抓取分支，使用
git pull，如果有沖突，要先處理沖突。
