關於git項目管理分支策略的一點思考

00

做爲組員的時候，對git的理解沒太深，只知道fetch，rebase之類的簡單運用，沒有上升到項目管理的層面。到要本身去負責的時候，應了那句老話，人生到處是學問。

而後開始在網上看看前人的經驗，可參考的文章大都在談2010年Vincent Driessen的文章。畢竟經驗很少，在這裏只能留一下本身當前的想法，之後隨時更新。

 

01

咱們項目的當前git分支策略是採用一人一條分支的策略，是由以前的同事制定的。示意圖以下：

Figure 1. 當前分支策略示意圖

這種策略的優勢：

1.  責任明確。master中的代碼均可以較簡單的追蹤到分支上。
2. 分支清晰。在人員少的時候，能夠保持分支明朗。

可是做爲組員，我認爲這種分支策略是缺點遠遠大於優勢的，主要缺點以下：

1.  不適應高頻需求團隊。由於需求不斷砸來，缺乏里程碑版本的肯定，致使每一個新需求來都須要立刻上線，致使組員缺乏同步遠程庫和本地庫代碼的時機，我有位同事開發了三個月居然都沒同步過線上的代碼，可想而知一旦更新代碼衝突會多嚴重。

2. 需求必須線性合併到master上。由於每一個組員只有一條本身的分支，必然會有需求前後次序的衝突，例如：開發的時候a，b，c三個需求依次開發，卻被要求先要上線c需求，那麼c需求就可能有代碼耦合在a，b需求中，致使功能缺失。

所以，我開始尋找另外更好的分支策略

 

02

而後參考了A successful Git branching model [0] 的模型，開始搭建本身的branch模型。

主要就是master，development branch 和 issue-* branch。 先說issue-* branch，我另外搭建了一個issue系統（bug追蹤系統），全部的需求開發，bug修改都須要在系統中先report。以後開發人員就能夠根據issue系統給的issue id去建立分支，因爲和issue系統的結合，就能夠把一個大的需求切分不一樣部分給不一樣的開發人員去作。以後要合併上線的話只須要根據issue id號合併就行，最後刪掉分支。

因爲時間關係準備開會，第二部分先簡略說下，之後再補充

 

 

 

Refference

[0] Vincent Driessen,A successful Git branching model . http://nvie.com/posts/a-successful-git-branching-model/

[1] 阮一峯, http://www.ruanyifeng.com/blog/2012/07/git.html. http://www.ruanyifeng.com/blog/2012/07/git.html