分支管理

业界主流分支策略

罗列业界主流分支管理策略的特点和优劣，以最佳实践作为参照，试图寻找匹配的或经过裁剪、增补后合适的分支管理策略：

典型组织：Google 、Facebook

特征：

优点：

缺点：

对master 分支质量要求高：大多数团队成员工作在mater 分支，发布时可能会出现”一粒老鼠屎，坏了一锅粥“的阻塞性灾难
对团队协作节奏要求高：如主线分支上的功能没有及时合入，但业务方又坚持要求在指定版本上线该功能，就会导致发布“难产”，甚至会被迫允许部分未开发完成的功能在发布分支上继续开发
将未经测试的代码引入生产环境可能未引发不可预知的风险
特性切换需要健壮的工程过程、可靠的技术设计和成熟的特性切换生命周期管理，如果不具备这三个关键的条件，反而会降低生产力

1.2 主干开发，主干发布

特征：
分支策略中的太极拳，即“没有策略”的分支策略

适用场景：

流程：

当开发接到开发任务，从 master 分支创建一个新的feature 分支，所有相关的代码修改都在新分支中进行。开发人员可以自由地提交代码和提交到远程仓库
新分支中的代码全部完成之后，通过提交一个新的 PR（pull request）或MR（Merge Request），团队中的其他人员会进行代码审查。由持续集成服务器（如 Jenkins）对新分支进行自动化测试。当代码通过自动化测试和代码审查之后，该分支的代码才能被合并入主干，并在主干完成功能的回归测试。
最后从 master 分支部署到生产环境

优点：

缺点：

feature 分支存活的时间越长，跟主干的差异就越大，分支合并冲突的风险就越大；随着需求拆分粒度变小，短分支的方式更合适；所以要么模块拆分的比较清晰，不影响其他人动这块功能，要么就与主干保持频繁同步（merge 或 rebase）
CI/CD 需要对不同分支配备不同的构建环境

2.1 Git Flow
2011年左右比较流行，后因流程繁琐遭吐槽，普遍认为hotfix 和 release 分支多余

2.2 GitHub Flow
特征：
只使用 master 分支和 feature 分支，并借助 GitHub 的 pull request 功能
master 分支中只包含稳定的代码（已经或即将被部署到生产环境），不允许把未测试或未审查的代码直接提交到 master 分支
对代码的任何修改，包括 Bug 修复、热修复、新功能开发等都在单独的分支中进行（不管是一行代码的小改动，还是需要几个星期开发的新功能，都采用同样的方式来管理）
2.3 GitLab Flow
在Github Flow（feature + master）的基础上，针对不同的发布场景，衍生出三个子类模型

分支模型	说明	图示
带生产分支	1.无法控制准确的发布时间，但又要求持续集成 2.需要创建一个生产分支来放置发布的代码
带环境分支	1.要求所有代码都在各个环境中测试通过 2.需要未不同的环境建立不同的分支
带发布分支	1.用于对外界发布软件的项目，同时需要维护多个发布版本 2.尽可能晚地从master 拉取发布分支 3.bug 修复应先合并到master，然后cherry pick 到各发布分支

GitLab 作为最优秀的开源代码平台，被多数互联网大公司（包括阿里、携程和美团点评等）所使用，这些大厂也都采用特性分支开发策略，结合各自公司的情况做个性化的定制

	分支策略	适用场景
1	主干开发	- 开发团队系统设计和开发能力强 - 有一套有效的特性切换的实施机制，保证上线后无需修改代码就能修改系统行为 - 需要快速迭代，想要获得CI/CD 所有好处
2	Git Flow	- 有预定的发布周期，需要执行严格的发布流程
3	Github Flow	- 随时集成随时发布：分支集成后经过代码评审和自动化测试就可以立即发布
4	GitLab Flow	- 无法控制准确的发布时间，但又要求不停集成
5	GitLab Flow	- 需要逐个通过各个环境验证
6	GitLab Flow	- 需要对外发布和维护不同版本

总结：
结合当前团队的现状给出一下结论

	TODO	说明	成本
追求效率：”主干开发”	- 从”主干开发，主干发布” 到”主干开发，分支发布”		最小
追求稳定：“特性分支开发”	- 抛弃原始代码管理工具Gitblit，引入优秀开源的代码管理平台GitLab - 需要更专业的、具有Devops 理念和落地经验的运维人员		大
主干开发结合特性分支		准则： - 团队共享一条主干分支 - 特性分支存活周期尽量短，不超过3天，每天同步主干代码 - 并行分支越少越好，尽量采用主干发布（是否需要发布分支，取决于发布模式）	比较大
	分支发布策略

建议：
Git 技巧：

增加代码审查：