git开发流程

一、分支管理规范

Git Flow 模型

Git 流程使用规范

(图片来源：A successful Git branching model)

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 修改的副标题：

主要是具体修改的功能点

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

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

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

使用介绍

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

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

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

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

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

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

相关工具

Git Hook 自定义拦截脚本：commit-msg

使用环境：python3.7

使用方式：

打开工程目录下的 .git/hooks 文件夹

将 commit-msg 脚本复制到文件夹下，即可

全局设置：通过以下方式，可全局设置，每次 git clone 时，自动将 commit-msg 脚本添加到工程的 hooks 目录中：全局设置 commit-msg。

其他工具：

Commitizen：辅助撰写合格 Commit message 的工具

Commitlint：Commit message 规则校验工具

拓展

GitLab 与 Jira 关联

效果：Git Commit 时，在 message 里面添加工单号，可在 Jira 对应工单详情页查看到本次提交。

配置：官方文档。