Git开发规范

日常开发中，我们经常会跟Git打交道，可能服务器不一样，但是命令和规范基本都是一样的。

一.常驻分支

常驻分支为一个正常开发上线流程应该会有的分支。

1.master/prod/production

主分支，又称为生产环境分支，有时可能会使用（prod/production）来代替，生产环境的部署分支，生产环境相关操作，如：打包等应从改分支进行。

2.dev

全称（Develop），开发分支，我们正常的需求开发等，应该使用该分支。开发环境的部署和打包，使用该分支。

3.pre

全称（Pre production），预生产分支，一般根据项目而定，有的项目可能因为资源不足等原因，没有预生产分支，预生产分支，又为线上测试环境。预生产环境打包应从此分支进行。

二.临时分支

临时分支，顾名思义，是不会常驻的，一般，在merge完，完成使命后，会被删除。

1.feature

新需求的开发分支，从develop分支上面分出来的。开发完成后，要merge到develop分支。功能分支的命名，可以采用feature_*的形式命名(*为需求名称拼写，如feature_user_list)

2.hotfix

Bug修复分支。为了修复某个bug，从常驻分支上面分出来的。修复完成后，再merge到对应的分支。Bug修复分支的命名，可以采用fixbug_*的形式命名（*为bug说明，如fixbug_user_list）

三.开发流程

1.正常开发

1. 从dev分支切出一个新分支，根据是新功能还是bug，命名为feature_* 或 fixbug_*。
2. 开发者完成开发，提交分支到远程仓库。
3. 开发者发起merge请求（可在gitlab页面New merge request），将新分支请求merge到develop分支，并提醒代码检查人员进行review。
4. 代码检查人员对代码review之后，若无问题，则接受merge请求，新分支merge到develop分支，同时可删除新建分支；若有问题，则不能进行merge，可close该请求，同时通知开发者在新分支上进行相应调整。调整完后提交代码重复review流程。
5. 转测时，直接从当前develop分支merge到pre分支，重新构建测试环境完成转测。
6. 测试完成后，从pre分支merge到master/prod分支，基于master/prod分支构建生产环境完成上线。并对master分支打tag，tag名可为v1.0.0_2020.05.15.1（即版本号_上线时间）

2.开发过程中，修复Bug

即前一个版本已经转测但未上线，后一个版本又已在开发中并部分合并到了dev分支，转测后测试环境发现的bug需要修复，但是dev分支此时又有新内容且该部分内容目前不计划转测，可以从pre切出一个bug修复分支。完成之后需要同时merge到pre分支与dev分支。

3.生产环境Bug修复

生产环境的Bug分两种情况：

1. 紧急Bug：严重影响用户使用的为紧急Bug，需立即进行修复。如关键业务流程存在问题，影响用户正常的业务行为。
2. 非紧急Bug或优化：非关键业务流程问题，仅影响用户使用体验，或出现频率较小等，为非紧急Bug，可规划到后续版本进行修复。

修复紧急Bug：
：需要从master分支切出一个bug修复分支，完成之后需要同时merge到master分支与dev分支（如果需要测试介入验证，则可先merge到pre分支，验证通过后再merge到master分支上线）。

四.流程图

前言

文章首发于Noah Sun’s Home Git开发规范参考
，转载请注明出处，谢谢！

分支管理

git 的分支管理功能非常强大，为了提高效率、避免分支混乱，我们参考git flow的开发流程规范或者可以直接使用git flow工具。

分支构成

主要分支

master分支：永远处在即将发布（production-ready）状态；
develop分支：为开发分支，始终保持最新完成以及bug修复后的代码。

辅助分支

feature分支：开发新功能的分支，基于develop，开发完成后merge回develop；
release分支：准备要发布版本的分支（测试环境用的），用来修复SIT（System Integration Testing） bug；基于develop分支，完成后merge回develop和master分支；
hotfix分支：修复线上（master）紧急bug，等不及release分支就必须马上上线；基于master分支，完成后merge回master和develop分支。

命名规范约定如下：

• feature分支命名：feature/name
• release分支命名：release/name
• hotfix分支命名：hotfix/name

常见的开发流程

增加新功能

(develop)$: git checkout -b feature/xxx            # 从develop建立功能分支
(feature/xxx)$: blabla                             # 开发
(feature/xxx)$: git add xxx
(feature/xxx)$: git commit -m 'commit comment'
(develop)$: git merge feature/xxx --no-ff          # 把功能分支合并到develop

修复紧急bug

(master)$: git checkout -b hotfix/xxx         # 从master建立hotfix分支
(hotfix/xxx)$: blabla                         # 开发
(hotfix/xxx)$: git add xxx
(hotfix/xxx)$: git commit -m 'commit comment'
(master)$: git merge hotfix/xxx --no-ff       # 把hotfix分支合并到master，并上线到生产环境；注意，非管理员请用Merge Request；
(develop)$: git merge hotfix/xxx --no-ff      # 把hotfix分支合并到develop，同步代码

测试环境发布测试

(develop)$: git checkout -b release/x.y.z           # 从develop建立预发布分支
(release/x.y.z)$: blabla                            # 开发或者从其他feature分支合并代码
(release/x.y.z)$: git merge develop --no-ff         # 把develop分支合并到release/x.y.z，然后在测试环境拉取并测试

生产环境上线

(master)$: git merge release/x.y.z --no-ff          # 把release/x.y.z或者develop测试好的代码合并到master
(master)$: git tag -a 0.1.0 -m 'xxx'                # 给版本命名，打Tag

注意：这一步由master管理员做，普通开发人员合并代码请用Merge Request。

Tag管理

Tag生成时间

master分支每次发布时，必须打tag。

Tag命名规范

版本格式：主版本号.次版本号.修订号，如：1.0.1。

版本号递增规则如下：

• 主版本号：当你做了不兼容的 API 修改；项目架构发生巨大变化；
• 次版本号：当你做了向下兼容的功能性新增；
• 修订号：当你做了向下兼容的问题修正；小的修改，如代码格式修正等。

参考

您必须知道的 Git 分支开发规范
分支管理规范
git分支管理和工作流规范：具体规范

       git是当前比较流行的版本管理工具，趁着今天有空，对我们实际使用的情况做一个总结。

1. 主要分支：master、develop

       master：永远和线上产品最后一次发布的代码一致，保证随时可发布
　　
　　develop：最新的开发完整功能的分支（完整功能是指某个模块、需求或者特性完全开发完成后才合并到develop上）
　　这两个分支，所有开发人员都没有push权限，只有开发组长或者其他专人有merge权限，开发人员在自己的分支开发完成后，提交merge请求，开发组长或者其他专人负责review后进行合并。

2. 其它分支：feature、hotfix、release

       feature：功能开发分支。某（几）个开发人员在开发某个功能的时候，从develop上自行拉取分支，待功能开发完成，合并到develop，然后提测。我们的命名规范为：feature-姓名-开发的功能-日期。如：feature-zhangsan-orderList-20181020
　　
　　hotfix：紧急处理线上bug的分支。在线上有紧急bug需要修复的时候，从master拉取，修改完成测试通过之后，发布正式，然后合并到master和develop。命名规范同feature。如：hotfix-zhangsan-importBugFix-20181020
　　
　　release：发布分支。某个迭代开发完成，即将发布的时候从develop拉取此版本，此时，所有此次要发布的feature已经合并到了develop，这个版本只是用来做面向此次发布的工作，比如修复bug、打包发布等等。测试通过，发布之后，将此分支合并到master和develop。命名规范我们是按照迭代名称来取的，如：release-18.6.2-20181020
　　
　　ps：每次发布完成合并后，要从master打tag，并删除已发布分支，上面就没有一一说明了
　　
　　下面特地画了一张图：

以上是我的理解和用法，如有不正确的，还请指正。