别乱提交代码了，你最好知道的 Git 分支开发规范！别错过好文哦

create17

发布于 2021-04-07 11:14:15

1.1K0

发布于 2021-04-07 11:14:15

文章被收录于专栏：大数据实战演练大数据实战演练

点击上方蓝色“大数据实战演练”，选择“设为星标”或“置顶”

回复“资料”领取独家整理的学习资料！

每一个成功人士的背后，必定曾经做出过勇敢而又孤独的决定。

放弃不难，但坚持很酷~

作者：稻草叔叔

来源：juejin.im/post/6844903635533594632

整理 + 丰富：create17

Git 是目前最流行的源代码管理工具。为规范开发，保持代码提交记录以及 git 分支结构清晰，方便后续维护，现规范 git 的相关操作。

分支命名

1、master 分支

master 为主分支，也是用于部署生产环境的分支，所有提供给用户使用的正式版本，都在这个主分支上发布。为确保 master 分支稳定性， master 分支一般由 develop 以及 hotfix 分支合并，任何时间都不能直接修改代码。

2、develop 分支

master 分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做 develop。

develop 为开发分支，始终保持最新完成以及 bug 修复后的代码，一般开发的新功能时，feature 分支都是基于 develop 分支下创建的。

如果想正式对外发布，就在 master 分支上，对 develop 分支进行"合并"（merge）。

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 分支。

常见任务

增加新功能

(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

修复紧急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，同步代码

测试环境代码

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

生产环境上线

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

日志规范

在一个团队协作的项目中，开发人员需要经常提交一些代码去修复bug或者实现新的 feature 。而项目中的文件和实现什么功能、解决什么问题都会渐渐淡忘，最后需要浪费时间去阅读代码。但是好的日志规范 commit messages 编写有帮助到我们，它也反映了一个开发人员是否是良好的协作者。

而项目中的文件和实现什么功能、解决什么问题都会渐渐淡忘，最后需要浪费时间去阅读代码。但是好的日志规范 commit messages 编写有帮助到我们，它也反映了一个开发人员是否是良好的协作者。

编写良好的 Commit messages 可以达到3个重要的目的：

加快 review 的流程
帮助我们编写良好的版本发布日志
让之后的维护者了解代码里出现特定变化和 feature 被添加的原因

目前，社区有多种 Commit message 的写法规范。来自Angular 规范是目前使用最广的写法，比较合理和系统化。如下图：

Commit messages的基本语法

当前业界应用的比较广泛的是 Angular Git Commit Guidelines

https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines

具体格式为:

<type>: <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

type: 本次 commit 的类型，诸如 bugfix docs style 等
scope: 本次 commit 波及的范围
subject: 简明扼要的阐述下本次 commit 的主旨，在原文中特意强调了几点：
- 使用祈使句，是不是很熟悉又陌生的一个词
- 首字母不要大写
- 结尾无需添加标点

body: 同样使用祈使句，在主体内容中我们需要把本次 commit 详细的描述一下，比如此次变更的动机，如需换行，则使用 |

footer: 描述下与之关联的 issue 或 break change

Type的类别说明：

feat: 添加新特性
fix: 修复bug
docs: 仅仅修改了文档
style: 仅仅修改了空格、格式缩进、逗号等等，不改变代码逻辑
refactor: 代码重构，没有加新功能或者修复bug
perf: 增加代码进行性能测试
test: 增加测试用例
chore: 改变构建流程、或者增加依赖库、工具等

Commit messages格式要求

# 标题：50个字符以内，描述主要变更内容
#
# 主体内容：更详细的说明文本，建议72个字符以内。需要描述的信息包括:
#
# * 为什么这个变更是必须的? 它可能是用来修复一个bug，增加一个feature，提升性能、可靠性、稳定性等等
# * 他如何解决这个问题? 具体描述解决问题的步骤
# * 是否存在副作用、风险?
#
# 如果需要的话可以添加一个链接到issue地址或者其它文档