Git 版本管理

在企业级发布中，依托于 Git 强大的版本管理能力进行发布，但同时由于发布的复杂性，研发人员往往因复杂性而碍手碍脚，其实这其中是有迹可循的。

一、名词解释

1. master分支

​ 只存线上的代码，只有确定可以上线时的才合并到master上，并且在master的基础上打Tag。

2. develop分支

​ 初次创建develop时，需要从master分支拉取，保持开发时代码和线上最新的代码相同。develop分支是在开发时的最终分支，具有所有当前版本需要上线的所有功能。

3. feature分支

   • 用于开发功能的分支，必须从最新的develop分支代码拉取。分支命名基本上是feature/xxxxx（和功能相关的名字）。
   • 不强制提交到远程仓库，可以本地创建。比如，我要开发登录功能，我从develop分支的最新代码创建新分支命名为feature/login，然后切换到这个新分支开始开发。
   • 开发完成后，测试差不多完成，合并到develop分支。

4. release分支

   • 当develop分支已经有了本次上线的所有代码的时候，并且以通过全部测试的时候，可以从develop分支创建release分支了，release分支是为发布新的产品版本而设计的。
   • 通过在release分支上进行这些工作可以让develop分支空闲出来以接受新的feature分支上的代码提交，进入新的软件开发迭代周期。
   • 在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等等）。
   • 比如，此次1.0版本所有的功能版本都已经合并到了develop上，并且所有测试都已经通过了测试，那我就创建新的release分支release/v1.0。切换到新分支，修改最新的版本号等，不允许大的更改。

5. hotfix分支

   • 当线上出现bug需要紧急修复时，从当前master分支派生hotfix分支。
   • 修改线上bug，修改完成后合并回develop和master分钟。
   • 比如，在线上v1.0登录功能出现问题，我从master拉取代码创建新的分支hotfix/v1.0_login，修改完成后合并到master和develop上。

6. tag

   • 上线合并到master以后,保留版本历史记录,从master创建tag版本

二、生命周期

分支	说明	创建来源	代码来源	目标分支	代码输入方式	生命周期	命名规则
★master	主干分支，通常作为代码基线，所有发布的代码最终都会合并到此分支。	无	release, hotfix	无	Pull request	长期	Master
★develop	开发分支，通常作为其他分支的源分支，也最终会合并回此分支	无	feature, release, hotfix	无	Pull request	长期	Develop
feature	功能分支，用于为未来的应用版本开发新的功能需求	develop	develop	develop	Merge	并入目标分支后，可以删除	feature_{jira_issue_key}
★release	发布分支，用于辅助新版本发布的准备工作，例如小bug的修复，或者版本号的修改等等	develop	develop	develop master	Merge	并入目标分支后，可以删除	release_{jira_issue_key}
hotfix	修复分支，用于正式版本的紧急修复	master	master	develop master release	Merge	并入目标分支后，可以删除	hotfix_{jira_issue_key}
tag	master发布版本快照	master	master	无	无	长期	tag_{jira_issue_key}

三、开发流程

动作	开发	测试	审查
从develop创建开发分支	√
创建 feature → develop 的 pull request	√
代码审查			√
合并代码到开发分支			√

四、 版本发布流程

	开发	测试	审查
创建并推送发布分支	√
创建 realease → develop 的 pull request	√
创建 realease → master的 pull request	√
审查 realease → develop 的 pull request			√
审查 realease → master 的 pull request			√
发布测试		√
合并代码到开发分支			√
合并代码到主干分支			√
关闭realease → develop 的 pull request			√
关闭realease → master 的 pull request			√
创建代码标签			√

五、Hotfix修复

	开发	测试	审查
创建并推送修复分支	√
创建 hotfix → develop 的 pull request	√
创建 hotfix → release的 pull request	√
创建 hotfix → master的 pull request	√
审查 hotfix → develop 的 pull request			√
审查 hotfix →release的 pull request			√
审查 hotfix → master 的 pull request			√
发布测试		√
合并代码到开发分支			√
合并代码到release分支			√
合并代码到主干分支			√
关闭hotfix → develop 的 pull request			√
关闭hotfix → release 的 pull request			√
关闭hotfix → master 的 pull request			√
创建代码标签			√

六、场景说明

1. 正常的业务需求流程

   1. 当接收到正常的业务需求时，需要约定一个大的发布版本（一次迭代）以及这个发布版本包含的多个jira任务，一个发布版本必须在一个时间点上发布；如果jira上的任务粒度太大，则需要拆分细化成更小的jira子任务（工作量在1~2人日为准，最好控制在一天以内）。

   2. 以develop为基准创建一个分支，分支名称为“feature-jira编号-开发人员姓名全拼”，如“feature-ONC-21-lishaohua”，jira任务ONC-21的所有开发工作都在feature-ONC-21-lishaohua分支上进行，所有开发过程的commit message需要填写具体的开发内容。

   3. 开发及单元测试工作完成后创建merge request合并到develop分支，合并请求消息同样需要复制jira的内容描述以及具体的开发内容。

   4. 开发人员的自测工作基于合并后的develop分支代码进行，如果这个发布版本所有jira任务全部自测通过后，基于测试通过的develop分支创建一个release分支，分支名称为“release-版本号”，如“release-ctrip1.0”，测试人员基于release分支进行测试。

   5. 测试人员继续在新建的release分支上进行回归测试和验证，如果存在bug直接在该分支修改并合并到develop分支；如果验证通过则准备生产上线，

   6. 生产上线时将release代码合并到master分支，并打tag，tag名称为“tag-版本号”，从release打包上线。

2. 紧急bug修复流程

   1. 当发现线上bug需要紧急修复时（开发人员需要确保bug修复已经在jira录入），需要以master分支为基准创建一个hotfix分支，分支名称为“hotfix-jira编号-开发人员姓名全拼”；

   2. bug修复代码直接在新建的hotfix分支上提交，commit message需要填写具体的开发内容。测试人员直接在hotfix分支测试测试

   3. 通过后，开发人员同时请求合并到master分支,release分支,develop分支，合并请求消息同样需要复制jira的任务描述以及具体的开发内容。

   4. 生产上线时将hotfix代码合并到master分支，并打tag，tag名称为“tag-版本号-jira编号”，从release打包上线。

3. 高优先级开发任务流程

   1. 如果在其他发布版本或迭代在开发中，而优先级更高的迭代需要同时进行，则需要特别注意。在创建feature分支时，要确保develop分支和master分支时一致的没有被未上线甚至未测试的代码污染过的，如果是则直接以develop分支为基准创建新的分支，命名规范如同正常的业务需求流程；如果develop分支上已经有其他未上线分支的代码且该分支代码上线优先级较低，则不能以develop分支为基准创建分支，需要以master分支为基准创建分支。

   2. 当更高优先级feature功能开发和自测完成后，需要上测试环境，这时，需要以master分支为基准创建一个release分支，release分支名称为“release-版本号”，所有较高优先级的feature分支合并到高优先级的release分支上，并在该分支进行测试。

   3. release分支测试通过后，合并到master分支准备上生产，同时release合并到develop分支；master分支生产上线后打tag，tag名称为“tag-版本号”，feature分支合并到高优先级的release分支上，并在该分支进行测试。

   4. release分支测试通过后，合并到master分支准备上生产，同时release合并到develop分支；master分支生产上线后打tag，tag名称为“tag-版本号”。