【过程改进】总结大中小型项目的git流程

git做为源码管理工具出于流行趋势。这里和你们一块儿分享下咱们是如何用git的分支(branch)功能管理不一样规模的项目

---

小型项目 

推荐工具：TortoiseGit

开发阶段（初版上线前）：2个分支 develop和master

因为是项目参与人员很少,基本上不多会有不一样角色的人员出现职责冲突，需求变动也不会很繁冗。这种状况值咱们只须要主要功能分支。

其中develop负责开发版本，master至关于预上线版本。

develop过程若是出现代码冲突，手工merge就好。

开发阶段（初版上线后）：3个分支 develop、master、hotfix

多处于来的hotfix用于紧急上线（bug，新需求等）。hotfix基于master，由于develop已经越走越远，基于develop的hotfix会将带上一些当前不想上线的新功能。

hotfix完成后hotfix要merge到master上，由于线上无论何种状况都是master版本。qa完成测试而且上线后要将master版本merge到develop避免hotfix的修改在develop中丢失。

维护阶段(中止常规开发)：2个分支 master、hotfix。

这个阶段就至关于针对上线版本的各类打补丁了。

---

中型项目

推荐工具： sourcetree

开发阶段（初版上线前）：3个分支 feature、develop和master

相对于小型项目多了feature分支的概念。feature分支基于develop分支，当功能开发完成后merge回develop。

这样作的好处是将develop分支从小型项目中去中心化。举个例子，由于是中型项目，咱们可能有5 6个在并行开发，若是这个过程当中客户说某个功能咱们不要了，咱们能够很轻松的丢掉某个feature分支而没必要污染develop。

可是若是是开发时间好久的feature分支，极可能会由于不定时的merge develop或者需求的不断变动等致使当前分支的commit比较肮脏。因此对于feature分析的力度要控制好。

如图所示：

开发阶段（初版上线后）：4个分支 feature、develop、master和hotfix

和上面当心项目同样 hotfix基于master版本。

维护阶段(中止常规开发)： 和小型项目同样

---

 

大型项目

推荐工具：sourcetree

大型项目相对于中型项目又多了release版本。这个版本的做用只要是控制需求的更新以及当前版本bug的fix处理。

点击查看大图：

 对于这种情景sourcetree自带git-flow的功能

 

而且给出各类引导提示

 和中型项目相比，hotfix分支在大型项目中只处理线上的bug问题。对于需求的控制，都会发生在release分支中。一个release版本的生成并不意味着它能够直接提交master，qa的介入在中小型项目中属于master分支，

可是在这个流程下，qa的介入属于release分支，包括对于bug的修复操做也是直接在release版本完成。当qa对于release版本确认完成后，release版本merge到master预上线而且merge回develop保持代码一致性。

更详细的资料能够参考： http://nvie.com/posts/a-successful-git-branching-model/