分支介紹
每次提交，Git都把它們串成一條時間線，這條時間線就是一個分支。截止到目前，只有一條時間線，
在Git裏，這個分支叫主分支，即master分支。
HEAD嚴格來講不是指向提交，而是指向master，master纔是指向提交的，因此，HEAD指向的就是當前分支。git
HEAD表示當前版本github
一開始的時候，master分支是一條線，Git用master指向最新的提交，再用HEAD指向master，就能肯定當前分支，以及當前分支的提交點：
安全
每次提交，master分支都會向前移動一步，這樣，隨着你不斷提交，master分支的線也愈來愈長：app
命令
查看分支：git branchpost
建立分支：git branch <name>fetch
切換分支：git checkout <name>ui
建立+切換分支：git checkout -b <name>this
合併某分支到當前分支：git merge <name>指針
刪除分支：git branch -d <name>code
刪除沒有合併分支：·git branch -D <name>
合併某分支到當前分支（禁用Fast forward）：git merge --no-ff -m "merge with no-ff" <name>
bug修復
隱藏當前分支：git stash
查看隱藏列表：git stash list
兩種恢復方法：
（1）恢復後，再刪除，2條命令：
恢復隱藏工做區（恢復後，stash內容並不刪除，還須要drop）：git stash apply
刪除隱藏工做區：git stash drop
（2）直接恢復並刪除，1條命令：git stash pop
多個stash時，恢復某個工做區：git stash apply stash@{0}
多人協做
查看遠程庫信息：git remote，或者用git remote -v顯示更詳細的信息
本地推送分支：git push origin branch-name
遠程抓取分支：git pull
在本地建立和遠程分支對應的分支：git checkout -b <branch-name> origin/<branch-name>，本地和遠程分支的名稱最好一致
創建本地分支和遠程分支的關聯，使用git branch --set-upstream-to=origin/<branch-name> <branch-name>
建立與合併分支
分支過程
1.新建分支
2.提交分支修改
3.合併分支
4.刪除分支
當咱們建立新的分支，例如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.MD
$ 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.MD 文件，剛纔添加的內容不見了！由於那個提交是在dev分支上，而master分支此刻的提交點並無變：
如今，咱們把dev分支的工做成果合併到master分支上：
$ git merge dev
Updating d46f35e..b17d20e
Fast-forward
readme.MD | 1 +
1 file changed, 1 insertion(+)
git merge命令用於合併指定分支到當前分支。合併後，再查看readme.MD 的內容，就能夠看到，和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分支上工做效果是同樣的，但過程更安全。
解決衝突
（1）分支 feature1 分支修改
準備新的feature1分支，繼續咱們的新分支開發：
$ git checkout -b feature1
Switched to a new branch 'feature1'
修改readme.MD最後一行，改成：
Creating a new branch is quick AND simple.
在feature1分支上提交：
$ git add readme.MD
$ git commit -m "AND simple"
[feature1 14096d0] AND simple
1 file changed, 1 insertion(+), 1 deletion(-)
（2）分支master作修改
切換到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.MD文件的最後一行改成：
Creating a new branch is quick & simple.
提交：
$ git add readme.MD
$ git commit -m "& simple"
[master 5dc6824] & simple
1 file changed, 1 insertion(+), 1 deletion(-)
如今，master分支和feature1分支各自都分別有新的提交，變成了這樣：
（3）衝突發生
這種狀況下，Git沒法執行「快速合併」，只能試圖把各自的修改合併起來，但這種合併就可能會有衝突，咱們試試看：
$ git merge feature1
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 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.MD
no changes added to commit (use "git add" and/or "git commit -a")
（4）解決衝突
咱們能夠直接查看readme.MD的內容：
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1
Git用<<<<<<<，=======，>>>>>>>標記出不一樣分支的內容，咱們修改以下後保存：
Creating a new branch is quick and simple.
再提交：
$ git add readme.MD
$ git commit -m "conflict fixed"
[master cf810e4] conflict fixed
如今，master分支和feature1分支變成了下圖所示：
用帶參數的git log也能夠看到分支的合併狀況：
$ git log --graph --pretty=oneline --abbrev-commit
* cf810e4 (HEAD -> master) conflict fixed
|\
| * 14096d0 (feature1) AND simple
* | 5dc6824 & simple
|/
* b17d20e branch test
* d46f35e (origin/master) remove test.txt
* b84166e add test.txt
* 519219b git tracks changes
* e43a48b understand how stage works
* 1094adb append GPL
* e475afc add distributed
* eaadf4e wrote a readme file
最後，刪除feature1分支：
$ git branch -d feature1
Deleted branch feature1 (was 14096d0).
小結
當Git沒法自動合併分支時，就必須首先解決衝突。解決衝突後，再提交，合併完成。
解決衝突就是把Git合併失敗的文件手動編輯爲咱們但願的內容，再提交。
用git log --graph命令能夠看到分支合併圖。
分支管理策略
不用fast forward模式，使用普通模式合併分支
一般，合併分支時，若是可能，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分支上合併就能夠了。
因此，團隊合做的分支看起來就像這樣：
小結
Git分支十分強大，在團隊開發中應該充分應用。
合併分支時，加上--no-ff參數就能夠用普通模式合併，合併後的歷史有分支，能看出來曾經作過合併，而fast forward合併就看不出來曾經作過合併。
bug修復
軟件開發中，bug就像屢見不鮮同樣。有了bug就須要修復，在Git中，因爲分支是如此的強大，因此，每一個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，須要把「Git is free software ...」改成「Git is a free software ...」，而後提交：
$ 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}
小結
修復bug時，咱們會經過建立新的bug分支進行修復，而後合併，最後刪除；
當手頭工做沒有完成時，先把工做現場git stash一下，而後去修復bug，修復後，再git stash pop，回到工做現場。
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).
終於刪除成功！
多人協做
當你從遠程倉庫克隆時，實際上Git自動把本地的master分支和遠程的master分支對應起來了，而且，遠程倉庫的默認名稱是origin。
要查看遠程庫的信息，用git remote：
$ git remote
origin
或者，用git remote -v顯示更詳細的信息：
$ git remote -v
origin 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分支是開發分支，團隊全部成員都須要在上面工做，因此也須要與遠程同步；
bug分支只用於在本地修復bug，就不必推到遠程了，除非老闆要看看你每週到底修復了幾個bug；
feature分支是否推到遠程，取決於你是否和你的小夥伴合做在上面開發。
總之，就是在Git中，分支徹底能夠在本地本身藏着玩，是否推送，視你的心情而定！
抓取分支
多人協做時，你們都會往master和dev分支上推送各自的修改。
如今，模擬一個你的小夥伴，能夠在另外一臺電腦（注意要把SSH Key添加到GitHub）或者同一臺電腦的另外一個目錄下克隆：
$ git clone git@github.com:michaelliao/learngit.git
Cloning into 'learngit'...
remote: Counting objects: 40, done.
remote: Compressing objects: 100% (21/21), done.
remote: Total 40 (delta 14), reused 40 (delta 14), pack-reused 0
Receiving objects: 100% (40/40), done.
Resolving deltas: 100% (14/14), done.
當你的小夥伴從遠程庫clone時，默認狀況下，你的小夥伴只能看到本地的master分支。不信能夠用git branch命令看看：
$ git branch
* master
如今，你的小夥伴要在dev分支上開發，就必須建立遠程origin的dev分支到本地，因而他用這個命令建立本地dev分支：
$ git checkout -b dev origin/dev
如今，他就能夠在dev上繼續修改，而後，時不時地把dev分支push到遠程：
$ git add env.txt
$ git commit -m "add env"
[dev 7a5e5dd] add env
1 file changed, 1 insertion(+)
create mode 100644 env.txt
$ 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), 308 bytes | 308.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To github.com:michaelliao/learngit.git
f52c633..7a5e5dd dev -> dev
你的小夥伴已經向origin/dev分支推送了他的提交，而碰巧你也對一樣的文件做了修改，並試圖推送：
$ cat env.txt
env
$ git add env.txt
$ git commit -m "add new env"
[dev 7bd91f1] add new env
1 file changed, 1 insertion(+)
create mode 100644 env.txt
$ git push origin dev
To 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. Integrate the remote changes (e.g.
hint: '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
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-to=origin/<branch> dev
git pull也失敗了，緣由是沒有指定本地dev分支與遠程origin/dev分支的連接，根據提示，設置dev和origin/dev的連接：
$ git branch --set-upstream-to=origin/dev dev
Branch 'dev' set up to track remote branch 'dev' from 'origin'.
再pull：
$ git pull
Auto-merging env.txt
CONFLICT (add/add): Merge conflict in env.txt
Automatic merge failed; fix conflicts and then commit the result.
這回git pull成功，可是合併有衝突，須要手動解決，解決的方法和分支管理中的解決衝突徹底同樣。解決後，提交，再push：
$ git commit -m "fix env conflict"
[dev 57c53ab] fix env conflict
$ git push origin dev
Counting objects: 6, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (6/6), 621 bytes | 621.00 KiB/s, done.
Total 6 (delta 0), reused 0 (delta 0)
To github.com:michaelliao/learngit.git
7a5e5dd..57c53ab dev -> dev
所以，多人協做的工做模式一般是這樣：
首先，能夠試圖用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，若是有衝突，要先處理衝突。
參考
廖雪峯的git教程