欢迎来到
按发布创建分支
定义
编辑
基于发布的分支策略是Git分支策略的一种，也是基于主干分支开发的几乎唯一的可以接收的创建分支的情况。当创建了这个分支，也就定义了发布的版本。所有的该版本的测试和验证全部都在该分支上进行。而最新的开发工作仍然在主干上进行。
实践出处
编辑
《持续交付：发布可靠软件的系统方法》
为什么
编辑
在基于主干的分支策略中，存在一个巨大的邪恶的做法，那就是“冻结分支”。为了某一次大的发布，几天甚至几个星期内都不允许向版本库中签入代码。这违背了每日提交的最佳实践。
而通过创建“发布分支”，开发人员仍旧可以向主干分支提交代码，而在发布分支上只做严重缺陷的修复。
只有在主干上发现最严重的缺陷修复，才从主干合并到发布分支上。
何时使用
编辑
创建发布分支是有场景要求的。开发团队需要开发新的功能，而当前要发布的版本正在测试或者准备部署，同时测试团队也希望能够在当前发布中修复缺陷，但是不影响正在进行中的新功能开发。
在这样的情况下，在逻辑上将新功能的开发与分支上的缺陷修复分开是可以接受的。但要记住的是，缺陷修复必须被合并回主干。一般来说，当把缺陷修复提交到发布分支上之后，就应该立即合并回主干。
如何使用
编辑
在基于发布的分支策略中，需要遵循如下规则：
-
一直在主干上开发新功能。
-
当待发布版本的所有功能都完成了，并且希望继续开发新功能时才创建一个发布分支。
-
在分支上只允许提交那些修复严重缺陷的代码，并且这些代码要立即马上合并回主干。
-
当执行发布时，这个分支可以选择性的打一个标签（tag）。
-
不要在已有的发布分支上再创建更多的分支，所有的后续分支应该从主干创建。从已有的分支上创建分支会形成一种“梯形”结构，很难发现两个版本之间哪些代码是公共的。
-
如果发布频率达到了一周一次（或者以上）的频度，那么该策略就没有必要了。因为在这种情况下，发布一个新版本要比在已发布的分支上打补丁更容易，成本更低。
常见问题解答
编辑
-
基于发布的分支的不适用场景？
该分支策略在真正的大项目中效果并不太好，因为很难让一个大型团队或者多个团队在同一个版本上同时完成他们所有的工作。
在大项目的开发中，需要从架构上对软件进行更合理的规划，形成组件化的架构。这样每个组件都有一个发布分支，不同开发速度的团队可以按照自己的进度在创建发布分支后，在主干分支上继续开发新的功能。
-
在基于发布的分支策略中，可以进行主干合并到发布分支的操作吗？
一般来说，因为主干已经在开发新的功能了，而这些新的功能并没有开发完成，主干并不是一个严格意义上的可用分支，这时候合并到发布分支会带来不必要的问题。一个更好的方法是，将严重的缺陷在发布分支上修改，修改完成后，立刻合并回主干分支。
参考资料
编辑
-
https://www.atlassian.com/agile/software-development/branching
-
https://trunkbaseddevelopment.com/branch-for-release/
关键词
编辑
Git分支模型 发布 分支策略
我们非常重视知识产权，我们在非常努力地寻找最初的出处来源并注明出处。但因为互联网信息浩瀚，难免会有疏漏。如果您觉得有侵犯您的权益，请联系我们。
导出按发布创建分支.pdf
导出按发布创建分支.docx
导出按发布创建分支.pptx分享
