Git 开发规范

Git 开发规范

分支管理策略

git flow

img

Vincent Driessen 于2010年提出的分支模型，可以说是最早、最全面的分支管理策略了，后续出现的分支管理策略基本都是基于 git flow 进行修改的。这里先要明确几个基本概念

1. master/main：主分支，最终所有需要发布的有效代码都会合并到该分支
2. develop：开发分支，所有开发内容都是基于 develop 分支创建 feature 分支
3. feature：特性分支，也就是每个版本开发要写的代码
4. release：发布分支，当需要发布版本时，develop 不能直接合并到 master 分支，需要通过 release 分支进行必要测试验证后，再将 relase 分别合并到 master 和 develop 分支。
5. hotfix：热修复分支，线上出了紧急 bug，需要专门分支处理

从上图可以看出，使用 git flow 开发步骤还是比较多的：

1. 从 develop 创建一个 feature 分支
2. 开发并自测完 feature 分支，将其合并到 develop 分支
3. 从 develop 分支创建 release 分支，进行集成测试
4. 将 release 分支合并到 master 和 develop 分支

github flow

省略去了大部分分支类型，仅保留了 master 和 feature 分支。

暂时无法在飞书文档外展示此内容

gitlab flow

引入了生产分支和环境分支，总体上与 github flow 区别不大。

环境分支很好理解，即不同环境使用不同的环境分支。

生产分支则类似于 release 分支，但是是从 master 拉取出来，用来代表生产部署的代码版本。

trunk-based development

img

与 github flow 差别很大，认为应该在 master（主干）上开发，使用 release 分支进行发布，理由是短期的开发任务不需要整的那么麻烦，测试什么的在提交到 master 之前做好就行了。

基本上就等同于单分支开发了，用的比较少。

总结

其实分支模型大差不差，git flow 最全面， github flow 最简化。

基本上，你可以使用 git flow 满足任何开发团队的节奏，也可以在此基础上去掉一些自己不需要使用的分支。github flow 之所以能这么简单，主要是因为 feature 分支开发周期较长，且有健全的持续集成、持续部署工具保证 feature 分支合并到 master 后不会影响 master 的可用性，要求不可谓不高。

其实，总结下来，一个健全的开发团队的分支管理应该满足以下条件：

1. 有一个永远有效、能反应生产部署代码的分支，可以随时发布
2. 有一个能持续集成、体现开发进度的分支，能够帮助提早发现集成问题

Commit Message

很多开发的 git commit message 写的是一团糟，要么是流水账，要么货不对板。

commit message 没有绝对的好坏，但是有相对的优劣，一个团队要遵守一致的填写规范。一个好的 commit message 应该要尽可能简洁、保留关键信息。

我们可以先将 commit 分为几类：

1. 代码重构：refactor
2. 功能开发：feat
3. 问题修复：fix
4. 文件变更：doc
5. ......

先用分类来概括提交内容，再用一段简短的文字来描述，如：

feat: 考试试卷CRUD fix: 试卷完成功能失败问题 refactor: 使用令牌桶替换默认限流算法 ....