Git常见的三种协作开发模式：Git Flow & GitHub Flow & Gitlab Flow，本文只是对上述几种模式进行吸收融合，结合项目实战总结出的比较实用的分支写作规范。

版本分支介绍

master分支（生产分支）

长期分支，经过充分测试的稳定发布版本，对应线上生产运行环境，只接受来自release分支和hotfix分支的合并。

develep分支（开发分支）

长期分支，经过开发自测过的新功能集成可用版本，对应开发集成环境，只接受来自feature分支、bug分支、hotfix分支的合并。

release分支（预发布分支）

临时分支，一个项目里程碑的测试预发布版本，对应测试环境，测试通过可用合并到master分支（升级生产），不接受直接提交代码，只接受来自bug分支的合并，演进路径：develop → release → master。

feature分支（需求分支）

临时分支，开发者本地正在开发的新需求分支，对应需求开发负责人的本地环境，该分支有两个来源：直接提交代码和来自task分支的合并请求，演进路径： develop → feature → develop。

task分支（任务分支）

临时分支，开发者本地正在开发的新任务分支，对应任务开发者本地环境，该分支可以直接提交代码，演进路径：feature → task → feature。

bug分支（测试缺陷分支）

临时分支，开发者本地正在修复的测试缺陷分支，对应开发者本地环境，该分支可以直接提交代码，演进路径：release → bug → develop&release 或者 develop → bug → develop。

hotfix分支（生产缺陷分支）

临时分支，开发者本地正在修复的生产缺陷分支，对应开发者本地环境，该分支可以直接提交代码，演进路径：master → hotfix → master&develop&release。

以上为质保产品推荐分支及版本管理，当产品在新研发阶段，由于未上线，为了简化流程，可以不启用develop分支和release分支，此时master分支等同于develop分支和release分支，即需求开发和缺陷修复都基于master分支。当需要部署测试环境时，启用release分支，当部署了生产环境，则马上启用develop分支。

develop：开发分支

需求开发过程

  1. 需求设计人员获取最新develop分支，从develop分支中新建需求分支，分支命名：feature/${需求id}-英文描述

  2. 若需求较大涉及多人开发，则需要在需求分支新建任务分支，任务开发人员获取步骤1中新建的需求分支（feature/${需求id}-英文描述），从该分支中新建 任务分支，分支命名：task/${任务id}-英文描述

  3. 开发完成后发mr请求到需求分支（feature/${需求id}-英文描述），并通知设计人员审核代码并做任务验收，验收通过后合并到需求分支，并删除合并的任务分支

  4. 需求分支上所有任务都验收审核通过后由设计人员发mr请求到develop分支，当上线评审通过后由配管合并代码并删除该需求分支

需求开发过程git命令参考
git clone 工程地址 (1)
git checkout develop (2)
git pull (3)
git checkout -b feature/xxx-xxxx (4)

(5)

git status (6)
git diff (7)
git add . (8)
git commit -m 任务修改中文描述 (9)
git push (10)

(11)
1 获取最新代码，如果本地已有，可跳过
2 切换到develop分支，如果已在develop分支，可跳过
3 更新服务器最新develop分支代码
4 新建需求分支
5 在当前代码分支进行开发、自测，当阶段性开发完成继续进行下面步骤
6 查看当前分支代码修改情况
7 对比修改内容
8 确认无误后将当前目录的修改全部添加到git
9 提交到本地git仓库，如果任务还未完成，继续回到5进行迭代
10 推送到git服务器仓库，此时其他人可以获取到该分支的代码，如果任务还未完成，继续回到5进行迭代
11 自测完成，通过在线提交mr请求到develop进行集成

release：预发布分支

测试发布过程

  1. 在当前项目全部开发完成时，从上一个发布版本（如果没有待发布版本，用master）基础上新建预发布分支，分支命名：release/YYYYMMDD

  2. 配管发起从develop分支到release分支的mr请求，mr请求命名：YYYYMMDD版本

  3. 评审会审核通过后配管合并代码

测试问题修复过程

  1. 从release分支中新建问题修复分支，分支命名：bug/${缺陷ID}-英文描述

  2. 修复缺陷后分别发mr请求到develop和release分支，通知设计人员审核代码（需要确保一个mr请求保留分支，以免只能合并一次，第二次合并的时候分支被删除）

  3. 代码审核通过后通知配管合并代码并删除该分支

测试问题修复过程git命令参考
git checkout release (1)
git pull
git checkout -b bug/xxx-xxxx

(2)

git status
git diff
git add .
git commit -m 缺陷修复中文描述
git push

(3)
1 切换到release分支，如果已在release分支，可跳过
2 修复bug，自测
3 自测完成，在线操作：

  • 通过在线提交mr请求到develop进行集成通过gitlab在线提交该分支的mr请求到develop，注意去掉勾选Remove source branch when merge request is accepted.

  • 通过gitlab在线提交该分支的mr请求到release，注意勾选Remove source branch when merge request is accepted.

master：生产分支

生产发布过程

  1. 当预生产测试通过后，从release分支发起到master的mr请求，mr请求命名：YYYYMMDD版本

  2. 配管审核通过后合并代码并删除该release分支

生产问题修复过程

  1. 从master分支中新建问题修复分支，分支命名：hotfix/${缺陷ID}-英文描述

  2. 修复缺陷后分别发mr请求到develop和master分支，通知设计人员审核代码（需要确保一个mr请求保留分支，以免只能合并一次，第二次合并的时候分支被删除）

  3. 代码审核通过后通知配管合并代码并删除该分支

生产问题修复过程git命令参考
git checkout master (1)
git pull
git checkout -b hotfix/xxx-xxxx

(2)

git status
git diff
git add .
git commit -m 缺陷修复中文描述
git push

(3)
1 切换到master分支，如果已在master分支，可跳过
2 修复bug，自测
3 自测完成，在线操作

  • 通过gitlab在线提交该分支的mr请求到develop，注意去掉勾选Remove source branch when merge request is accepted.

  • 如果当前有release分支，则还需要通过gitlab在线提交该分支的mr请求到release分支，注意去掉勾选Remove source branch when merge request is accepted.

  • 通过gitlab在线提交该分支的mr请求到master，注意勾选Remove source branch when merge request is accepted.

其他分支策略

Git Flow

荷兰程序员 Vincent Driessen 提出的一种分支管理策略：https://nvie.com/posts/a-successful-git-branching-model/[A Successful Git Branching Model]。

他的核心思想：

  • 两个长期分支，受保护不能删除

    • master：稳定的分布版

    • develop：最新的开发版

  • 三个短期分支，用完后删除

    • feature：功能分支，演进路径：develop → feature → develop

    • release：预发布分支，演进路径：develop → release → master & develop

    • hotfix：补丁分支，演进路径：master → hotfix → master & develop

下面是安装git flow 插件后两个常用场景的操作示例：

普通开发流程
# 初始化版本流程控制
git checkout -b develop origin/develop
# 初始化工作目录(一直回车即可)
git flow init
# 开始创建新的需求分支
git flow feature start xxxx #这时项目会自动切换 feature/xxxx分支
#
# 修改代码
# git commit -a -m 修改说明
#
# 提交功能到远程库：
git flow feature publish xxxx
# 完成开发分支合并develop(自动)
git flow feature finish xxxx
# 发布到远程开发分支
git push origin develop
# 删除远程分支
git push origin :feature/xxxx
生产紧急bug修复流程
# 更新master分支
git pull origin master
# 切换到master分支
git checkout master
#生成一个hotfix分支
git flow hotfix start xxx

# 通知相关得工程师和测试人员hotfix分支名称
# 最终测试完成后拉回分支最新代码
git pull origin hotfix/xxx
# 最终修改和测试完成后，结束hot fix以供发布
git flow hot fix finish xxx
# 发布最终的master分支
git push origin master

Github Flow

Github flow 是Git flow的简化版，专门配合"持续发布"。他只有一个长期分支master，不区分功能和补丁，只有一个演进路径：master → 临时的功能和补丁分支 → master

Gitlab Flow

Gitlab Flow 综合了Git Flow和Github Flow，是Gitlab官方推荐的版本策略。

他的核心思想：

一个长期分支

  • master: 开发分支，是所有其他分支的"上游"。只有上游分支采纳的代码变化，才能应用到其他分支。

n个环境分支

  • pre-production: "预发布环境"的分支，不接受直接代码提交。

  • production: "生产环境"的分支，不接受直接代码提交。

n个发布版本

  • 1-0-stable: 1.0稳定版本

  • 2-0-stable: 2.0稳定版本