网站首页 > 技术文章 正文
前言
git 依靠分布式版本控制、以及出众的分支功能受到互联网开发们的青睐，如果你上过 github 就离不开 git 的相关操作。
我司原来用的是 svn ，经过两年的时间，全项目都已换成 git ，我现在个人项目也全部用 github 和 gitee 。
但是，随着需求迭代周期的不断变化、发布的严格管控、线上问题的紧急修复等，开发分支时刻面临着来自不同需求方的“挑战”，合并到生产分支有时总会出现不可控的问题。
这些问题对开发人员管控代码造成了“不小的困扰”。归根到底就是没有对 git branch 的开发合并策略有个系统的认识。
借如下这张图，聊下 git 分支合并策略：
相信有和我们一样的 git 分支合并问题的同学看过这图后，已经有了解决方案，可以忽略之后的内容了。当然看晕的同学，可以继续阅读下去，我会尽可能说清楚其中的方式。
面临的问题
首先我们前端只是个几个人的团队，分支只有如下两种：
- develop：开发分支
- product：发布分支
以前就像前面说的一样，随着团队的逐日专业化，不能扛着小枪指哪打哪儿，面对各种“约束”，“困难”产生了如下些问题：
- 在开发资源有限的前提下，面对多个需求，如何管理 develop 分支？
- 线上紧急 bug 的修复（紧急事件对分支的侵入）
- 怎么维护“相对”稳定的分支，作为发布分支（发布分支的管理）
- 线上发布后，因为某些“不可抗力”的原因，如何快速回滚上个版本（版本回滚）
应对策略
开发分支的细化
在项目“垦荒”阶段，或者迭代需求有规律，功能“轻量”时，往往一条开发分支就足够了（毕竟我们以前都那么干的），但产品上线后，面对八方的需求就有些捉襟见肘。
比如： A ， B 两个需求，A 预估 5 天，B 预估 10 天，但整个开发时间只有 10 天，势必 AB 两个需要不同开发人员同时进行。但更不幸的是，第 5 天时就要把 A 推到生产，一条 develop 分支完全不能应对（总不能 B 需求才完成一半），那怎么管理 develop 分支？
把 A ，B 两个需求单独创建分支，这类分支称为 feature branch ，那我们的 git 代码提交流程就会变成这样：