Git 分支管理策略汇总( 三 ) _生活百科

没有了分支的代码隔离，测试和解决冲突都变得简单，持续集成也变得稳定了许多，但也有如下几个问题：

如何避免发布的时候引入未完成的 feature
如何进行线上 bug fix

如何避免发布的时候引入未完成的 feature答案是：Feature Toggle 。
既然代码要随时保持可发布，而我们又需要只有一份代码来支持持续集成，在代码库里加一个特性开关来随时打开和关闭新特性是最容易想到的，当然也是最容易被质疑的解决方案。
Feature Toggle 是有成本的，不管是在加 Toggle 的时候的代码设计，还是在移除 Toggle 时的人力成本和风险，都是需要和它带来的价值进行衡量的。
事实上，在我们做一个前端的大特性变更的时候，我们确实因为没办法 Toggle 而采用了一个独立的 feature 分支，我们认为即使为了这个分支单独做一套 Pipeline，也比在前端的各种样式间添加移除 Toggle 来得简单。
但同时，团队商议决定在每次提交前都要先将 master 分支合并到 feature 分支，以此避免分支隔离久以后合并时的痛苦。
如何进行线上 bug fix在发布时打上 release tag，一旦发现这个版本有问题，如果这个时候 master 分支上没有其他提交，可以直接在 master 分支上 hot fix，如果 master 分支已经有了提交就要做以下四件事：

从 release tag 创建发布分支。
在 master 上做 bug fix 提交。
将 bug fix 提交 cherry-pick 到 release 分支。
在 release 分支再做一次发布。

线上 fix 通常都比较紧急。看完这个略显繁琐的 bug fix 流程，你可能会问为什么不在 release 分支直接 fix ，再合并到 master 分支？
这样做确实比较符合直觉，但事实是，如果在 release 分支做 fix，很可能会忘了合并回 master 。
试想深夜两点你做完 bug fix 眼看终于上线成功，这时你的第一反应就是“终于可以下班了。什么，合并回 master？明天再来吧“
等到第二天你早已把这个事忘得一干二净。而问题要等到下一次上线才会被暴露出来，一旦发现，而这个时候上一次 release 的人又不在，无疑增加了很多工作量。
总结以上四种就是目前相对主流的分支管理策略，但没有哪一种策略是万能的。所以无论选择哪一种，都需要考虑团队的实际情况，以及项目的具体业务需求，适合自己的才是最好的。
最后，再分享三点小建议：