一种新的Git分支管理策略

在使用git管理代码时，分支管理策略是需要开发之间规范统一的。现有的常见分支管理策略有TBD、Github flow，git flow。对于以上策略，本文不再赘述，有兴趣同学可以参考这篇文章。Git 分支管理最佳实践

TBD暂且不说。Github flow由于没有统一的开发分支，只有不同的feature分支，当多人开发多个需求时，feature分支和feature在发布测试服时容易相互覆盖。而git-flow则因为feature分支都合并到develop分支，当下一个版本需求都合并到develop时一起发布，如果要临时单独上线一个功能可能比较麻烦。适用于版本迭代周期比较长，版本需求比较明确的开发团队。而对于像我司团队这种需求周期短，开发内容多变，且多人并行开发多需求的情况可能就都不太适合。因此，我们对Github flow进行一些改变，制定并规范了一种更为灵活的分支管理策略。

如图总共分为三种分支。和Github flow一样，master 分支的作用是提供一个稳定可靠的代码基础。任何开发人员都不允许把未测试或未审查的代码直接提交到 master 分支。而develop分支则用于合并正在开发中的功能进行测试。当有一个新的feature或者发现新的bug时，我们都从master中切出一个分支，修改完代码后把分支合并到develop中进行测试。当测试不通过则返回feature或者bug分支进行修改，直到测试通过，把feature分支通过Merge request合并到master分支进行发布。这样就避免了Github Flow中不同的feature分支发布互相覆盖的问题，也避免了git-flow功能不能临时独立发布的问题。

当然，以上分支策略也有问题，比如分支切换比较频繁。如果能有像git-flow一样的插件工具会轻松很多。

分支管理策略是一个见仁见智的问题，没有绝对最好的，只有最适合自己团队的。以上。