前言
分支就是科幻電影里面的平行宇宙，當你正在電腦前努力學習Git的時候，另一個你正在另一個平行宇宙里努力學習SVN。如果兩個平行宇宙互不干擾，那對現在的你也沒啥影響。不過，在某個時間點，兩個平行宇宙合并了，結果，你既學會了Git又學會了SVN！
正文
分支簡介
為了真正理解 Git 處理分支的方式，我們需要回顧一下Git是如何保存數據的。
Git 保存的不是文件的變化或者差異，而是一系列不同時刻的文件快照。在進行提交操作時，Git會保存一個提交對象（commit object）。知道了Git保存數據的方式，我們可以很自然的想到——該提交對象會包含一個指向暫存內容快照的指針。 但不僅僅是這樣，該提交對象還包含了作者的姓名和郵箱、提交時輸入的信息以及指向它的父對象的指針。首次提交產生的提交對象沒有父對象，普通提交操作產生的提交對象有一個父對象，而由多個分支合并產生的提交對象有多個父對象。
Git的分支，其實本質上僅僅是指向提交對象的可變指針。 Git的默認分支名字是 master。 在多次提交操作之后，你其實已經有一個指向最后那個提交對象的 master 分支。 它會在每次的提交操作中自動向前移動。
Git的 “master” 分支并不是一個特殊分支。它就跟其它分支完全沒有區別。 之所以幾乎每一個倉庫> 都有 master 分支，是因為git init命令默認創建它，并且大多數人都懶得去改動它。
分支在實際中有什么用呢？假設你準備開發一個新功能，但是需要兩周才能完成，第一周你寫了50%的代碼，如果立刻提交，由于代碼還沒寫完，不完整的代碼庫會導致別人不能干活了。如果等代碼全部寫完再一次提交，又存在丟失每天進度的巨大風險。
現在有了分支，就不用怕了。你創建了一個屬于你自己的分支，別人看不到，還繼續在原來的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到開發完畢后，再一次性合并到原來的分支上，這樣，既安全，又不影響別人工作。
其他版本控制系統如SVN等都有分支管理，但是用過之后你會發現，這些版本控制系統創建和切換分支比蝸牛還慢，簡直讓人無法忍受，結果分支功能成了擺設，大家都不去用。
但Git的分支是與眾不同的，無論創建、切換和刪除分支，Git在1秒鐘之內就能完成！無論你的版本庫是1個文件還是1萬個文件。
分支創建
Git是怎么創建新分支的呢？ 很簡單，它只是為你創建了一個可以移動的新的指針。 比如，創建一個 testing分支， 你需要使用 git branch 命令：
$ git branch testing
這會在當前所在的提交對象上創建一個指針。
那么，Git又是怎么知道當前在哪一個分支上呢？ 也很簡單，它有一個名為 HEAD 的特殊指針。 請注意它和許多其它版本控制系統（如 Subversion 或 CVS）里的 HEAD 概念完全不同。 在 Git中，它是一個指針，指向當前所在的本地分支（譯注：將 HEAD 想象為當前分支的別名）。 在本例中，你仍然在master 分支上。 因為 git branch 命令僅僅 創建 一個新分支，并不會自動切換到新分支中去。
你可以簡單地使用 git log 命令查看各個分支當前所指的對象。 提供這一功能的參數是 --decorate。
$ git log --oneline --decorate
f30ab (HEAD, master, testing) add feature #32 - ability to add new
34ac2 fixed bug #1328 - stack overflow under certain conditions
98ca9 initial commit of my project
正如你所見，當前 “master” 和 “testing” 分支均指向校驗和以 f30ab 開頭的提交對象。
分支切換
要切換到一個已存在的分支，你需要使用git checkout命令。 我們現在切換到新創建的 testing 分支去：
$ git checkout testing
這樣 HEAD 就指向 testing 分支了。
上面的創建分支和切換分支命令可以合起來用下面這個命令來替代。
$ git checkout -b testing
那么，這樣的實現方式會給我們帶來什么好處呢？ 現在不妨再提交一次：
$ vim test.rb
$ git commit -a -m 'made a change'
如圖所示，你的
testing 分支向前移動了，但是 master 分支卻沒有，它仍然指向運行 git checkout 時所指的對象。 這就有意思了，現在我們切換回 master 分支看看：
$ git checkout master
這條命令做了兩件事。 一是使 HEAD 指回
master 分支，二是將工作目錄恢復成 master 分支所指向的快照內容。 也就是說，你現在做修改的話，項目將始于一個較舊的版本。 本質上來講，這就是忽略testing 分支所做的修改，以便于向另一個方向進行開發。可以使用
git branch命令查看當前分支，注意前面帶*的表示當前分支
Note
分支切換會改變你工作目錄中的文件
在切換分支時，一定要注意你工作目錄里的文件會被改變。 如果是切換到一個較舊的分支，你的工作目> 錄會恢復到該分支最后一次提交時的樣子。 如果Git不能干凈利落地完成這個任務，它將禁止切換分支。
合并分支（快速合并）
假如我們在testing上的工作完成了，就可以把testing合并到master上。Git怎么合并呢？最簡單的方法，就是直接把master指向testing的當前提交，就完成了合并，這里你需要使用git merge命令
$ git merge testing
Updating 64ba18a..760118b
Fast-forward
hello.txt | 1 +
1 file changed, 1 insertion(+)
create mode 100644 hello.txt
git merge命令用于合并指定分支到當前分支。合并后，再查看內容，就可以看到，和testing分支的最新提交是完全一樣的。
注意到上面的Fast-forward信息，Git告訴我們，這次合并是“快進模式”，也就是直接把master指向testing的當前提交，所以合并速度非常快。
當然，也不是每次合并都能Fast-forward，我們后面會講其他方式的合并。
刪除分支
合并完分支后，甚至可以刪除dev分支。刪除dev分支就是把dev指針給刪掉，刪掉后，我們就剩下了一條master分支,這里需要使用git branch -d命令來刪除分支
$ git branch -d testing
Deleted branch testing (was 760118b).
分支合并沖突
人生不如意之事十之八九，合并分支往往也不是一帆風順的。
準備新的dev分支，繼續我們的新分支開發：
$ git checkout -b dev
Switched to a new branch 'dev'
修改README.md內容，添加一樣內容"day day up~"，在dev分支上提交：
$ git commit -am "one commit"
[dev 6a6a08e] one commit
1 file changed, 1 insertion(+)
切換到master分支：
$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
Git還會自動提示我們當前master分支比遠程的master分支要超前1個提交。
在master分支上把README.md文件的最后改為 good good study,然后提價
$ git commit -am "two commit"
[master 75d6f25] two commit
1 file changed, 1 insertion(+)
現在，master分支和dev分支各自都分別有新的提交，變成了這樣：
這種情況下，Git無法執行“快速合并”，只能試圖把各自的修改合并起來，但這種合并就可能會有沖突，我們試試看：
$ git merge dev
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.
果然沖突了！Git告訴我們， README.md文件存在沖突，必須手動解決沖突后再提交。git status也可以告訴我們沖突的文件：
$ git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)
You have unmerged paths.
(fix conflicts and run "git commit")
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: README.md
no changes added to commit (use "git add" and/or "git commit -a")
我們可以直接查看README.md的內容：
$ cat README.md
#gitLearn
<<<<<<< HEAD
good good study
=======
day day up
>>>>>>> dev
Git用<<<<<<<，=======，>>>>>>>標記出不同分支的內容，我們修改如下后保存：
#gitLearn
good good study
day day up
再提交：
$ git commit -am 'merge commit'
[master 9a4d00b] merge commit
現在，master分支和dev分支變成了下圖所示：
用帶參數的git log也可以看到分支的合并情況：
$ git log --graph --pretty=oneline --abbrev-commit
* 9a4d00b merge commit
|\
| * 6a6a08e one commit
* | 75d6f25 two commit
|/
* ae06dcf 123
* 760118b test
* 64ba18a test
|\
| * 4392848 Accept Merge Request #1 test : (dev -> master)
| |\
| | * a430c4b update README.md
| |/
| * 88ec6d7 Initial commit
* 32d11c8 update README.md
* 8d5acc1 new file README
* e02f115 Initial commit
最后，刪除feature1分支：
$ git branch -d dev
Deleted branch dev (was 6a6a08e).
合并分支（普通合并）
通常，合并分支時，如果可能，Git會用Fast forward模式，但這種模式下，刪除分支后，會丟掉分支信息。
如果要強制禁用Fast forward模式，Git就會在merge時生成一個新的commit，這樣，從分支歷史上就可以看出分支信息。
下面我們實戰一下--no-ff方式的git merge：
首先，仍然創建并切換dev分支：
$ git checkout -b dev
Switched to a new branch 'dev'
修改README.md文件，并提交一個新的commit：
$ git commit -am 'submit'
[dev fee6025] submit
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.md | 1 +
1 file changed, 1 insertion(+)
因為本次合并要創建一個新的commit，所以加上-m參數，把commit描述寫進去。
合并后，我們用git log看看分支歷史：
$ git log --graph --pretty=oneline --abbrev-commit
* b98f802 merge with no-ff
|\
| * fee6025 submit
|/
* 9a4d00b merge commit
...
可以看到，不使用Fast forward模式，merge后就像這樣：
分支管理策略
實際公司開發的時候一般3個分支就可以了：
- mster 主分支用來發布
- dev 日常開發用的分支
- bug 修改bug用的分支
首先，master分支應該是非常穩定的，也就是僅用來發布新版本，平時不能在上面干活；
干活都在dev分支上，也就是說，dev分支是不穩定的，到某個時候，比如1.0版本發布時，再把dev分支合并到master上，在master分支發布1.0版本,你和你的小伙伴們每個人都在dev分支上干活，每個人都有自己的分支，時不時地往dev分支上合并就可以了；
bug分支用來處理日常bug,搞定后合到dev分支即可；
假設遠程公共倉庫，有一個master和一個dev分支，進行多人協作開發時候（每個人的公鑰必須加入到遠程賬號下，否則無法push）， 每個人都應該clone一份到本地。 但是clone的只是master，如果遠程的master和dev一樣，沒關系；如果不一致，則需要clone出dev分支 git checkout -b dev origin/dev 之后每個人在本地的dev分支上獨自開發（最好不要在mast上開發）， 開發完成之后push到遠程dev, git push origin dev。 之后審核人再確定是否合并dev到master。
團隊多人開發協作
當你從遠程倉庫克隆時，實際上Git自動把本地的master分支和遠程的master分支對應起來了，并且，遠程倉庫的默認名稱是origin。
要查看遠程庫的信息，用git remote：
$ git remote
origin
或者，用git remote -v顯示更詳細的信息：
$ git remote -v
origin git@git.coding.net:tengj/gitLearn.git (fetch)
origin git@git.coding.net:tengj/gitLearn.git (push)
上面顯示了可以抓取和推送的origin的地址。如果沒有推送權限，就看不到push的地址。
推送分支
推送分支，就是把該分支上的所有本地提交推送到遠程庫。推送時，要指定本地分支，這樣，Git就會把該分支推送到遠程庫對應的遠程分支上：
$ git push origin master
如果要推送其他分支，比如dev，就改成：
$ git push origin dev
抓取分支
多人協作時，大家都會往master和dev分支上推送各自的修改。
現在，模擬一個你的小伙伴，可以在另一臺電腦（注意要把SSH Key添加到GitHub）或者同一臺電腦的另一個目錄下克隆：
$ git clone git@git.coding.net:tengj/gitStudy.git
Cloning into 'gitStudy'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (3/3), done.
Checking connectivity... done.
當你的小伙伴從遠程庫clone時，默認情況下，你的小伙伴只能看到本地的master分支。不信可以用git branch命令看看：
$ git branch
* master
現在，你的小伙伴要在dev分支上開發，就必須創建遠程origin的dev分支到本地，于是他用這個命令創建本地dev分支（程分支dev要先創建）。
$ git checkout -b dev
git
創建dev分之后，先同步遠程服務器上的數據到本地
$ git fetch origin
From git.coding.net:tengj/gitStudy
* [new branch] dev -> origin/dev
現在，他就可以在dev上繼續修改，然后，時不時地把dev分支push到遠程：
$ git commit -am 'test'
[dev c120ad6] test
1 file changed, 1 insertion(+)
$ git push origin dev
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 262 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@git.coding.net:tengj/gitStudy.git
65c05aa..c120ad6 dev -> dev
你的小伙伴已經向origin/dev分支推送了他的提交，而碰巧你也對同樣的文件作了修改，并試圖推送：
$ git push origin dev
To git@git.coding.net:tengj/gitStudy.git
! [rejected] dev -> dev (fetch first)
error: failed to push some refs to 'git@git.coding.net:tengj/gitStudy.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.
推送失敗，因為你的小伙伴的最新提交和你試圖推送的提交有沖突，解決辦法也很簡單，Git已經提示我們，先用git pull把最新的提交從origin/dev抓下來，然后，在本地合并，解決沖突，再推送：
$ git pull origin dev
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From git.coding.net:tengj/gitStudy
* branch dev -> FETCH_HEAD
b7b87f4..f636337 dev -> origin/dev
Auto-merging a.txt
CONFLICT (content): Merge conflict in a.txt
Automatic merge failed; fix conflicts and then commit the result.
因此，多人協作的工作模式通常是這樣：
- 首先，可以試圖用
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分支管理就學完了，整理一下所學的命令，大體如下：
git branch 查看當前分支
git branch -v 查看每一個分支的最后一次提交
git branch -a 查看本地和遠程分支的情況
git branch --merged 查看已經與當前分支合并的分支
git branch --no-merged 查看已經與當前分支未合并的分支
git branch -r 查看遠程分支
git branch dev 創建分支 dev
git checkout dev 切換到分支dev
git checkout -b dev 創建并切換分支dev
git merge dev 名稱為dev的分支與當前分支合并
git branch -d dev 刪除分支dev
一直覺得自己寫的不是技術，而是情懷，一篇篇文章是自己這一路走來的痕跡。靠專業技能的成功是最具可復制性的，希望我的這條路能讓你少走彎路，希望我能幫你抹去知識的蒙塵，希望我能幫你理清知識的脈絡，希望未來技術之巔上有你也有我。
