一、背景问题

Git作为一款优秀的分布式代码管理工具，在开发过程中为团队提供了极大的便利。然而，正如俗话所说，“无规矩不成方圆”。如果没有合理的分支管理规范，可能会引发一系列问题，比如：

1、代码冲突：开发者直接从 master 分支拉取代码进行修改，合并时出现各种冲突，解决起来困难重重，往往会影响开发进度。

二、方案

以上的种种问题的根源在于 Git 分支管理的缺失规范。通过合理的管理规范，可以有效减少生产事故并提高研发效率。

2.1、人员角色

首先，根据研发人员的职责，我们可以将角色划分为：

1、项目组长 - Team Leader

2、需求开发研发 - Developer

3、系统集成测试人员 - SIT Tester

4、系统用户故事测试人员 - UAT Tester

5、系统运维人员 - Operator

2.2、角色分工

根据人员分工，划分每个角色可操作的环境权限。具体划分如下：

2.3、分支管理

2.3.1、分支命名规范

根据角色和权限管理，创建不同的分支。以下是各类分支的命名规范及示例：

1、master 分支

• master 为主分支，也是用于部署生产环境的分支，确保master分支稳定性

• master 分支一般由develop以及hotfix分支合并，任何时间都不能直接修改代码

2、develop 分支

• develop 为开发分支，始终保持最新完成以及bug修复后的代码

• 一般开发的新功能时，feature分支都是基于develop分支下创建的

3、feature 分支

• 开发新功能时，以develop为基础创建feature分支

• 分支命名: feature/ 开头的为特性分支， 命名规则: feature/user_module、 feature/cart_module

4、release分支

• release 为预上线分支，发布提测阶段，会release分支代码为基准提测

当有一组feature开发完成，首先会合并到develop分支，进入提测时，会创建release分支。

如果测试过程中若存在bug需要修复，则直接由开发者在release分支修复并提交。

当测试完成之后，合并release分支到master和develop分支，此时master为最新代码，用作上线。

5、hotfix 分支

• 分支命名: hotfix/ 开头的为修复分支，它的命名规则与 feature 分支类似

• 线上出现紧急问题时，需要及时修复，以master分支为基线，创建hotfix分支，修复完成后，需要合并到master分支和develop分支。

2.3.2、分支流程管理

git flow 流程图参考以下

git flow流程图参考

1、一个新的项目需求立项后，初始化项目分支，默认创建 master 分支，然后从 master 分支 checkout -b Develop 分支。

2、每位开发人员认领自己的功能需求，分别从 Develop 分支拉取自己个人分支进行功能编码。敏捷开发强调功能小版本迭代，并行开发。

3、当研发人员每个 feature 分支完成，开发自测之后，提交 merge request，team leader 经过 code review 确定运行无缺陷后合并到 develop 分支。

4、此时 sit 测试人员需要从 develop 分支打包最新代码，并部署 sit 测试环境，同步进行功能及接口测试，强调敏捷中的 “测试驱动原则”。

5、当所有 feature 都已合并并且 sit tester 打包测试无误后，从此时的 develop 分支拉取最新代码同步到 release 分支，并打包代码部署到 UAT 预生产环境进行 uat 测试，测试过程中的缺陷直接在 release 分支进行修复，研发及测试人员对修复的代码进行缺陷回归。

6、release 分支代码回归测试，无误后发布上线，同时合并到 master 分支。

此时，一个项目从最初的开发编码到发版上线，整个研发流程确保清晰明了。保证整个研发流程规范，可以大大减少生产事故。当然，不可避免的也会有生产问题，如果此时出现生产问题，需要直接从 master 分支同步代码至 hotfix 分支，修复生产问题并复测回归。这种流程下，比较容易出现冲突的场景及解决方案如下：

1）、多 feature 分支并行开发，在提交测试合并至 develop 分支时，容易出现合并冲突。这就要求各研发人员尽量只修改个人功能代码文件。公共配置或公共依赖包应由单独开发人员维护，按需添加，修改合并后推送到各 feature 分支。

2）、Hotfix 分支修复的同时有 release 分支功能需要发版上线，合并 master 时容易出现合并冲突。这时按功能生产环境紧急性依次发布上线，发版上线后立即合并 master 并推送到另一分支 (hotfix/release)。

2.3.3、提交日志规范

Commit Masseage 的格式规范

每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。其中，Header 是必需的，Body 和 Footer 可以省略。

Header 部分只有一行，包括三个字段：type（必需）、scope（可选）和 subject（必需）。

• type，type 用于说明 commit 的类别，只允许使用下面 7 个标识。

1. feat：新功能（feature）

2. fix：修补 bug

3. docs：文档（documentation）

4. style：格式（不影响代码运行的变动）

5. refactor：重构（即不是新增功能，也不是修改 bug 的代码变动）

6. test：增加测试

7. chore：构建过程或辅助工具的变动

• scope，scope 用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。

• subject 是 commit 目的的简短描述，不超过 50 个字符。

Body 部分是对本次 commit 的详细描述，可以分成多行。

Footer 部分只用于两种情况。

• 不兼容变动，如果当前代码与上一个版本不兼容，则 Footer 部分以 BREAKING CHANGE 开头，后面是对变动的描述、以及变动理由和迁移方法。

• 关闭 Issue，如果当前 commit 针对某个 issue，那么可以在 Footer 部分关闭这个 issue

三、操作方法

3.1、常见任务命令行操作

3.1.1、增加新功能

(dev)$: git checkout -b feature/xxx  # 从dev建立特性分支(feature/xxx)$: blabla  #开发(feature/xxx)$: git add xxx(feature/xxx)$: git commit -m 'commit comment'(dev)$: git merge feature/xxx --no-ff          # 把特性分支合并到dev

3.1.2、修复紧急bug

(master)$: git checkout -b hotfix/xxx         # 从master建立hotfix分支(hotfix/xxx)$: blabla                         # 开发(hotfix/xxx)$: git add xxx(hotfix/xxx)$: git commit -m 'commit comment'(master)$: git merge hotfix/xxx --no-ff       # 把hotfix分支合并到master，并上线到生产环境(dev)$: git merge hotfix/xxx --no-ff          # 把hotfix分支合并到dev，同步代码

3.1.3、测试环境代码

(release)$: git merge dev --no-ff             # 把dev分支合并到release，然后在测试环境拉取并测试

3.1.4、生产环境上线

(master)$: git merge release --no-ff        # 把release测试好的代码合并到master，运维人员操作(master)$: git tag -a v0.1 -m '部署包版本名'  #给版本命名，打Tag

3.1.5、 代码合并

代码合并是个技术活，这里提2个点

第一点是合并注意事项：1）、由开发人员发起合并，对于冲突比较多的，可以2个人以上进行合并；2）、系统参与者 评审人员 review通过后，才正式合并到分支。

第二点是合并方式：可基于命令行也可基于Idea git插件代码建立分支与合并分支。

以下基于Idea git插件方式进行代码合并说明：

3.1.5.1、建立分支

git默认的主分支名字为master，一般团队开发时，都不会在master主分支上修改代码，而是建立新分支，测试完毕后，在将分支的代码合并到master主分支上。

操作如下

1、idea git分支的操作

idea git的操作在右下角，如下图：

说明：

• 【new branch】新建分支

• 【local branches】本地分支

• 【current master】表示当前是主分支

• 【remote branches】远程仓库分支。我在这里配置了两个远程仓库，所以这里显示2个。

2、创建分支

点击【new branch】，弹出窗口，如下图：

输入分支名称点【OK】，然后默认切换到该分支。

3、切换分支

如果要切换回master主分支，操作如下图：

点击【checkout】

4、在新建立的分支上修改代码

切换到之前新创建的分支，修改代码。

5、提交分支到本地库

一般情况下只需要将分支提交到本地仓库，不需要将分支提交远程仓库。如果将所有的分支都提交到远程仓库，会让远程仓库杂乱无章。

确保在新建分支下，操作如下图：

弹出新窗口，如下图：

选择要提交的文件，写上提交注释，然后点击【commit】

commit表示提交代码到本地库

弹出警告窗口如下图：

点击【commit and push】，提交本地库成功！

3.1.5.2、合并到master主分支

1）、切换到master主分支

2）、合并代码到master主分支

操作如下图：

点击merge

注意：

• 当前必须切换到master主分支

• 然后在要合并的分支上点击merge

3）、推送到远程仓库

操作如下图：

点击【push】

提交成功后右下角弹出信息：

​

四、小结

1、分支管理的重要性：良好的管理规范能适当减少生产事故，提高研发效率。

2、对于分支如何管理：文中就分支流程管理和常见操作进行了说明，希望能够帮到大家。

阅读原文：原文链接