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