GIT分支命名规范（转载）

Git分支使用规范

• 几乎所有的版本控制系统都以某种形式支持分支。 使用分支意味着你可以把你的工作从开发主线上分离开来，以免影响开发主线。有人把 Git 的分支模型称为它的“必杀技特性”，因为基于指针的实现使其足够轻量。
• Git 鼓励在工作流程中频繁地使用分支与合并，哪怕一天之内进行许多次，但仍要遵循一定的规范

分支命名

master 分支

• master 为整个项目主分支，也是用于部署生产环境的分支，有且仅有一个，除项目负责人以外的开发人员不能向master分支合并内容
• master 分支要确保稳定性
• master 分支一般由 develop 以及 hotfix 分支合并，任何时间都不能直接修改代码

develop 分支

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

feature 分支

• feature是为了开发后续版本的功能，从Develop分支上面分出来的。开发完成稳定后，要再并入Develop
• 分支命名: feature/ 开头的为特性分支， 命名规则: feature/user_module、 feature/cart_module

release 分支

• release是发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。

hotfix/fixbug 分支

• fixbug分支是从master分支上面分出来的。fix结束以后，再合并进Master和Develop分支。最后，删除"fixbug分支"。
• 分支命名: hotfix/ 开头的为修复分支，它的命名规则与 feature 分支类似
• 线上出现紧急问题时，需要及时修复，以 master 分支为基线，创建 hotfix 分支，修复完成后，需要合并到 master 分支和 develop 分支
• 当有一组 feature 开发完成，首先会合并到 develop 分支，进入提测时，会创建 release 分支。
• 如果测试过程中存在 bug 需要修复，则直接由开发者在 release 分支修复并提交。
• 当测试完成之后，合并 release 分支到 master 和 develop 分支，此时 master 为最新代码，用作上线。

注意

• 以上规范不一定是必须的，一般是根据实际情况来的，总结下自己工作中的一些问题
• 自己的分支一定要自测，切记不要提交后，影响到其他代码，更别说别人拉下代码还报错这种低级错误
• 本地分支要做到勤提交，分小功能提交，一次提交一大堆各种功能的做法也要杜绝
• 每天第一件事就是更新 develop 分支内容到本地分支，避免大规模 merge，太容易出错了
• 迭代新版本时，一定要保证当前开发分支和线上分支一样