参考

http://www.yujujie.cn/shbk/38997.html

分支管理规范

Git Flow 分支说明

Master

发版分支 + 保护分支。功能代码在 Release 分支上测试通过、或 BUG 已在 Hotfix 分支上修复，则需要将代码合并到 Master 分支。代码合并到 Master 分支，即代表可以随时发版，发版成功时需要基于 Master 分支上的最新提交节点打 Tag。

Hotfix

修复分支 + 临时分支。线上出现紧急 Bug 时，需要基于对应版本的 Tag 创建修复分支，问题修复完成时以此分支进行提测。问题修复后，需将代码合并到 Develop 和 Master 分支。

基于发版 Tag 创建，最后合并到 Develop 和 Master 分支。

Release

预发布分支 + 临时分支。功能开发完成并合并到 Develop 分支时，基于 Develop 分支创建 Release 分支进行提测 。Release 分支上出现影响发版的 Bug 时，需要创建 Feature 分支修改 Bug;当测试通过后，需将代码合并到 Develop 和 Master 分支。

基于 Develop 分支创建，最后合并到 Develop 和 Master 分支。

Develop

开发分支 + 保护分支。多人协作开发时的代码合并总分支，功能分支向 Develop 分支合并时，往往会有 CodeReview 流程。

基于 Master 分支创建。

Feature

功能分支 + 临时分支。有新需求时，基于最新的 Deveop 分支创建功能分支，功能开发完成时，需将代码合并到 Develop 分支。

基于 Develop 分支创建，最后合并到 Develop 分支。

Tag&Branch 的区别

Tag 和 Branch 类似，都是引用或者说者指针。在工程里 .git/refs 目录下能够清楚的看到，各个 Tag 和 Branch 所指向的提交节点的 SHA-1 值。

区别：

• Tag：Tag 的位置是固定的，在给指定提交打好标签以后，它就固定于此位置；
• Branch：Branch 的位置是会不断变动的，随着分支的向前推移或者向后回滚，都在不断变化；尽量使用 Tag，保存代码片段。

Git Commit 提交规范

Commit Message 格式

分为三个部分，头部、主体、底部。

头部

type 类型，修改的类型级别：

• feat：新功能(feature)
• fix：修补 bug
• docs：文档(documentation)
• style： 格式(不影响代码运行的变动)
• refactor：重构(即不是新增功能，也不是修改 bug 的代码变动)
• test：增加测试
• chore：构建过程或辅助工具的变动

scope 修改范围：主要是这次修改涉及到的部分，最好简单的概括。

subject 修改的副标题：主要是具体修改的功能点。

主体

主要对本次 commit 的详细描述，可以分成多行。

底部

主要放置不兼容变更和 Issue 关闭的信息。

为了方便代码的快速提交，body 和 fotter 部分可以省略。

使用介绍

需求开发或者修改 Bug 时，提交代码时要添加对应 Jira 编号：

git commit -m "feat(CHESS-1217): 我的页面增加分享入口及分享功能开发"

修改 Bug 时，需要指明修改代码所在模块：

git commit -m "fix(分享): 修改修改部分手机分享大图为空问题"

没有具体模块、或者多模块代码一起提交时，可使用其他提交方式：

git commit -m "fix(BUG): 修改推送红点提示逻辑"

代码评审

代码评审发生在 Feature 分支向 Develop 分支合并的过程中。

代码评审流程

不同的颜色块，代表不同的角色；

创建一个 Merge Request 可以进行多次 Push；

开发人员推动整个代码评审流程的执行，包含及时通知组员评审代码、通知组长合并代码等。

保护分支设置

在 GitLab 打开要设置的工程 (Maintainers 角色)，选择 Setting -> Repository -> Protected Branches，将 master 和 develop 分支设置为保护分支，只能是 Maintainers 角色 可以合并请求，并且禁止直接 push 代码。之后，所有代码只能通过创建 Merge Request 的方式合并到 develop 和 master 分支;为了代码库的安全，需要回收 Maintainers 权限，除组长外的开发人员都是 Developer 权限。

Merge Request

创建 Merge Request

填写必要信息

Title：简单总结本次 Merge 的修改点；

Description：详细描述修改内容，影响范围等；

Assignee（指派人）：委托人，选择具有 Maintainers 角色的成员，该成员会收到合并请求的邮件通知，最后由该成员合并请求；

Approvers（审核者）：一般选择小组成员，小组成员具有审核代码权限，对不合格代码可以要求开发者修改；

分支选择，功能分支向 develop 分支合并时，会有删除源分支选项，建议勾选；

针对本次合并的提交，一次合并请求可以包含多次提交。

代码评审及合并请求

只有评审成员评审通过时，合并按钮才会高亮，才能合并代码；

参与代码评审的成员，认为代码没有问题时，可点击该按钮；

针对当前代码创建的讨论，有讨论存在时，开发者需要及时解决；

如果代码有问题，可直接创建一个讨论，即 3 列表会增加，开发者修改之后可关闭讨论；

代码修改之后，或者不需要修改，点击关闭讨论。

其他注意事项

1、提交合并请求时，先同步最新代码

提交合并代码前，建议先执行 git fetch 和 git merge/rebase 将 develop 分支下的最新代码更新到开发分支，再提交合并请求，避免造成冲突。

2、合并代码到 master 分支

通过 develop 分支提测且测试通过后，将 develop 分支的代码合并到 master 分支进行发版，版本发布完成时及时打标签。