从分支管理和 Commit 提交两个方面总结一下规范
分支规范
分支介绍
Production 分支
也就是我们经常使用的Master分支，这个分支最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改Develop 分支
这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支Feature 分支
这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个ReleaseRelease 分支
当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后，我们合并到Master和Develop分支Hotfix 分支
当我们在Production发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release
分支流程（下面第一个参考链接里有详细图解）
初始分支
Master 和 Develop
所有在 Master 分支上的 Commit 应该 Tag
Feature 分支
分支名 feature/*
Feature分支基于Develop分支创建，做完后，必须合并回Develop分支, 合并完分支后一般会删掉这个Feature分支，但是也可以保留
Release分支
分支名 release/*
Release分支基于Develop分支创建，打完Release分之后，我们可以在这个Release分支上测试，修改Bug等。同时，其它开发人员可以基于开发新的Feature (记住：一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)
发布Release分支时，合并Release到Master和Develop， 同时在Master分支上打个Tag记住Release版本号，然后可以删除Release分支了
维护分支 Hotfix
分支名 hotfix/*
hotfix分支基于Master分支创建，开发完后需要合并回Master和Develop分支，同时在Master上打一个tag
代码示例
a. 创建develop分支
git branch develop
git push -u origin develop
b. 开始新Feature开发
git checkout -b some-feature develop
# Optionally, push branch to origin:
git push -u origin some-feature
# 做一些改动
git status
git add some-file
git commit
c. 完成Feature
git pull origin develop
git checkout develop
git merge --no-ff some-feature
git push origin develop
git branch -d some-feature
# If you pushed branch to origin:
git push origin --delete some-feature
d. 开始Relase
git checkout -b release-0.1.0 develop
# Optional: Bump version number, commit
# Prepare release, commit
e. 完成Release
git checkout master
git merge --no-ff release-0.1.0
git push
git checkout develop
git merge --no-ff release-0.1.0
git push
git branch -d release-0.1.0
# If you pushed branch to origin:
git push origin --delete release-0.1.0
git tag -a v0.1.0 master
git push --tags
f. 开始Hotfix
git checkout -b hotfix-0.1.1 master
g. 完成Hotfix
git checkout master
git merge --no-ff hotfix-0.1.1
git push
git checkout develop
git merge --no-ff hotfix-0.1.1
git push
git branch -d hotfix-0.1.1
git tag -a v0.1.1 master
git push --tags
注意事项
- Master 分支、Develop 分支需要加保护，向其合并时提 merge request
- 合并代码到 Master 和 Develop 时应使用 --no-ff 禁止快进式合并，以保持提交记录干净简洁
Commit 规范
原则
- 单个 commit 解决单个问题
- <type> 和 <subject> 必填
- <subject> 使用中文，动词开头，描述要清晰简洁，结尾不加句号
- 需要详细说明的使用 <body>
格式
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
<BLANK LINE>
<revert>
格式示例
fix(route): 404 页面跳转不正确
主体内容
Closes #123, #245, #992
type 使用
feat： 新功能,新特性（feature）
fix： 修复bug
docs： 文档（documentation）
style： 代码格式修改(比较小的代码变动, 功能保持不变)
test： 测试用例修改,或增加测试代码
refactor：代码重构,内部处理逻辑/算法逻辑发生较大改变.（即不是新增功能，也不是修改bug的代码变动）
chore： 构建过程或辅助工具的变动, 比如构建流程, 依赖管理等.(无法判断的提交推荐用这个)
refactor: 对现有代码进行一定的重构
perf: 提高性能的代码更改
参考链接
Git 在团队中的最佳实践--如何正确使用Git Flow
Git 最佳实践原则
Git 合并时 --no-ff 的作用
# git merge和git merge --no-ff的区别
