信不信，7 張圖就能讓你把 Git 分支管理拿捏的死死的。。
相比同類軟件，Git有很多優(yōu)點。其中很顯著的一點，就是版本的分支（branch）和合并（merge）十分方便。
有些傳統(tǒng)的版本管理軟件，分支操作實際上會生成一份現(xiàn)有代碼的物理拷貝，而Git只生成一個指向當(dāng)前版本（又稱"快照"）的指針，因此非?？旖菀子?。
但是，太方便了也會產(chǎn)生副作用。如果你不加注意，很可能會留下一個枝節(jié)蔓生、四處開放的版本庫，到處都是分支，完全看不出主干發(fā)展的脈絡(luò)。
那有沒有一個好的分支策略呢？答案當(dāng)然是有的。
一、主分支Master
首先，代碼庫應(yīng)該有一個、且僅有一個主分支。所有提供給用戶使用的正式版本，都在這個主分支上發(fā)布。
Git主分支的名字，默認(rèn)叫做Master。它是自動建立的，版本庫初始化以后，默認(rèn)就是在主分支在進行開發(fā)。
二、開發(fā)分支Develop
主分支只用來發(fā)布重大版本，日常開發(fā)應(yīng)該在另一條分支上完成。我們把開發(fā)用的分支，叫做Develop。
這個分支可以用來生成代碼的最新隔夜版本（nightly）。如果想正式對外發(fā)布，就在Master分支上，對Develop分支進行"合并"（merge）。
Git創(chuàng)建Develop分支的命令：
??git?checkout?-b?develop?master
將Develop分支發(fā)布到Master分支的命令：
??#?切換到Master分支
??git?checkout?master
??#?對Develop分支進行合并
??git?merge?--no-ff?develop
這里稍微解釋一下上一條命令的--no-ff參數(shù)是什么意思。默認(rèn)情況下，Git執(zhí)行"快進式合并"（fast-farward merge），會直接將Master分支指向Develop分支。
使用--no-ff參數(shù)后，會執(zhí)行正常合并，在Master分支上生成一個新節(jié)點。為了保證版本演進的清晰，我們希望采用這種做法。
三、臨時性分支
前面講到版本庫的兩條主要分支：Master和Develop。前者用于正式發(fā)布，后者用于日常開發(fā)。其實，常設(shè)分支只需要這兩條就夠了，不需要其他了。
但是，除了常設(shè)分支以外，還有一些臨時性分支，用于應(yīng)對一些特定目的的版本開發(fā)。臨時性分支主要有三種：
功能（feature）分支 預(yù)發(fā)布（release）分支 修補bug（fixbug）分支
這三種分支都屬于臨時性需要，使用完以后，應(yīng)該刪除，使得代碼庫的常設(shè)分支始終只有Master和Develop。
接下來，一個個來看這三種"臨時性分支"。
第一種是功能分支，它是為了開發(fā)某種特定功能，從Develop分支上面分出來的。開發(fā)完成后，要再并入Develop。
功能分支的名字，可以采用feature-*的形式命名。
創(chuàng)建一個功能分支：
??git?checkout?-b?feature-x?develop
開發(fā)完成后，將功能分支合并到develop分支：
??git?checkout?develop
??git?merge?--no-ff?feature-x
刪除feature分支：
??git?branch?-d?feature-x
第二種是預(yù)發(fā)布分支，它是指發(fā)布正式版本之前（即合并到Master分支之前），我們可能需要有一個預(yù)發(fā)布的版本進行測試。
預(yù)發(fā)布分支是從Develop分支上面分出來的，預(yù)發(fā)布結(jié)束以后，必須合并進Develop和Master分支。它的命名，可以采用release-*的形式。
創(chuàng)建一個預(yù)發(fā)布分支：
??git?checkout?-b?release-1.2?develop
確認(rèn)沒有問題后，合并到master分支：
??git?checkout?master
??git?merge?--no-ff?release-1.2
??#?對合并生成的新節(jié)點，做一個標(biāo)簽
??git?tag?-a?1.2
再合并到develop分支：
??git?checkout?develop
??git?merge?--no-ff?release-1.2
最后，刪除預(yù)發(fā)布分支：
??git?branch?-d?release-1.2
最后一種是修補bug分支。軟件正式發(fā)布以后，難免會出現(xiàn)bug。這時就需要創(chuàng)建一個分支，進行bug修補。
修補bug分支是從Master分支上面分出來的。修補結(jié)束以后，再合并進Master和Develop分支。它的命名，可以采用fixbug-*的形式。
創(chuàng)建一個修補bug分支：
??git?checkout?-b?fixbug-0.1?master
修補結(jié)束后，合并到master分支：
??git?checkout?master
??git?merge?--no-ff?fixbug-0.1
??git?tag?-a?0.1.1
再合并到develop分支：
??git?checkout?develop
??git?merge?--no-ff?fixbug-0.1
最后，刪除"修補bug分支"：
??git?branch?-d?fixbug-0.1
參考鏈接（阮一峰老師的博客）：https://www.ruanyifeng.com/blog/2012/07/git.html
為了把 Git 這條線學(xué)好，建議大家把前面 5 個章節(jié)回顧一下：
可能是 Git 歷史上最偉大的一次代碼提交 終于有人把 Git 的數(shù)據(jù)模型講清楚了 昨晚看完 Linus 第一次提交的 Git 代碼后，我失眠了！ 要熟練使用 Git，恐怕要記住這60個命令 崩潰！實習(xí)生把小組的代碼倉庫搞得一團糟。。。
由于公眾號的文章發(fā)布后不能修改，也沒辦法加個統(tǒng)一的目錄作為索引頁，所以二哥就把《Java 程序員進階之路》的系列文章開源到了 GitHub（點擊閱讀原文可以直接跳轉(zhuǎn)）：
https://github.com/itwanger/toBeBetterJavaer
每天看著 star 數(shù)的上漲我心里非常的開心，希望越來越多的 Java 愛好者能因為這個開源項目而受益，而越來越多人的 star，也會激勵我繼續(xù)更新下去~