分支规范

master主分支

master主分支始终保持稳定的可发布版本，用于部署生产环境，并且仅在发布新的可供部署的代码时才更新master分支上的代码

除项目负责人以外的开发人员不能向master合并内容

一般由develop以及hotfix分支合并，任何时间不能直接修改代码

develop开发分支

dev-版本号+期次号

为不稳定版本，始终保持最新完成以及代码修复后的代码，主要针对测试版本的发布

原则上不允许直接在dev分支上进行功能开发，必须新建feature分支进行开发

当develop分支上的代码已实现了软件需求说明书中所有的功能，通过了所有的测试后，并且代码已经足够稳定时，就可以将所有的开发成果合并回master分支了。对于master分支上的新提交的代码建议都打上一个新的版本号标签(TAG),供后续代码跟踪使用

hotfix紧急热修复分支

hotfix-[问题名称｜bug编号]

hotfix分支用来快速给已发布产品修复bug或微调功能，从master分支或者release/*分支衍生出来，修复好后，先合并到dev分支验证。验证通过后需要回归master，然后将此分支删除

hotfix分支一旦建立就将独立，不可再从其他分支pull代码

feature功能开发分支(topic分支)

feature-[功能名称]

为了开发某个特定的功能，从dev分支上面分出来的,开发完成以后，合并回dev分支

一般而言，feature分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里

bugfix问题修复分支

bugfix-[bug编号]

从dev分支创建，用来快速给未上线产品或者迭代需求修复bug或微调功能

refactor重构分支

refactor-[重构名称]

从dev分支创建，用于代码的重大规模重构（小规模重构创建feature分支即可）

重构以后，必须经过严格测试通过，才能向dev分支合并

release分支

当develop分支上的代码已经包含了所有即将发布的版本中所计划包含的软件功能，并且已通过所有测试时，我们就可以考虑准备创建release分支了。而所有在当前即将发布的版本之外的业务需求一定要确保不能混到release分支之内（避免由此引入一些不可控的系统缺陷），成功的派生了release分支，并被赋予版本号之后，develop分支就可以为“下一个版本”服务了。所谓的“下一个版本”是在当前即将发布的版本之后发布的版本。版本号的命名可以依据项目定义的版本号命名规则进行。

release分支是为发布新的产品版本而设计的。在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等等）。通过在release分支上进行这些工作可以让develop分支空闲出来以接受新的feature分支上的代码提交，进入新的软件开发迭代周期。

使用规范-建议流程

第一步：新建分支

每次开发新功能，都应该新建一个单独的分支，获取主干最新代码

git checkout master
git pull
git checkout -b myfeature

第二步：提交分支

分支内容修改完成后就可以提交commit了

git add [filename] 选择性提交文件
git add --all/.
git status 查看发生变动的文件
git commit

第三步：与主干同步

在分支的开发过程中，要经常与远程当前分支保持同步

git fetch origin
git rebase origin/master
或者直接使用git pull

第四步：合并commit

在合并到主分支时，希望只有1个（最多两三个）commit

第一种方法：git rebase -i origin/master

第二种方法：先撤销（git reset HEAD~x）过去的commit再建立一个新的

第五步：推送到远程仓库

git push

第六步：pull Request

提交到远程仓库以后，就可以发出 Pull Request 到master分支，然后请求别人进行代码review，确认可以合并到master。

commit提交规范

Git在提交代码是都需要写commit message（提交说明），否则就不允许提交

目的

commit message 应该清晰明了，说明本次提交的目的。在多人协作的时候，有问题也方便查看提交日志。

git commit -m "commit message"

如果一行不够可以只执行git commit进入文本编辑器

commit message剖析

commit message分为三部分 header(必需的)，body和footer

不管是哪一个部分，任何一行都不要有太多字符。这是为了避免自动换行影响美观

herder

Header部分只有一行，包括三个字段：type（必填）、scope（影响范围，选填）和subject（必填）

type 用于说明 commit 的类别

名称	说明
feat	新功能
fix	修改Bug
docs	修改文档
style	修改格式化代码结构，没有逻辑上的代码修改（如空白，格式、缺少分号等）
refactor	既不是新增功能，也不是修改bug的代码变动（比如重命名变量）
test	增加测试代码，单元测试一类的，没有生产代码的变更
chore	构建过程或辅助工具的变动
build	主要目的是修改项目构建系统(例如 glup，webpack，rollup 的配置等)的提交
ci	对Cl配置文件和脚本的更改（如：Travis、Circle、Browserstack、Saucelabs），修改项目继续集成流程
revert	回滚到上一个版本
pref	性能提升的修改
deps	升级依赖

scope 用于定义 type 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。

subject是 commit 目的的简短描述，不超过50个字符。

body

Body 部分是对本次 commit 的详细描述，可以分成多行，每行尽量不超过72个字符。应该说明代码变动的动机，以及与以前行为的对比。

footer

Footer 部分只用于两种情况

不兼容变动：如果当前代码与上一个版本不兼容，则 Footer 部分以BREAKING CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法。

关闭issue