上一篇講到Git的分支管理實(shí)操，在線合并和本地合并都進(jìn)行了實(shí)操。畢竟：光說不練是假把式。而只練不整理，只能是傻把式了。分支管理到底如何進(jìn)行管理呢？
先以GitLab上的一張經(jīng)典的圖打頭，作為一個(gè)總體概覽，也方便理解分支的管理和走向：

現(xiàn)假設(shè)公司有名為Hogwarts_Online2的開發(fā)項(xiàng)目，其中包含了上線分支master，開發(fā)分支develop，測(cè)試分支release，和個(gè)人開發(fā)的特性分支

1.1）與遠(yuǎn)程倉(cāng)庫(kù)建立連接，在本地創(chuàng)建自己的分支，并拉取develop分支的文件：

1.2）在當(dāng)前分支中創(chuàng)建新的文件gitflowDemo.txt，輸入內(nèi)容“study git”；然后add,commit

#修改分支?

vi gitflowDemo.txt

?#提交修改

?git add gitflowDemo.txt?

git commit -m "add demo"

1.3） 通過git pull命令檢查遠(yuǎn)程develop分支是否和當(dāng)前分支有沖突：

$ git pull origin develop?

From ssh://47.95.238.18:10022/root/hogwarts_online2?

?* branch? ? ? ?? ? ?develop ? ?-> FETCH_HEAD

Already up to date.

注： push之前先拉去遠(yuǎn)程代碼，以防在開發(fā)過程中，遠(yuǎn)程被別人更新過新版本代碼。如有代碼沖突，兩人協(xié)商沖突解決辦法。多人開發(fā)的時(shí)候，沖突是不可避免的。

1.4) git push將修改推至遠(yuǎn)程特性分支origin gitflowDemo：

1.5) 在GitLab上進(jìn)行merge request，并在develop分支上進(jìn)行merge：
如果想要撤回這次merge可用git merge --abort

create merge request:

選擇develop分支：

沒有沖突，可直接merge：

最終我們可以看到成功merge進(jìn)develop分支中：

我們還可以在graph中查看分支的走向：

修改gitflowDemo.txt文件為

study git?

update

add,commit,push

git add gitflowDemo.txt?

git commit -m "update gitflowDemo.txt"?

git push -u origin gitflowDemo

切換到本地develop分支，pull最新代碼，merge本地gitflowDemo分支代碼，push進(jìn)遠(yuǎn)程develop分支

git checkout develop?

git pull origin develop

git merge gitflowDemo?

git push -u origin develop

這個(gè)是在GitLab上檢查更新情況：

develop分支變動(dòng)頻繁，master分支屬于上限版本，因此需要一個(gè)內(nèi)測(cè)的分支版本，這個(gè)就是release分支了
具體的提交操作根據(jù)權(quán)限范圍，和1中develop的操作一致。

有的時(shí)候出現(xiàn)的非常緊急的bug，需要立即修改上線，來不及在各個(gè)分支上進(jìn)行merge測(cè)試了；這個(gè)就是就需要用hotfixes模式，建立一個(gè)bugfix分支，直接繞開其他分支，修改合并到master中。
3.1) 建立bugfix分支，并修改文件push到遠(yuǎn)程分支：

git checkout master?

git checkout -b bug_02fix?

vi bugfix02.txt?

fix bug02?

git commit -a -m "bug_01 fix"

git push -u origin bug_01fix?

git add bugfix02.txt?

git commit -m "fix bug02"?

git push origin bug_02fix

3.2) 這個(gè)時(shí)候檢查GitLab，會(huì)發(fā)現(xiàn)多了一條從master分支拉出來的修改bug02的分支：

3.3）最后由最終的master權(quán)限擁有者來進(jìn)行合并。

3.4）修改了bug直接上線master后，很有可能讓master分支的修改已經(jīng)領(lǐng)先其他分支了；這個(gè)時(shí)候就需要將其他分支更新，對(duì)master分支進(jìn)行合并；同時(shí)將bugfix分支刪除，盡量保證分支的整潔度。

git log --graph --all --decorate=short

git grep "pattern" ?$(git rev-list --all)?

git log f13297

?git checkout feature?

git rebase master

與merge后的分支走向?qū)Ρ龋?/p>

git checkout feature?

git merge master?

#或者寫在一行?

git merge feature master

此外，rebase還可以對(duì)提交的歷史進(jìn)行修改（不常用也不建議使用）

git rebase -i HEAD~2

注意： rebase的使用規(guī)則
1、不要在公用的分支上執(zhí)行rebase
2、主要的分支進(jìn)行保護(hù)

git diff

git diff HEAD~3?

git diff master develop

常見diff工具：

• diff ——僅展示某一行的增加（+）或減少（-）

• vimdiff ——比diff看起來要更直接

• IDE ——強(qiáng)大的工具，展示清晰，使用方便

vimdiff bugfix01.txt bugfix02.txt