从最早使用git起，就隐隐约约摸索了一套git开发规范，这里做个小总结。这篇文章尽量通俗些。

初版： 2020-12-12 22:45:19

缘起

从最早使用 git起，就隐隐约约摸索了一套基于git的开发规范，比如

• 默认的master不允许随便动，设定保护分支
• 先建立分支，比如feature前缀的分支用来开发功能，开发完合并到master
• 达成一个阶段设定tag，标记版本
• 紧急的bug不能排期的，设定为hotfix，开发完合并到一个基础分支，测试通过后进入master
• 等等

这是最早的约定，后来发现大家的规范殊途同归，今天看了下系统的 git 规范，原来这里面有系统的学问。

分支管理规范

系统来说，git 开发规范或者说分支管理规范大致有三种：

• github flow
• git flow
• gitlab flow

Github flow

核心思路：

• master 作为保护分支始终核心可用
• 提交代码鼓励频繁颗粒度提交代码
• 开启pr，此外有讨论、codeReview 等
• 最终合并到 master

更多的是思路。目前就理解到这里，具体的可以自行查阅

Git flow

安装一个插件可以启用。使用 git flow init 可以开启。需要单独安装可参考 图解git flow开发流程

原来我司已经在做这个了，只不过 support 没使用。看下图：

补充：version tag prefix 可以加个 v

核心思想是：

• master用来稳定部署，当前稳定版
• develop 是最新代码，下一代的版本
• feature 功能开发分支，开发完合并develop后删除
• release 基于 dev的特定版本存档，合并到master后删除
• hotfix 解决问题

这个插件封装了一些命令大致如下：

# 开启分支
git flow feature start xxx
# 提交完 会合并到dev
git flow feature finish xxx
# 那就发布release
git flow release start 1.0.1

细节不放了，可看上面的第三方链接。

Gitlab flow

刚才提到的两种方案：

• git flow 比较复杂，分支很多，管理起来麻烦
• github flow 做了整合。但和issue管理麻烦

因此这个的核心思想是：

• 取消dev分支，采用基于 master进行签出和合并的策略
• 同时把issue和feature紧密相连。

一般的实践是：

• 分三个 master pre-prod prod。
• 开发新功能或者新需求，先建立issue，然后从master拉分支 issueID-name，也就是相当于feature，好处是开发完对应的issue会自动关闭
• 必须使用 rebase来合并commit记录，然后push
• 然后master依次发起合并。

没啥好说的，个人倾向于使用 git flow

结束

简单做个调研