學習筆記，非原創。謝謝
Git鼓勵大量使用分支：
創建與合并分支 ：
查看分支：git branch
創建分支：git branch <name>
切換分支：git checkout <name>
創建+切換分支：git checkout -b <name>
合并某分支到當前分支：git merge <name>
刪除分支：git branch -d <name>
我們創建dev分支，然后切換到dev分支：
git checkout命令加上-b參數表示創建并切換，相當于以下兩條命令：
$ git branch dev
$ git checkout devSwitchedto branch'dev'
然后，用git branch命令查看當前分支：
git branch命令會列出所有分支，當前分支前面會標一個*號。
然后，我們就可以在dev分支上正常提交，
現在，dev分支的工作完成，我們就可以切換回master分支：
切換回master分支后，再查看一個readme.txt文件，剛才添加的內容不見了！因為那個提交是在dev分支上，而master分支此刻的提交點并沒有變：
現在，我們把dev分支的工作成果合并到master分支上：
git merge命令用于合并指定分支到當前分支。合并后，再查看readme.txt的內容，就可以看到，和dev分支的最新提交是完全一樣的。
注意到上面的Fast-forward信息，Git告訴我們，這次合并是“快進模式”，也就是直接把master指向dev的當前提交，所以合并速度非常快。
當然，也不是每次合并都能Fast-forward，我們后面會講其他方式的合并。
合并完成后，就可以放心地刪除dev分支了：
刪除后，查看branch，就只剩下master分支了：
因為創建、合并和刪除分支非常快，所以Git鼓勵你使用分支完成某個任務，合并后再刪掉分支，這和直接在master分支上工作效果是一樣的，但過程更安全
分支策略
在實際開發中，我們應該按照幾個基本原則進行分支管理：
首先，master分支應該是非常穩定的，也就是僅用來發布新版本，平時不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是說，dev分支是不穩定的，到某個時候，比如1.0版本發布時，再把dev分支合并到master上，在master分支發布1.0版本；
你和你的小伙伴們每個人都在dev分支上干活，每個人都有自己的分支，時不時地往dev分支上合并就可以了。
所以，團隊合作的分支看起來就像這樣：
Bug 分支
修復bug時，我們會通過創建新的bug分支進行修復，然后合并，最后刪除；
當手頭工作沒有完成時，先把工作現場git stash一下，然后去修復bug，修復后，再git stash pop，回到工作現場。
$ git stash
Savedworking directoryandindex stateWIPondev:f52c633 add merge
用git status查看工作區，就是干凈的（除非有沒有被Git管理的文件），因此可以放心地創建分支來修復bug。
首先確定要在哪個分支上修復bug，假定需要在master分支上修復，就從master創建臨時分支：
$ git checkout master
Switchedto 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 add readme.txt
$ git commit -m"fix bug 101"
[issue-1014c805e2] fix bug101
1file changed,1insertion(+),1deletion(-)
修復完成后，切換到master分支，并完成合并，最后刪除issue-101分支：
$ git checkout master
Switchedto branch'master'
Yourbranch is ahead of'origin/master'by6commits.??
(use"git push"to publish your local commits)
$ git merge --no-ff -m "merged bug fix 101" issue-101
Mergemade by the'recursive'strategy.
?readme.txt |2+-
1file changed,1insertion(+),1deletion(-)
回到dev分支繼續工作
$ git checkout dev
Switchedto branch'dev'
$ git status
Onbranch dev
nothing to commit, working tree clean
工作區是干凈的，用git stash list命令查看
$ git stash list
stash@{0}: WIP on dev:f52c633 add merge
工作現場還在，恢復工作現場：
一是用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..." to unstage)?
?new file: hello.py
Changes not staged for commit:
?(use "git add..." to update what will be committed)?
(use "git checkout --..." to discard changes in working dir ectory)?
?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}
Feature（功能）分支
開發一個新feature（功能），最好新建一個分支；
如果要丟棄一個沒有被合并過的分支，可以通過 git branch -D <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自動把本地的master分支和遠程的master分支對應起來了，并且，遠程倉庫的默認名稱是origin。
要查看遠程庫的信息，用git remote：
$ git remoteorigin
或者，用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
Cloninginto'learngit'...
remote:Countingobjects:40, done.
remote:Compressingobjects:100% (21/21), done.
remote:Total40(delta14), reused40(delta14), pack-reused0
Receivingobjects:100% (40/40), done.
Resolvingdeltas: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 7 a5e5dd] add env
1file 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),308bytes |308.00KiB/s, done.
Total 3 (delta0), reused 0 (delta0)
To github.com:michaelliao/learngit.git?
?f52c633..7a5e5dd? dev -> dev
你的小伙伴已經向origin/dev分支推送了他的提交，而碰巧你也對同樣的文件作了修改，并試圖推送：
$ cat env.txt
env
$ git add env.txt
$ gitcommit-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 informationforthe 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"
[dev57c53ab] 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.00KiB/s, done.
Total 6 (delta 0), reused 0 (delta 0)
To github.com:michaelliao/learngit.git
7a5e5dd..57c53ab? dev -> dev
多人協作的工作模式
1、首先，可以試圖用git push origin <branch-name>推送自己的修改；
2、如果推送失敗，則因為遠程分支比你的本地更新，需要先用git pull試圖合并；
3、如果合并有沖突，則解決沖突，并在本地提交；
4、沒有沖突或者解決掉沖突后，再用git push origin <branch-name>推送就能成功！
如果git pull提示no tracking information，則說明本地分支和遠程分支的鏈接關系沒有創建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。
Rebase
rebase操作可以把本地未push的分叉提交歷史整理成直線；
rebase的目的是使得我們在查看歷史提交的變化時更容易，因為分叉的提交需要三方對比。
