Git管理策略的一点思考

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

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

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

from http://nvie.com

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

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:今天上海大雨。

猜你喜欢

转载自sisyphe.iteye.com/blog/1580249