Git 分支管理流程探讨

为了确保项目稳定性，满足项目迭代与项目开发人员的增长，需要尽快制定一个规范的 Git 分支管理流程。此分支管理流程是在 Git-Flow 的基础上做了一些改变。

环境区分

环境分为以下四种：

• 测试 1 服（开发自测，查看效果等。随时合并提交。）
• 测试 2 服（提测，冒烟测试，测试使用。功能提测时才能合并提交）
• 预发布环境（上线前的最后一道防线，配置尽量等同于正式环境）
• 正式环境

版本号管理

（当前需求版本号不好改的话就添加到第4位。）
版本格式： 主版本号.次版本号.修订号
如： 1.0.1
主版本号：重构、重大的功能更新
次版本号：常规的需求迭代
修订号：正式环境bug修复、部分极小的优化
每一次的发布/部署上线至正式环境，理应都要更新一位版本号。（无论一个迭代发出去后改了几次bug）

分支划分

• master - 主分支

• 主分支，与线上环境始终一致。任何时候都不可以直接修改。
• 每个提交就代表发布了一次线上，每次提交都是一个新的版本号。
• 可拉取 release、hotfix 子分支，仅能合并 stage、hotfix 分支。

• develop - 开发主分支

• 功能开发主分支。
• 可拉取 feature 子分支，仅能合并 master、feature 分支

• feature/xxx - 功能分支

• 用于开发需求、功能。由 develop 拉取。
• 不可拉取子分支，仅能合并 develop 分支
• 命名：feature/{待发布功能的版本号}-{功能简述} 。如：feature/1.1.0-error_cache

• hotfix/xxx - 缺陷分支（仅正式环境bug）

• 仅用于修复正式环境出现的bug，由 master 拉取。
• 不可拉取子分支，一般不合并其他分支。
• 命名：hotfix/{当前线上版本号} 。如：hotfix/1.0.0

• staging/xxx - 预发布分支

• 用于功能预发布，部署预发布环境。
• 不可拉取子分支，一般不合并其他分支。
• 命名：stage/{此次待上线版本号} 。如：stage/1.1.0

• release/xxx - 正式版本记录分支

• 用于部署正式环境，每次master发布时拉取一个对应版本的 release 分支。
• 不可修改、不可拉取分支、不可合并。仅做记录和方便回滚线上代码用。
• 命名：release/{此次上线的版本号} 。如：release/1.1.0

• test - 测试 2 服分支

• 用于部署测试 2 服环境，测试正式冒烟测试用。
• 不可拉取子分支，仅能合并 feature、develop 分支。

• sandbox - 测试 1 服分支

• 用于部署测试 1 服环境，开发自测，体验效果等。
• 不可拉取子分支，仅能合并 feature、develop 分支。

项目开发流程

假设当前已有线上版本 v1.0.0：
当前拥有 master（tag为v1.0.0）、develop、stage/1.0.0、test、sandbox 分支。分支内容相同。
待做 1.1.0（任务列表）、1.2.0（表格） 两个版本的功能点。

文字版流程

• 准备开发：从 develop 拉取 feature/1.1.0-task、feature/1.2.0-excel 两个功能分支。
• 开发中，测试1服查看效果：将 feature 分合并至 sandbox 分支。
• 开发完成，测试2服做冒烟测试：将待测试的 feature 分支合并至 test 分支。
• 冒烟bug：直接在对应的 feature 分支修改。
• 冒烟通过，准备预发布1.1.0：
• 提交合并请求，code review 后将 feature/1.1.0-task 合并至 develop 。
• feature/1.1.0-task 分支不得再有任何改动。
• 从 develop 拉取 stage/1.1.0 预发布版本分支。将 stage/1.1.0 分支代码发布到 预发布环境。
• 预发布bug：直接在 stage/1.1.0 分支上提交修改。只改bug！
• 预发布测试通过，准备正式上线：
• 提交合并请求，将 stage/1.1.0 合并至 master 。同时拉取 release/1.1.0 分支做版本备份。
• stage/1.1.0、release/1.1.0 分支不得再有任何改动。
• 将 master 合并至 develop（将 stage 可能出现的改动同步至开发分支）
• 将 develop 合并至 feature/1.2.0-excel（更新线上最新代码到未发布的功能分支，防止未发布的功能分支版本过老，未来开发冲突过多）
• 正式服出现bug（当前线上版本为 1.1.0）：
• 从 master 拉取 hotfix/1.1.0 分支，在该分支上提交代码修复bug。
• 将 hotfix/1.1.0 分支发布到预发布环境进行测试验证。
• 测试验证通过，提交合并请求。master 版本号第三位加 1。
• 将 hotfix/1.1.0 合并至 master。同时拉取 release/1.1.1 分支做版本备份。
• 重复 master 更新后的步骤，同步至 develop， develop 同步至未发布的 feature。

流程图

项目开发流程注意事项

1. 已进入预发布，未正式上线。此时需要上线一个紧急的功能（非bug），但 develop、stage 当前版本的代码不能上线，如何处理？

• 假设当前版本 1.0.0 ，已处于预发布的功能版本为 1.1.0 。
• 将当前 stage、待发布的 feature 分支版本改为 1.2.0 。从 master 拉取 feature 1.1.0 版本功能分支。
• feature 1.1.0 开发完成，从 master 重新拉取 test 分支，将 feature 合并至 test 分支测试。
• 冒烟测试通过，直接从该 feature 拉出 stage/1.1.0 分支，进行预发布测试。
• 预发布测试通过，合并至 master。发布正式环境。
• 将 master 合并至 develop 、stage/1.2.0 分支。
• 继续 stage/1.2.0 的测试。

1. 从 develop 拉取了两个 feature 分支：f1、f2 。开发一半时发现两个 feature 分支有依赖怎么办？

• 最好在开始前就确定好两个功能的相关性。若相关则只创建一个 feature 分支。
• 若已经创建，则需要将两个 feature 分支合并为一个。

1. 已进入预发布，未正式上线。线上碰到了紧急bug需要立刻修复并验证，如何处理？

• 按照正常线上bug出现流程处理，从 master 拉取 hotfix 分支。
• 改完bug后，暂停 stage 分支的测试。将 hotfix 分支的内容发布到 预发布环境上先进行验证。
• 验证通过，将 hotfix 合并到 master，再把 master 分支合并到 stage、develop 上。

1. 已进入预发布，未正式上线。有两个 feature 功能，领导突然说只上其中一个功能。如何处理？

• 弃用、删除当前版本的 stage 分支，develop 分支回滚。
• 重新将要上线的 feature 合并至 develop，继续正常走流程。

1. 已进入测试2服（冒烟测试）。有两个 feature 功能，领导说只要一个。如何处理？

• 从 master 重建 test 分支（删除重建）
• 重新合并要测试的 develop、feature 分支。

1. 测试1服被玩坏了，如何处理？

• 从 master 重建 sandbox 分支（删除重建）
• 重新合并想要合并的 develop、feature 分支。

1. feature 往测试分支上合并，有合并冲突怎么办？

• 在测试分支上处理合并请求冲突
• 绝不能将测试分支往 feature 上合并！

1. feature 往 develop 提交合并请求，有合并冲突。工蜂不给合并，develop不能直接合并后提交。如何处理？

• 创建一个临时的 merge 分支。将要合并的 feature 往该 merge 分支上合并。然后提 merge -> develop 的合并请求。
• 或者找有权限的直接在 develop 分支处理合并请求。（找大佬）
• 或者将已合并其他分支的 develop 合并到自己的 feature 分支上。在自己分支上处理好冲突后才提合并到 develop 的合并请求。逐个 feature 合并。（反正 feature 也是能回滚的）

代码提交规范

规范格式

<【版本xxx】> <【类型】> <本次提交内容简述>
[可选：需求/缺陷的链接]
[可选的正文]
示例
【版本1.0.1】【需求】任务模块需求功能开发
https://xxx.xxx.xxx

1. 任务列表开发
2. 任务文件上传机制开发
3. ...其他修改

...
代码提交注意事项

提交的类型有：需求、缺陷、优化等。
当类型为 需求、缺陷 时，必须携带对应的单子链接。
优化时表示代码优化、开发自测问题的修复等。不需要也没有单子，此时可以不填写链接。
遇见代码冲突时，一定要慎重解决，与另一个分支的开发协商处理。不能随意覆盖他人修改！
解决完成后，在项目内全局搜索 <<<<<<<<< 字符。防止漏掉的冲突未解决。