git--基础--04--分支管理规范

git–基础–04–分支管理规范

---

1、 git-flow模型

1. 分支管理采用git-flow 模式，预设两个主分支在仓库中
   1. master分支
   2. develop分支
2. 开发人员不可以直接操作这两个分支，在开发完成的功能分支提交到远程仓库后，需要提出merge request，由技术管理人员合并至develop分支。

2、master和develop分支

1. 称作为长期分支。
2. 存活在项目的整个生命周期中。

2.1、发布主分支master

1. 每个代码库只有一个
2. 只用于发布生产的正式版本，同时要对应生成一个tag。
   1. master分支的所有提交都应是提供给用户的正式版本。
   2. 需确保master分支的任何内容都是可部署的
3. 只允许对master进行其他分支的合并和创建标记操作，不能单独在master分支上进行提交。
4. master分支应该只授权给项目代码的管理者，不允许其余人员操作。

2.2、开发主分支develop

1. 是进行开发的基础分支，其他分支是基于develop分支切分出来的
2. 其他分支开发完成后，会合并在develop分支中，等待被整合到master分支中。

3、其他分支

1. 也叫临时分支，只是临时存在的，它们是根据需要来创建的，例如
   1. 针对功能开发的分支
   2. 针对版本发布的分支
2. 其他分支开发完成后，会合并在develop分支中，自己会被删除掉。

3.1、功能分支feature

1. 是功能分支，开发某个功能点而创建。
2. 完成功能点的开发后，feature分支的最新内容会被部署至 SIT(测试环境) 进行功能测试验收。
3. 功能点测试完成后再合并入 develop分支，并删除 feature分支。

3.1.1、分支命名格式1

1. feature目录下
   1. 开发人员的名字拼音–功能的名字拼音–版本号
   2. 例如：
      1. zhoufei-goutong-v1，表示 开发人员是周飞，沟通功能，版本是v1

3.1.2、分支命名格式2

1. feature-[任务号码]
2. 例如
   1. feature-10980，10980对应任务管理平台中的任务号码

3.2、预发布分支release

1. 发布正式版本之前(即合并到master分支之前)，基于develop分支切出来的
2. 作为预发布版本以此进行测试的分支。
3. 一个release分支对应一个版本发布计划，包含一个或多个的用户故事、不定量的功能点、漏洞修复等。
4. 完成发布计划的所有开发后，将release分支的内容 会部署到 UAT(仿真环境) 进行测试验收。
5. 最后确认发布后，需要将release分支合并至master分支和develop分支，并删除该release分支，然后基于最新的master分支创建一个新的版本标记，基于tag进行生产环境部署。

3.2.1、分支命名格式

1. release目录下
   1. release-[版本号]
   2. 例如release-0.1.0。

3.3、修补Bug分支bugfix

1. 开发过程中，发现了develop代码的漏洞，对于发现的漏洞进行修补的分支
2. 基于develop分支切分出来，与feature的开发过程比较类似。
3. 完成漏洞修补的开发后，bugfix分支的最新内容会被部署至 SIT(测试环境)，进行功能测试验收。最后将其合并入develop分支，并删除bugfix分支。

3.3.1、分支命名格式1

1. bugfix目录下
   1. 开发人员的名字拼音–功能的名字拼音
   2. 例如：
      1. zhoufei-goutong，表示 开发人员是周飞，修补沟通功能

3.3.2、分支命名格式2

1. bugfix目录下
   1. bugfix-[任务号码]
   2. 例如bugfix-10980，10980对应任务管理系统中的bug任务号码。

3.4、热修复分支hotfix

1. 软件正式发布以后，难免会出现Bug，这时就需要创建一个hotfix分支 ，进行Bug热修复。
2. 与bugfix不同的地方在于，hotfix是基于master分支进行切分的，完成会合并入master分支，再合并到develop分支。
3. 漏洞修复后需要为hotfix分支制作一个新的修订号版本标记。最后，根据实际情况可选的合并入master分支，再合并到develop分支，并删除 hotfix分支。

3.4.1、分支命名格式1

1. hotfix目录下
   1. hotfix-[新版本号码]
   2. 例如hotfix-0.1.1。