项目使用的简单 git 规范，基于 git 分支开发，防止甩锅。

目录

ー：分支命名

二：常见任务（观察分支名称）

---

 

ー：分支命名

---

master 分支

• master 为主分支，也是用于部署生产环境的分支，确保 master 分支稳定性
• master 分支一般由 develop 以及 hotfix 分支合并，任何时间都不能直接修改代码

develop 分支

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

feature 分支

• 开发新功能时，以 develop 为基础创建 feature 分支
• 分支命名:  feature/ 开头的为特性分支， 命名规则: feature/user_module，feature/cart_module

release分支

• release 为预上线分支，发布提测阶段，会 release 分支代码为基准提测
• 当有一组 feature 开发完成，首先会合并到 develop 分支，进入提测时，会创建 release 分支。
• 如果测试过程中若存在 bug 需要修复，则直接由开发者在 release 分支修复并提交。
• 当测试完成之后，合并 release 分支到 master 和 develop 分支，此时 master 为最新代码，用作上线。复制代码

hotfix 分支

• 分支命名: hotfix/ 开头的为修复分支，它的命名规则与 feature 分支类似
• 线上出现紧急问题时，需要及时修复，以 master 分支为基线，创建 hotfix 分支，修复完成后，需要合并到 master 分支和 develop 分支

 

二：常见任务（观察分支名称）

---

增加新功能，基于分支快速迭代

(dev)$: git checkout -b feature/xxx_module                       # 从 dev 建立特性分支 xxx_module ,并转入对应的特性分支
(feature/xxx_module)$: blabla                                    # 开发，添加代码
(feature/xxx_module)$: git add xxx                               # 将开发的代码添加到暂存区
(feature/xxx_module)$: git commit -m 'commit comment'            # 提交暂存区的代码到本地仓库
(feature/xxx_module)$: git checkout dev                          # 从 xxx_module 分支切换至开发者分支 dev
(dev)$: git merge feature/xxx --no-ff                            # 把特性分支合并到 dev

修复紧急bug

(feature/xxx_module)$: git checkout master                        # 如果在新功能分支，先切换
(master)$: git checkout -b hotfix/xxx                             # 从 master 建立并转到 hotfix 分支
(hotfix/xxx)$: blabla                                             # 开发，添加代码
(hotfix/xxx)$: git add xxx                                        # 将开发的代码添加到暂存区
(hotfix/xxx)$: git commit -m 'commit comment'                     # 提交暂存区的代码到本地仓库

# master 分支和 developer 分支都需要合并

(feature/xxx_module)$: git checkout master                        # 从 xxx_module 分支切换至开发者分支 master
(master)$: git merge hotfix/xxx --no-ff                           # 把 hotfix 分支合并到 master ，并上线到生产环境

(feature/xxx_module)$: git checkout dev                           # 从 xxx_module 分支切换至开发者分支 dev
(dev)$: git merge hotfix/xxx --no-ff                              # 把 hotfix 分支合并到 dev ，同步代码

项目上线之前 release 测试环境代码

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

生产环境上线

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

日志规范

---

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

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

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

一般规则为 【本次提交的主题，可以是优化（optimize）,可以是改 bug（debug）】【如果是修改 bug 后方可以跟禅道，jra 的 bug 编号】【之后可以编写修改的详情信息作为备注】

git 也支持提供这种规则模板可以搜索下。