命令行及內(nèi)容概覽

git branch #查看分支
 
git branch <name>  #創(chuàng)建分支

git checkout <name> #切換分支

git checkout -b <new branch name> #創(chuàng)建加切換分支

git merge <name>  #合并某分支到當(dāng)前分支

git branch -d <name> #刪除分支

git log --graph #查看分支合并的情況

git log --graph --pretty=oneline --abbrev-commit #用一行呈現(xiàn)log信息

#如何利用分支進行合作開發(fā)

git stash #隱藏工作區(qū)和暫存區(qū)的內(nèi)容

git stash apply #將隱藏的內(nèi)容恢復(fù)，但不從stash list中刪除

git stash drop #刪除stash list中的內(nèi)容

git stash pop #恢復(fù)的同時也刪除

git remote #查看遠程庫的信息

git remote -v #查看更詳細的信息

git push origin <remote branch name> #推送到遠程倉庫的指定分支

git branch --set-upstream <local branch name> origin/<remote branch name>
 #建立local branch和remote branch的鏈接

git pull 
#抓取分支到本地，嘗試合并，若有conflict，解決沖突，在本地提交后再push

創(chuàng)建與合并分支

每次提交，Git都把它們串成一條時間線，這條時間線就是一個分支。截止到目前，只有一條時間線，在Git里，這個分支叫主分支，即master分支。HEAD
嚴格來說不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是當(dāng)前分支。
一開始的時候，master分支是一條線，Git用master指向最新的提交，再用HEAD指向master，就能確定當(dāng)前分支，以及當(dāng)前分支的提交點：

git-br-initial

每次提交，master分支都會向前移動一步，這樣，隨著你不斷提交，master分支的線也越來越長

當(dāng)我們創(chuàng)建新的分支，例如dev時，Git新建了一個指針叫dev，指向master相同的提交，再把HEAD指向dev，就表示當(dāng)前分支在dev上：

git-br-create

Git創(chuàng)建一個分支很快，因為除了增加一個dev指針，改改HEAD的指向，工作區(qū)的文件都沒有任何變化！不過，從現(xiàn)在開始，對工作區(qū)的修改和提交就是針對dev分支了，比如新提交一次后，dev指針往前移動一步，而master指針不變：

git-br-dev-fd

git-br-ff-merge

git-br-rm

練習(xí)

git checkout -b dev

加上-b參數(shù)表示創(chuàng)建并切換，相當(dāng)于：

git branch dev
git checkout dev

然后，用git branch命令查看當(dāng)前分支

查看當(dāng)前分支

比如這里應(yīng)該換成dev

在新創(chuàng)建的分支上的工作完成（add和commit）之后，就可以切回到master。

切換到新創(chuàng)建的分支test

合并工作

test分支上的工作完成之后，切換到其他的分支。用git branch -d branchName刪除分支。

解決沖突

當(dāng)兩個分支分別有新的提交
現(xiàn)在，master分支和feature1分支各自都分別有新的提交，變成了這樣：

分別有新的提交

發(fā)生沖突

查看發(fā)生沖突的文件

修改發(fā)生沖突的文件，add、commit，master分支和新分支的關(guān)系就變成：

git-br-conflict-merged

分支的合并情況

當(dāng)Git無法自動合并分支時，就必須首先解決沖突。解決沖突后，再提交，合并完成。

用git log --graph命令可以看到分支合并圖。

分支管理策略

通常合并分支的時候，git會默認使用fast forward模式。但是，這種模式，在刪除分支后，會丟失分支信息。如果強制禁止這種模式，Git就會在merge時生成一個新的commit，這樣，從分支歷史上就可以看出分支信息。
加上--no-ff參數(shù)，表示禁用fast forward：
下面我們實戰(zhàn)一下--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'

準(zhǔn)備合并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后就像這樣：

git-no-ff-mode

分支策略

在實際開發(fā)中，我們應(yīng)該按照幾個基本原則進行分支管理：
首先，master分支應(yīng)該是非常穩(wěn)定的，也就是僅用來發(fā)布新版本，平時不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是說，dev分支是不穩(wěn)定的，到某個時候，比如1.0版本發(fā)布時，再把dev分支合并到master上，在master分支發(fā)布1.0版本：
你和你的小伙伴們每個人都在dev分支上干活，每個人都有自己的分支，時不時地往dev分支上合并就可以了。
所以，團隊合作的分支看起來就像這樣：

git-br-policy

小結(jié)
Git分支十分強大，在團隊開發(fā)中應(yīng)該充分應(yīng)用。
合并分支時，加上--no-ff參數(shù)就可以用普通模式合并，合并后的歷史有分支，能看出來曾經(jīng)做過合并，而fast forward合并就看不出來曾經(jīng)做過合并。

Bug分支

每個bug都可以通過一個新的臨時分支來修復(fù)，修復(fù)后，合并分支，然后將臨時分支刪除。
當(dāng)在dev上干活時，突然接到要修復(fù)代號101的bug，想新建一個分支issue-101來修復(fù)。可是手頭的工作還沒完成,dev上的工作還沒有提交。可是現(xiàn)在還沒有辦法提交手頭的工作，bug又需要立即修復(fù)。
Git提供了一個stash功能，可以把當(dāng)前工作現(xiàn)場“儲藏”起來，等以后恢復(fù)現(xiàn)場后繼續(xù)工作（未add和commit的工作都可以隱藏）：

有未add和未commit的工作

stash后工作區(qū)就變得干凈了

修復(fù)bug

1. 首先確定在哪個分支上修復(fù)bug，假定要在master上修復(fù)，就從master創(chuàng)建臨時分支，例如:

   
   
   從選定的分支上創(chuàng)建臨時分支
2. 修復(fù)bug，提交后切換到master分支，用git merge --no-ff -m "merge bug fix 101"合并分支，然后刪除issue-101分支。
3. 回到dev繼續(xù)干活。剛才被stash的工作用git stash list查看。有兩種方法恢復(fù)：
4. 用git stash apply恢復(fù)，恢復(fù)后，stash內(nèi)容并不刪除，需要用git stash drop來刪除。
5. 用git stash pop來刪除，恢復(fù)的同時也刪除了里的內(nèi)容，再用git stash list來查看就沒有了。可以多次stash，恢復(fù)的時候，先用git stash list查看，再用類似于git stash apply stash@{0}來恢復(fù)到想要的內(nèi)容。
   看到pop命令就大概明白，stash主要就是將需要放在一邊的內(nèi)容先放在一個堆棧里面啦

Feature分支

每添加一個新功能，最好新建一個feature分支（在取名的時候，要讓新的分支名能夠概括新的功能），在上面開發(fā)，完成后，合并，最后，刪除該feature分支。
一切順利的話，feature分支與bug分支一樣，完成后提交到dev并刪除分支。但是新功能被取消了，要求刪除feature分支。
先切換回dev分支，用git branch -d feature命令刪除分支，但是，由于feature分支沒有merge。會顯示失敗，根據(jù)提示用git branch -D feature就可以強行刪除了。

過程示例

多人協(xié)作

當(dāng)從遠程倉庫把項目clone到本地的時候，git自動把本地的master分支和遠程的master分支對應(yīng)起來了。遠程倉庫的默認名為origin。

要查看遠程庫的信息，用

git remote

或者用查看更詳細的信息

git remote -v

比如：

VectorLu:Diary Vector$ git remote
origin
VectorLu:Diary Vector$ git remote -v
origin  https://github.com/VectorLu/Diary.git (fetch)
origin  https://github.com/VectorLu/Diary.git (push)

上面顯示了可以抓取和推送的origin的地址，如果沒有推送的權(quán)限，就看不到push的地址。

推送分支就是把這個分支上的所有提交推送到遠程庫。推送時，要指定本地分支。git就會把指定的分支推送到遠程倉庫對應(yīng)的指定分支上。比如：

git push origin master

或者要推送到dev上，就是

git push origin dev

哪些分支需要推送，哪些不需要呢？

1. master分支是主分支，因此要時刻與遠程同步；
2. dev分支是開發(fā)分支，團隊所有成員都需要在上面工作，所以也需要與遠程同步；
3. bug分支只用于在本地修復(fù)bug，就沒必要推到遠程了，除非老板要看看你每周到底修復(fù)了幾個bug；
4. feature分支是否推到遠程，取決于你是否和你的小伙伴合作在上面開發(fā)。

然而可能會有推送失敗的情況出現(xiàn)。

未設(shè)定分支間的連接

$ git branch --set-upstream dev origin/dev
Branch dev set up to track remote branch dev from origin.

合并有沖突

修改文件以解決沖突，別忘了add和commit之后，再push。

解決沖突，add和commit之后再push

多人協(xié)作的工作模式通常是這樣：

1. 首先，可以試圖用git push origin branch-name推送自己的修改；
2. 如果推送失敗，則因為遠程分支比你的本地更新，需要先用git pull試圖合并；
3. 如果合并有沖突，則解決沖突，并在本地提交；
4. 沒有沖突或者解決掉沖突后，再用git push origin branch-name推送就能成功!
   **如果提示"no tracking information"，則說明本地分支與遠程分支之間沒有創(chuàng)建鏈接關(guān)系，用命令

git branch --set-upstream <local branch name> origin/<remote branch name>

**小結(jié):**
1. 查看遠程庫信息，使用git remote -v；
2. 本地新建的分支如果不推送到遠程，對其他人就是不可見的；
3. 從本地推送分支，使用git push origin branch-name，如果推送失敗，先用git pull抓取遠程的新提交；
4. 在本地創(chuàng)建和遠程分支對應(yīng)的分支，使用git checkout -b branch-name origin/branch-name，本地和遠程分支的名稱最好一致；
5. 建立本地分支和遠程分支的關(guān)聯(lián)，使用git branch --set-upstream branch-name origin/branch-name；
6. 從遠程抓取分支，使用git pull，如果有沖突，要先處理沖突，并且add和commit修改再push。