工程分支管理策略-公司实践

目前接受度比较高的分支管理策略是 Vincent Driessen提出的，其管理策略具现如下：

然而，这种管理策略对我们公司来说，还是太复杂，掌控不好，就是分支蔓延，所以公司实际采用的管理策略为：

图解：

（1）每开发一个功能，就从主干上切出一个开发分支；

（2）开发结束，测试完成后，将代码合并到主干，创建tag，删除开发分支；

（3）其他分支发现主干有新代码时，从主干上拉取最新代码，合并到自己的开发分支；

        ps：第三步的目的是 避免 自己的开发分支测试无误，而合并到主干后，却 出现功能冲突等

备注：

（1）必须保证：master分支总是可部署状态 - anything in the master branch is always deplyable

（2）分支命名：包含两部分内容：作用和创建日志，如：fileupload-20171001

（3）分支代码合并到主干时，注意使用参数--no-ff，如：git merge --no-ff <branch-name>

（4）tag命名：只包含创建日志即可，如：20171021，但是，要在创建tag时的release notes 中详细描述清楚本次调整的内容

（5）公司目前使用的这种分支管理策略存在一个问题，就是如果多个分支同时进入预发布测试阶段，会出现代码相互覆盖情况，不过公司引入docker后，这个问题不再存在。

ps：这个管理策略，是杨老师参考 Vincent Driessen提出来的，相对于 Vincent Driessen，变种还是挺大的，我之前也考虑过管理策略，但就没跳出 Vincent Driessen的框架，而且觉得两类分支肯定管理不好，存在各种开发冲突、测试冲突问题，然而实际上，跳出 Vincent Driessen框架，从master反向合并进开发分支，各种问题也就没了，所以呢，方法总是有的，不要给自己的想象设置篱笆。

参考文档

git分支管理策略：http://blog.csdn.net/zhaipengfei1231/article/details/79308926

Understanding the GitHub Flow：https://guides.github.com/introduction/flow/
GitLab Flow - Defined set of best practises：https://docs.gitlab.com/ee/workflow/gitlab_flow.html