Git管理策略的一点思考

今天看到阮一峰写的《Git分支管理策略》，觉得挺好，决定在团队内部试行一下。

我们团队属于人少，项目相对较多，同一个项目版本也多。有新功能演示，需要上线的稳定版，不同客户之间功能有差异的版本，此外项目之间还有集成的问题。所以长期以来版本非常混乱，恐怕没几个能很清楚的说出哪个版本的功能集以及针对的客户，QA也不知道。

 

原文中提到一个git flow的管理策略模型，如下所示：

结合该模型，简单设立了一下团队内部的开发过程。关键在于，第一团队要认可这种模型，第二团队对于发布计划要很清楚。

1. 设定基本的发布计划。即确定好master的几个production版本的时间点，如图上master的几个tag。

2. 设定迭代计划。即确定好release上的主要tag时间点。

3. 将每个story拆分成粒度合理的task。团队需要认可push到develop上的commit，原则上应该是个完整的task或者bug。这里我把task当成feature，各个相互配合的开发人员应该以完成整个feature为目标在相应的branch上协作。

4. 到达迭代的测试时间点时，release从develop上merge合适的commit（理想情况下应该就是当前develop最新的commit），构建版本后进行测试。如果有重大bug，该版本应该予以撤销。

5. 同时，在使用Git构建时，应该添加自动功能（可以使用buildr等自动构建工具），将当前版本涵盖的feature、commit等主要内容，自动发布到redmine的项目页，以便自动追踪。

6. 如果release有bug，需要fix，并merge到develop上。

7. 到产品版本发布时，从release上将经过测试的版本merge到master中。

8. 开始下一轮迭代。

PS：今天上海大雨。