分支合并流程对比
进步是痛苦的。学习也是痛苦的。在公司中推进git分支合并流程也是有阻力的。网络上版本管理系统之争持久而喧嚣，依照声量来讲目前应该是Git占了较大的优势。不过我们本文的关注点在于代码的分支管理模型，因为大家无论是用SVN或者Git，目的是为了解决研发过程管理中的实际问题。我这里整理几种分支管理模型，这样大家可以对照自己的痛点选择合适的模型。不过并不是最灵活的方案就最好，灵活意味着分支的管理和具体研发学习曲线都更复杂。
学习曲线（Complexity）
企业都希望研发团队能够快投入生产，而在版本管理这种“小事”不要花费太多精力。
需求变更（Release）
企业在一个迭代过程中是否能够完全不进行需求的变更，无论你们的周期是两周、一个月、或者一季度。
线上修正（Hotfix）
系统目前是否已经非常稳定，不存在需要发布线上修正的可能。
多环境（CI/CD）
企业是否存在多环境的要求（测试、预发布、正式等）
长期需求（Long-Lived Version-control Story）
企业是否存在一个大需求可能要持续数个迭代。（例如底层的基础业务模型扩展，增加新的数据隔离标识字段，涉及到系统底层或者全系统业务逻辑的变更。这里列这种需求并不是说必须支持，有些普通需求由于错误的技术方案/市场的变化等情况就会变化成这样的需求，所以综合考虑边界情况。）
另外也交代一下我所在的背景：
我在一线互联网公司呆过，目前在传统公司。公司初创，在思考很多问题。