关于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