# 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 到当前分支,否则会在其他分支看到修改的内容,引起误解。