聊聊分支管理

前言 背景 大多时候,开发人员仅需使用少量的分支,甚至只需 master 和 develop 两个分支即可完成日常工作。这足以应付小型项目或小规模团队的开发工作,但随着协作人员的增多和项目周期的延长,各样的挑战便会纷至沓来… 代码版本控制的挑战 并行开发:如何开始一个 feature 的开发,而不影响别的 feature ? 代码回溯:如何了解每次提交做了哪些工作,如何让提交记录承载软件文档的功能? 代码回溯:随着时间的流逝,如何快速了解每个分支都做了什么? 分支管理:由于新分支的创建是廉价的,分支多了之后该如何管理? 发布管理:如何进行发布管理?发布时如何冻结 Feature 的合并?发布过程中如何修复线上 bug?发布过程中如何并行开发新功能? 修复管理:线上代码出 Bug 后如何快速修复?修复后的代码如何安全、优雅的合并到所有协作者的工作分支中? 代码维护:如何在多人员的并行开发过程中保证代码质量? 面临这些挑战,本文试图提出一种简洁的、清晰的、可执行的分支管理方案,以期能够规避一些常见的版本控制陷阱,提高协作效率,增强知识共享,降低维护成本。 本分支规范的目的 提高协作效率:基于 git 的分布式实现,发挥并行开发的优势 增强知识共享:提交记录即文档,使其成为知识的载体之一,使得项目变更具有回溯性 降低维护成本:通过清晰的分支划分,简化代码集成过程、问题修复过程,使得项目的集成更可控 代码提交规范 好的提交记录是分支管理的基石,在讲述分支管理之前,务必先了解代码提交规范。 git commit 规范及原则 单一职责原则:细化提交粒度,每次提交内容应少而精,职责清晰,任务单一,拒绝将多个改动汇聚到同一个提交记录中 基于第一点,每次提交日志应尽可能的准确,详细阐述本次提交的改动内容,必要时可详细阐述改动的原因并给出相关链接。下附提交日志格式,以供参考。 第一行,简述变更内容,对于简单改动,仅填写此行信息即可。控制在 72 个半角字符以内,避免 Web 端自动换行 第二行,保持空行 第三行,详细变更 1,必要时需说明变更原因 第四行,详细变更 2,必要时需说明变更原因 第五行,相关链接(Wiki、RFC、技术博客等)... 拒绝空日志、重复日志、无意义的提交记录 避免不完整的提交,确保推送至远程分支的代码都是可运行的 如有某次提交不完整的情况,可在推送至远端前采用git commit --amend 的方式完善上次提交的内容 避免过于琐碎的无意义提交,尽量保持提交记录清晰可读...

November 9, 2019