Git-Flow 使用规范

Git-Flow 是构建在 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 模型中定义了主分支和辅助分支两类分支。其中主分支用于组织与软件开发、部署相关的活动；辅助分支用于组织为了解决特定的问题而进行的各种开发活动。

主分支

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

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 需要修复，咋办？

Bingo~这个时候就用到了辅助分支。

辅助分支

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

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

辅助分支有以下几种：

• 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 代码

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

• 但是有个问题，合并到 master 分之后，线上环境有个 bug 需要修复，咋办？

生产环境的 bug 修复由 hotfix 分支负责。

再来个大图 引自 https://www.jianshu.com/p/d46da933c180