标签：使用 稳定性 需要 特性 过程 模拟 版本控制系统 最好 调整
版本控制系统:用于维护应用程序每次修改的完整历史,包括源代码,文档,数据库定义,构建脚本,测试等.
当团队人数超过一定数量时,版本的冲突会日益增多,如何较好的进行版本控制管理,就变得非常重要.
分支的主要目的时帮助并行开发,而不互相影响.
团队中的分支使用情形:
合并:把分支上的一些修改复制到另一个分支的过程
分支的合并往往是冲突的开始,而冲突则意味着风险.
减少分支合并冲突的方式:
持续集成是不断向主干分支进行代码合并,保障主干分支的良好运行.持续集成不主张多分支.
一个更可控的分支策略是:只为发布创建长周期的分支.
在这种模式下,新开发的代码总是提交到主干分支上,只有在发布分支上修改缺陷时才需要合并,而这个合并是从分支合并会主干.而只有非常严重的缺陷修复才会从主干分支合并到发布分支上.
因为代码一直处于可发布状态,所以也就更容易发布.分支越少,合并和跟踪分支的工作就越少.
实际开发中可能团队人数较多,但是这并不影响主干分支开发模式,因为实际大家编辑相同文件且发生冲突的可能较小,如果较多的话,说明项目需要进行组件化拆分,并确保组件间的松耦合.
主干分支是持续集成的唯一分支管理方式.
优点:
同时,进行复杂修改时,将它拆解为小需求就可以很好的在主干分支上进行.
主干分支存在非可发布的状态的情形,如果针对这种情况就主张多分支的话,分支管理同样也存在这种状态,同时分支管理更加复杂,不可控因素会逐渐增多.
如何使用主干分支管理一个多开发人员,多版本发布的大型团队?
良好的组件化,增量式开发和特性隐藏.
按发布创建分支:在版本即将发布前,创建分支,用于测试和验证,开发依旧在主干分支进行.
发布分支只允许进行缺陷修复,不允许进行功能开发,以减少合并冲突情形,同时提交到发布分支的补丁,最好立即合并到主干分支上.
同时团队还应该尽量避免多分支开发的情形,比如老版本客户不愿意进行升级操作.同时大型团队往往会存在多个业务线,同一个版本完成所有开发也不现实,这是进行组件化就非常重要.
发布频率如果到达一周一次时,就没有必要创建发布分支了,主干分支发布即可.发布分支不允许再创建分支.
按功能和按团队来创建分支都是不推荐的,因为这会存在大量分支,然后造成集中合并,影响代码的稳定性.同时不同分支的差异会越来越大,团队间互不了解,风险也会逐渐增大.
可控分支创建的理由:
可控分支创建的唯一目的:对代码进行增量式或"通过抽象来模拟分支"方式的修改
标签：使用 稳定性 需要 特性 过程 模拟 版本控制系统 最好 调整
原文地址：https://www.cnblogs.com/chengmuyu/p/13276922.html
