前言
这个教程基于我的个人理解和实践,所以请大家多多指教。错误之处,欢迎评论指出,方便大家也能参考.有时间的话我也很乐意及时的进行改进。如果教程中有表述不清楚的地方,也请指出,或提供建议。
背景
在日常开发流程中,我们通常遵循一定的分支管理策略,例如在
dev
分支上进行开发,待功能稳定并通过测试后,最终通过测试的代码会被合并到release
分支准备正式发布。一旦软件版本上线,理论上该release
分支的代码就应该相对稳定,但在实际情况中,难免会出现线上紧急问题需要快速修复的情况。
这就是hotfix分支发挥作用的场景。以往处理这类问题时,可能会直接从release分支复制(cherry-pick
)所需的修正代码,然而,这种方式在后期合并过程中,特别是当主干dev分支对该文件也有持续更新时,容易造成merge
冲突,需要逐步回溯并cherry-pick
所有相关的历史修改,操作起来既复杂又耗时(以往我就是这么操作的,而且针对冲突还写过一篇文章:git之cherry-pick后再进行merge导致冲突的原因及解决方式)。
应用
而现在,借助hotfix分支策略,我们可以通过以下更为流畅的步骤解决这个问题:
- 当线上出现紧急bug需要立刻修复时,首先从当前的release分支 创建一个新的hotfix分支。
- 在dev分支 上针对问题进行修复,并将修复后的代码正常提交至dev分支。
- 紧接着,将dev分支 上的修复补丁通过
cherry-pick
的方式同步到hotfix分支上,并在此分支上进行严格的测试确认。 - 测试通过后,直接将hotfix分支 的内容部署上线,完成热修复工作,此时release分支 保持不变,避免了直接在release分支上做临时修复可能带来的风险。
- 待未来需要进行常规版本迭代时,只需将dev分支 的全部新功能和改进顺利合并到release分支,而不再受之前热修复的影响。
总结
通过引入hotfix分支,我们避免了一些不必要的冲突处理,使整个开发运维流程更为简洁和高效。