GIT分支规范管理_gitlab分支管理

• main: 主分支，也称为线上分支，主要用来版本发布。

• dev：日常开发分支，该分支正常保存了开发的最新代码。

• release：release 分支可以认为是 master 分支的测试版。比如说某个新增功能开发完成、线上问题紧急修复完成，那么就将 feature/hotfix 分支合并到 release 分支，到了发布日期就合并到

• master 分支，进行版本发布。

• feature：具体的功能开发分支。

• hotfix：线上 bug 修复分支。

一、主分支

主分支包括 Main Branch、Release Branch、Dev Branch 三个分支：

1、Main Branch  代表最新发布版本

用来进行版本发布，也就是当前线上运行的代码分支

一般情况下， main分支代表最新发布版本。当需要最新发布版本的内容时，直接取分支末端即可。

不论其他哪类分支，都建议一般从 main 分支创建，并且经常从 main 分支合并，以便跟上“潮流”，减少将来集成时的各种问题，比如代码合并冲突。

每当软件正式发布前，系统会确保它基于 main 最新。

每当软件正式发布后，系统会把相应内容合并回 main，以便让 main 分支始终代表最新发布版本。

一般来说，使用者不要直接“写”东西到main分支。

2、Release Branch

Release Branch 在我看来就是 Pre-Master。Release Branch 从 Master Branch 检出，最终会合并到 Master Branch，合并后 Master Branch 上就是可以发布的代码了。

所有新增功能的开发分支都是从 Dev Branch 检出作为本地分支，以 feature - 功能名 - 姓名首字母简拼，当功能开发完毕的时候，将 feature Branch 合并到 Dev Branch，在测试或预生产环境进行部署，测试通过后，再将 feature Branch 合并到 Release Branch。

如果出现线上问题需要紧急修复，则从 Release Branch 检出作为本地分支，以 hotfix - 功能名 - 姓名首字母简拼， 当问题修复完毕的时候，将 hotfix Branch 合并到 Dev Branch，在测试环境进行部署，测试通过后，再将 hotfix Branch 合并到 Release Branch，在预发环境再次验证。

待所有的测试和准备工作做完之后，我们就可以将 release 分支合并到 master 分支上，并择机进行线上发布。

 release 分支上的集成

release 分支用于集成和发布。基于 main 分支最新版本创建一条 release 分支，然后把想要集成的各条feature分支合并到这条release分支，进行部署和测试工作。

如果有新的 feature 分支要加入本次集成，那就把它也合并进这条 release 分支，然后再次部署并测试。

如果测试发现问题，就到 feature 分支上修复，然后把它再次合并到 release 分支，把修复带到 release 分支。

当然如果一个 feature 的问题太多太大，那干脆就放弃它。也就是说，新建一条 release 分支，把其他 feature 分支都合并过去，唯独不再合并这条 feature 分支。

就像 main 分支一样，release 分支也是由系统自动管理的。使用者不要直接在上面改代码，代码修改请总是在 feature 分支完成。

release 分支上的发布上线

当 release 分支上的质量足够好，本次想上线的功能也都具备之后，就要考虑发布上线的问题啦。如前面讲的，发布上线前，会确保它基于基础分支（常见的如 main）最新。而发布后会把 release 分支合并回 main，让 main代表最新发布版本。

以上几节介绍的内容，见下图：

3、Dev Branch

dev 就是我们的日常开发分支。

二、辅助分支

分支模式提供2中开发模式：开发人员只需要关心集成和发布哪些 feature 分支，而对 release 分支创建和管理、分支合并等一系列工作，开发仓库管理员 完成。

命名方式：

feature各个分支（缺陷的修复分支）： fea-1 fea-N 1~N 待办 讨论组创建的编号

release 各个分支 (下一次上线分支)： 集成的各条feature分支合并到这条release分支

本节内容详细介绍分支模式下，各(类)分支的使用方式。

1、Feature 分支

feature 分支用来开发具体的功能，一般 fork 自 Dev 分支，以 feature - 功能名 - 姓名首字母简拼 进行命名，最终合并到 Dev 、Release 分支。比如我们要在下一个版本增加功能 1、功能 2、功能 3。那么我们就可以起三个 feature 分支：feature-1-zxz，feature-2-qxh，feature-3-sq。（feature 分支命名最好能够自解释，1、2、3 这并不是一种好的命名）随着我们开发，功能 1 和功能 2 都被完成了，而功能 3 因为某些原因完成不了，那么最终 feature-1-zxz 和 feature-2-qxh 分支将被合并到 Dev 分支，而 feature-3-sq 分支将延期继续进行本地开发工作，功能 1 和功能 2 测试完没有问题后，将 feature1 和 feature2 分支将被合并到 Release 分支，最终将 Release 分支合并到 Master 分支。

在各 feature 分支上开发

一条 feature 分支（又称变更分支、开发分支），通常用来承载一个缺陷的修复，或者一个需求（如果不是很大的话）的开发，或者任务分解后一个任务的开发。

一般来讲，基于 main分支最新版本创建 feature 分支。然后在 feature 分支上开发、测试，直到这个 feature 功能完成，质量 OK，准备好去集成和发布。

2、Hotfix 分支

顾名思义，hotfix 分支用来修复线上 bug。当线上代码出现 bug 时，我们基于 Release 分支开一个 hotfix 分支，以 hotfix - 功能名 - 姓名首字母简拼（例如：hotfix-model-base-zxz），修复 bug 之后再将 hotfix 分支合并到 Release 分支，同时 Dev 分支作为最新最全的代码分支，hotfix 分支也需要合并到 Dev 分支上去，同时在不同分支对应的不同环境进行 bug 回归验证，最终将 Release 分支合并到 Master 分支，进行线上发布即可。

三、注意事项

1、 Feature 分支、Hotfix 分支合并到 Dev 分支，测试通过后，需再合并到 Release 分支，这时候就要求代码合并时需清楚的知道此代码是否已经经过验证。

2、 Dev、Release、Master 分支的同步

Release 分支合并到 Master 分支后，若 Dev 分支无正在测试的功能，建议定时将 Dev、Release、Master 分支进行代码同步。

通过以上分支管理，我们就可以轻松做到：团队成员之间功能并行开发、功能选择性发布、版本发布、线上问题紧急功能开发、紧急问题修复等。

四、多个环境/流程时

假定要想集成发布上线，要经过日常测试环境上的测试这个流程，还要经过预发环境上的测试这个流程，那么两个流程用一条 release 分支就有些不合适。因为两个流程可能同时在测不同的 feature 分支集合。

分支模式用这个办法避免这个问题：每一个测试环境，也就是每个流程，关联它自己的 release 分支。日常测试、预发测试这两个环境（也就是两个流程），分别关联两条 release 分支。这样就不会相互影响。推而广之，为正式运行环境，也对应一条release分支。也就是说，每个环境都有对应的 release 分支。

当把集成成果从一个环境传递到下一个环境时，就是把一个环境下已合并到一起的 feature 分支，再往另一个环境对应的 release 分支上合并一遍……这么做有点儿笨。系统实际的做法是，基于 main 分支创建另一个环境对应的 release 分支，然后把前一个环境对应的 release 分支合并到新的 release 分支上。