Gitflow使用规范

GitFlow是构建在Git之上的一个组织软件开发活动的模型，是在Git之上构建的一项软件开发最佳实践。

2010年Vincent Driessen提出了A Successful Git Branching Model分支模型，用来帮助开发人员在大型软件项目中追踪feature，hotfix和release。Gitflow使整个分支模型自动化完成，更加易用。

分支说明

1. 主分支：maser分支和develop分支为主分支，是受保护分支，只有master权限可以操作，只接受代码合并不接受代码提交
2. 辅助分支：feature功能分支，bugfix功能修复分支，release发布分支，hotfix热修复分支为辅助分支，完成功能之后合并会主分支，并删除

 

Git Flow模型中定义了主分支和辅助分支两类分支。其中主分支用于组织与软件开发、部署相关的活动；辅助分支组织为了解决特定的问题而进行的各种开发活动。

主分支

Gitflow定义了两个主分支，是长期支持分支，不会被删除。注意，主分支只接受代码合并，不接受代码提交。

master分支

We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.

引用原作者的描述，master分支上的代码始终指向生产就绪状态。

我理解这句话的意思就是：master分支上的代码应该是最近发布到生产环境的代码

master分支规定：

• 和生产的代码保持一致
• 仅在上线前才更新master分支上的代码
• 每次更新master，都需对master添加指定格式的tag，用于发布或回滚
• master分支是保护分支，不可直接push到远程master分支
• master分支代码只能被release分支或hotfix分支合并，不接受其他分支的合并

所以我们规定(请大家牢记)：

master分支上的代码，随时可以上线。

master分支上的代码，随时可以上线。

master分支上的代码，随时可以上线。

develop分支

We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”. This is where any automatic nightly builds are built from.

引用原作者的描述，develop分支是下一个发布的最新交付代码，叫做“集成分支”。每日构建应该在develop分支上。

我理解这句话的意思就是：develop分支是我们的主要开发分支，为下一阶段需要上线功能的集成分支。

develop分支规定：

• develop分支不能与master分支直接交互

这里我们就有几个问题了：

1. develop是开发分支，但是又不能提交代码？咋办？
2. master分支是生产分支，develop测试完了，又不能直接交互，咋办？
3. 如果不合并，那要是不能及时上线，develop没办法继续合并新的功能了，工作就停了？
4. 但是有个问题，合并到master分之后，线上环境有个bug需要修复，咋办？

辅助分支

带了疑问，我们了解一下辅助分支。

辅助分支是辅助团队进行并行开发，功能跟踪，线上快速修复，与主分支不同，这些分支不是长期支持分支，完成之后会删除。

这些分支每一个都有特定目的，必须遵守关于分支的起始分支以及合并目标分支的规则。

辅助分支有以下几种：

• feature 功能分支
• bugfix 缺陷修复分支(在原文中并未提及，但是avh版本git-flow包含此分支)
• release 发布分支
• hotfix 热修复分支
• support 长期支持分支

先来一张图，大家感受一下。

 

feature分支

【强制】出自：develop分支
【强制】合并回：develop分支
【强制】命名规范：/feature/[英文功能名称]

功能分支的本质是，只要功能处于开发阶段，它就会存在，但最终会合并回develop或丢弃。

原文中提到一句话《Feature branches typically exist in developer repos only, not in origin.》功能分支通常只存在于开发者本地仓库，而不在远程仓库。

这里我们根据实际情况来调整，功能开发多人协作很常见，所以我们认为功能分支应该存在远程仓库。

feature规定：

1. 以功能为单位从develop拉一个feature分支
2. 每个feature分支颗粒要尽量小，以利于快速迭代和避免冲突
3. 在本地单元测试及review通过后，向项目主管申请，由项目主管或专人合并推送到Gitlab的develop
4. 合并前，应先拉取远程develop将本地develop更新
5. feature分支只与develop分支交互，不能与master分支直接交互

此分支解决了我们第一个疑问

• develop是开发分支，但是又不能提交代码？咋办？

所有的开发都是在feature分支上进行，最终合并回develop分支上。

release分支

【强制】出自：develop分支
【强制】合并回：develop和master分支
【强制】命名规范：/release/[发布版本号]

发布分支为下一个生产版本，只允许小错误的修复和准备发布的元数据[版本号，发布日志，日期等]的修改。最终发布版本号，在发布分支决定。

通过发布分支，可以释放develop分支，以进行下一阶段的工作。

发布分支我们规定：

1. 生成release分支，首先修改版本号，以区别develop分支的版本
2. 只存在一个发布分支(这个是gitflow目前的规定，可以讨论一下)
3. 当需要为发布新版做准备时，从develop衍生出一个release分支
4. release分支也可以从develop分支上指定commit派生出
5. release分支测试通过后，合并到master分支并且给master标记一个版本号
6. release分支一旦建立就将独立，不再从其他分支合并代码
7. 必须合并回develop分支和master分支或废弃

此分支解决了我们两个疑问

• master分支是生产分支，develop测试完了，又不能直接交互，咋办？
• 如果不合并，那要是不能及时上线，develop没办法继续合并新的功能了，工作就停了？

master通过引入release分支来进行develop进行交互，使用release分支，既能进行发布前的独立验证，又能不影响其他的功能分支合并会develop进行每日构建。

 

bugfix分支

【强制】出自：develop分支
【强制】合并回：develop分支
【强制】命名规范：/bugfix/[bug-英文缺陷名称或者bug编号]

缺陷分支，主要进行缺陷的修复记录，和功能分支类似，gitflow流程中，没有定义缺陷分支，为了区分缺陷与功能，新建缺陷分支用于区别功能，也可以忽略此分支，直接在功能分支中进行修复。注意在commit message中做区分。

hotfix分支

【强制】出自：master分支
【强制】合并回：master分支 和 [develop分支 release分支]
【强制】命名规范：/hotfix/[发布版本号]

热修复分支，类似于发布分支，都是为了准备新的生产上线版本。

当线上版本出现了不得不立即修复的缺陷时，可以从master分支新建热修复分支。修复完成之后，更改版本号，合并回master分支以及develop分支。

注意，当在热修复之前已经发布了下一个发布版本的时候，此时热修复分支应该合并回master和release分支，release分支完成之后，会把热修复的分支合并回develop分支。

hotfix分支规定：

1. hotfix分支用来快速给已发布产品修复bug或微调功能
2. 只能从master分支指定tag版本衍生出来
3. 一旦完成修复bug，必须合并回master分支和develop分支
4. master被合并后，应该被标记一个新的版本号
5. hotfix分支一旦建立就将独立，不可再从其他分支pull代码

 

参考引自https://www.jianshu.com/p/d46da933c180