原文：https://martinfowler.com/articles/branching-patterns.html
分支
分支容易 合并难
分支健康
在每次提交时，执行自动检查（编译测试）
以确保分支上没有缺陷
理想情况下，应在每次提交时运行所有测试。
如果测试速度很慢，则不实用。
集成
持续集成
源代码管理系统是一种通信工具。
它允许看到团队中其他人在做什么。
开发人员一旦有可以共享的健康提交，
就进行主线集成，
不应该有超过一天的工作在你的本地存储库中未整合。
大多数持续集成的实践者每天集成多次，
乐于整合一小时或更少的工作
持续集成几乎不可能偶尔为开源工作贡献者提供，
但却是商业工作的现实选择。
审核
制定及时审查承诺的纪律非常重要。
如果开发人员完成了一些工作，
并投入到另一个工作中一段时间，
等到审核回复时，
他们脑海中的具体细节已经不那么清晰了。
结对编程提供连续的代码评审过程，
其反馈周期比等待代码审阅要快。
许多使用审阅提交的团队都不够快。
他们可以提供的宝贵反馈来得太晚，
没有用处。
虽然审核提交可能是一种有价值的做法，
但它绝不是通往健康代码库的必要途径，
尤其是如果您希望发展一个平衡的团队，
而不是过于依赖其初始领导者。
集成摩擦
文化因素影响整合摩擦，
尤其是团队成员之间的信任。
如果我不相信我的同事会做好体面的工作，
那么我很可能想要防止破坏代码库的提交。
如果我相信我的同事的判断，
我很可能更适应承诺后审查，或完全切断审查，
并依靠社区重构来清理任何问题。
消除了承诺前审查引入的摩擦，
从而鼓励了更高的集成频率。
模块化
对模块化较差的系统进行小更改，
必须了解几乎所有系统，
良好模块化的系统中更改不容易导致冲突。
但在开始编程之前，
构建良好的模块化体系结构极其困难，
我们需要不断观察我们的系统，
重构是实现此目的的关键。
需要良好的开发实践、设计模式，
以及从代码库的经验中学习。
发布
release 发布分支模式
production 生产分支模式
环境分支模式
不要使用。
必须与在每个环境中运行的可执行文件相同。
如果需要配置更改，
则必须通过显式配置文件或环境变量等机制隔离配置更改，
从而减少 Bug 滋生的空间。
hotfix 热修复分支模式
版本列车模式
按月度创建分支发布
Git 流 和 GitHub 流
Git Flow 有 master hotfix release develop feature
GitHub Flow 只有 master 和 feature
Git Flow 假定一个产品有多个生产版本。
GitHub Flow 假设一个产品只有一个生产版本，
并以高频次集成到发布就绪主线上。
反思
每当你考虑使用分支时，
都要弄清楚你要如何合并。
有没有办法通过提高模块化来解决您的问题？
你可以改善部署流水线吗？
是否一个标签就足够了？
你对流程进行哪些更改会使该分支变得不必要？
