# MASSCMS 代码 Git 分支管理规范
> MASSCMS 代码 Git 分支管理规范
## 一、分支与角色说明
Git 分支类型
master 分支（主分支） 稳定版本
develop 分支（开发分支） 最新版本
release 分支（发布分支） 发布新版本
hotfix 分支（热修复分支） 修复线上 Bug
feature 分支（特性分支） 实现新特性
_project 分支（项目分支）每个新的项目单独开一个分支_
角色与项目角色对应关系
Owner（拥有者） Git 管理员
Master（管理员） 开发主管
Developer（开发者） 开发人员
Reporter（报告者） 测试人员
Guest（观察者） 其他人员
## 二、分支简明使用流程
1. 每开发一个新功能，创建一个 feature 分支，多人在此分支上开发；
2. 提测时，将 master 分支和需要提测的分支汇总到一个 release 分支，发布测试环境；
3. 发现 bug 时，在 feature 分支上 debug 后，再次回到 2；
4. 发布生产环境后，将 release 分支合并到 master 分支，删除 release 分支；
5. _项目的功能定制，单独在 project 分支进行，每个 peoject 分支下面开设单独的 feature 分支；_
## 三、创建新项目（master 分支）
主分支，主分支只用来发布重大版本。所有提供给用户使用的正式版本，都在这个主分支上发布。
- 开发主管提交代码初始版本到 master 分支，并推送至 Git 系统；
- 开发主管在 Git 系统中设置 master 分支为 Protectd 分支（保护分支）；
- Protected 分支不允许 Developer 角色推送代码，但 Master 角色可以推送代码；
## 四、进行产品迭代开发（develop 分支）
日常开发基于此分支来完成。
- 开发主管在 master 分支上创建 develop 分支（开发分支），并推送至 Git 系统；
- master 分支与 develop 分支一样，有且仅有一个；
- 对于非并行项目可以使用 develop 分支开发方式，对于多人并行开发项目，使用 feature 分支开发方式，但 develop 和 feature 开发方式不应同时使用；
Git 创建 Develop 分支的命令：
`git checkout -b develop master`
将 Develop 分支发布到 Master 分支的命令：
### 切换到 Master 分支
`git checkout master`
### 对 Develop 分支进行合并
`git merge –no–ff develop`
这里稍微解释一下，上一条命令的–no–ff 参数是什么意思。默认情况下，Git 执行”快进式合并”（fast-farward merge），会直接将 Master 分支指向 Develop 分支。使用–no–ff 参数后，会执行正常合并，在 Master 分支上生成一个新节点。为了保证版本演进的清晰，我们希望采用这种做法。关于合并的更多解释，请参考 Benjamin Sandofsky 的《Understanding the Git Workflow》。
## 五、开发产品新特性（feature 分支）
功能分支，它是为了开发某种特定功能，从 Develop 分支上面分出来的。开发完成后，要再并入 Develop 分支。
_命名规则：采用 feature/feature1 的形式_
- 每个新需求或新的研究创建一个 feature 分支；
- 命名规范：
f-分支创建日期-新特性关键字，例如：f-20150508-满立减；
- 推荐使用 feature 分支，但 feature 分支的生命周期不能跨一次迭代；
创建一个功能分支：
`git checkout -b f-20150508-满立减 develop`
开发完成后，将功能分支合并到 develop 分支：
`git checkout develop`
`git merge –no-ff f-20150508-满立减`
删除 feature 分支：
`git branch -d f-20150508-满立减`
## 六、发布产品测试环境（release 分支）
release 分支，它是指发布正式版本之前（即合并到 Master 分支之前），我们可能需要有一个预发布的版本进行测试。
release 分支是从 Develop 分支上面分出来的，预发布结束以后，必须合并进 Develop 和 Master 分支。
_命名规则：采用 release/release1 的形式_
开发负责人需完成以下任务：
- 确认要发布的 feature 分支上的功能是否开发完毕并提交；
- 创建 release 分支（发布分支），将所有要发布的分支逐个合并到 release 分支，有如下情况：
- ①.feature 分支（可能有多个）
- ②.master 分支（期间可能有其他 release 版本更新到了 master）
- 命名规则：r-分支创建日期-新特性和待发布版本号，例如：r-201505081712-买立减 v1.0.0，版本可根据需要添加;
- 删除本次发布的所有 feature 分支;
- 发布到测试环境，通知测试;
创建一个预发布分支：
`git checkout -b release-1.2 develop`
确认没有问题后，合并到 master 分支：
`git checkout master`
`git merge –no-ff release-1.2`
# 对合并生成的新节点，做一个标签
`git tag -a 1.2`
再合并到 develop 分支：
`git checkout develop`
`git merge –no-ff release-1.2`
最后，删除预发布分支：
`git branch -d release-1.2`
## 七、修复待发布版本中的 Bug（hotfix 分支）
修补 bug 分支。软件正式发布以后，难免会出现 bug。这时就需要创建一个分支，进行 bug 修补。
修补 bug 分支是从 Master 分支上面分出来的。修补结束以后，再合并进 Master 和 Develop 分支。
_命名规则：采用 hotfix/fixbug1 的形式_
如果发现 bug，开发人员在 feature 分支上修复测试人员提交给自己的 bug，修复完成后，由负责人再次创建 release 分支，发布测试环境。
创建一个修补 bug 分支：
`git checkout -b fixbug-0.1 master`
修补结束后，合并到 master 分支：
`git checkout master`
`git merge –no-ff fixbug-0.1`
`git tag -a 0.1.1`
再合并到 develop 分支：
`git checkout develop`
`git merge –no-ff fixbug-0.1`
最后，删除”修补 bug 分支”：
`git branch -d fixbug-0.1`
## 八、发布产品正式环境
开发负责人需完成以下任务：
根据修复后的 release 分支再次将 master 合并，打包发布生产环境;
确认发布成功，并线上验收通过后，将 release 分支合并到 master 分支;
在 master 分支上创建标签，命名规则：tag-日期-新特性和版本号，例如：tag-201505081712-买立减 v1.0.0，版本可根据需要添加，作为发版里程碑标记;
删除对应 release 分支;
## 九、修复产品线上 Bug（hotfix 分支）
线上的不同版本出现了 bug 怎么办？开发负责人需完成以下任务：
从 master 分支某个 tag 上创建一个 hotfix 分支（热修复分支），一般是最新的 tag 应该和当前生产环境对应；
命名规则：h-分支创建日期-bug 名称和待发布版本号，例如：h-201705081614-购物车点击没反应 v1.0.1;
开发人员完成 Bug 修复，提交 hotfix 分支到测试环境验收通过;
再次发布正式环境流程;
将 hotfix 分支合并到 master 分支;
在 master 分支上创建标签，命名规则：tag-日期-新特性和版本号，例如：tag-201505081712-买立减 v1.0.0，版本可根据需要添加，作为发版里程碑标记;
删除 hotfix 分支;
## 十、定制化项目开发
## 十一、Git 的特别注意事项
- 使用 Git 过程中，必须通过创建分支进行开发，坚决禁止在主干分支上直接开发。
- 提交时，一定要填写有意义的注释。
- 由于 git 分支是基于指针的概念，所以分支速度非常快，当多个分支时，实际指针指向的是同一个文件，当文件被修改时，使用的是暂存区保存修改，此时并未提交到相应分支。
- 所以切换分支的时候，暂存区只有一个，所以切换分支之前，一定要将所有修改 commit 到当前分支，否则会在其他分支看到修改的内容，引起误解。