A successful Git branching model的了解

文章末尾的這張圖，很多人都看過，我在好多年前就看過，一直沒有了解，覺得要同時維護這麼多的分支，基本上就不用做事了，是以在團隊中，一直都是使用master分支一撸到底，還好這些年沒有出大問題。

今天臨下班的時候，有點閑時間，再次翻到這張圖，仔細看了20來分鐘，恍然大悟，原來這個模型簡單又好用，以前之是以覺得複雜，一方面是我看書不夠細心，另外一方面，也是網上的絕大部分文章，根本就沒有講清楚這張圖的重點。

這張圖，隻要注意豎線的顔色，黑色是分支存在的生命階段，淺灰色是相反。是以，日常開發，在git remote server上長期存在的分支，就兩個“master”和“develop”。

master分支：作為穩定的産品釋出後的分支，平時改動很少，tag也隻打在這個分支上。

develop分支：就是團隊日常開發使用的分支，代碼送出頻繁，基本上其它的分支，都是從develop分支上建立的，并且其它分支上的修改，都要合并到develop分支上。

至于其它的分支，都是短期存在的臨時分支，從右到左把他們的功用聽我簡單一說就明白了。

hotfixes分支：這個分支用于已經正式釋出的生産版本（也就是master上打了tag）出現bug的時候，從master分支的某個tag（一般是最新的一個，除非同時維護多個釋出版本）裡，branch一個分支，一般起名hotfixNN（NN代表兩位數字），用于修複bug。當bug修複後，就合并到master和dev分支，并且在master分支上打上新的tag，hotfixes生命周期結束，就可以删除了。這個分支存在時間較短，一般情況下不推送到remote。

release分支：當開發到一定時間後，準備釋出新版本，從develop分支branch一個新的分支，取名release，或者是1.0這樣的版本号，接下來這個分支隻進行bug修複，不再從别的分支合并新特性，并且每修複一個bug，就要合并到develop分支。等到bug修複得差不多了，可以釋出新版了，就把release分支合并到master和develop，并在master分支上打上tag，release分支生命周期結束，删除。這個分支一般會存在一段時間，也需要團隊一起修複多個bug，是以推送到remote。

feature分支：這類分支是很頻繁的從develop分支上branch出來，完成開發和本地測試後，又頻繁的合并到develop。這類分支不論存在時間長短，一般隻存在開發人員的本地，不推送到remote。在某些情況下，當需求變更,某些特性不需要了時,分支直接就放棄删除了。

以後的團隊協作，就用這個模型了。