成功的git分支模型

最近看了一篇文章,讲到如何构建一个成功的git分支模型,下面说说我对git分支模型的理解。

分支策略

git分支图

master

  • 单个分支。
  • 线上代码分支,不进行直接开发。
  • 代码的改变来源于release分支和hotfixes分支的merge
  • 每次merge产生一个Tag并发布线上版本,每个Tag表示每一个线上运行的app版本的真实完全代码。

develop分支

  • 单个分支。
  • 主要开发分支,代码提交最多的分支。
  • release的代码需要功能性的修改,则将release的代码mergedevelop重新开始开发。
  • 若开发时需要并行开始一个耗时较长的功能开发,根据需要,可将develop分支check out到特定新功能分支feature来进行开发,当feature开发完成,再mergedevelop中。

feature分支

  • 多个分支,命名feature_some_function
  • 每次需要新的花时较长且和原develop代码耦合较低的功能并行开发时,可开启一个新的feature分支。
  • feature分支同样应具有feature masterfeature develop
  • feature分支开发完成后mergedevelop分支。

release分支

  • 多个分支,命名release_version_code
  • 开发版本分支,当develop的功能开发完成,从develop分支check out一个新的release_version_code分支。
  • release只能有bug fix的代码提交,而不能有功能性需求的代码提交。
  • release上时,若有bug fix之外的需求,则merge代码到develop重新开始开发,待开发完毕,mergerelease
  • release代码开发完毕,mergemaster上,打Tag,发布新版app,并且mergedevelop,保证已修复的bug在开发分支也生效。

hotfixes分支

  • 根据需要决定是单个还是每次热修复开新的分支。
  • 当线上版本发生问题,需要紧急解决时,从master分支check out一个新分支,开始热修复。
  • 若紧急修复成功,则修复完成mergemaster分支,打Tag,发布新版本。
  • 若未能热修复成功,则将代码mergedevelop中,此时相当于开始一个新版本的开发流程。

总结

这种分支模型总结了我们原本常用的分支策略,各分支功能划分清晰,利于代码和版本管理,提高了分工合作的效率。实际开发中,最好在每次check out新的release以及在master上打Tag时,告知每个开发人员。另外,配合上每个分支的持续集成,可将每次merge的出错率降低。

参考资料

http://nvie.com/posts/a-successful-git-branching-model