Git 代码分支管理-Toy模板网

这篇具有很好参考价值的文章主要介绍了Git 代码分支管理。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

作者：京东科技周新智

一、引言

近日，IoT 研发团队加入了不少新同学，对 git 分支的命名和管理方式有些许的模糊，分支的命名规范以及管理方式对项目的版本发布至关重要，为了解决实际开发过程中版本发布时代码管理混乱、冲突等比较头疼的问题，我们将在文中阐述如何更好的管理代码分支。

二、总览

从上图可以看到主要包含下面几个分支：

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

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

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

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

• hotfix：线上 bug 修复分支。

三、主分支

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

1、Master Branch

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

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 分支上，并择机进行线上发布。

3、Dev Branch

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

四、辅助分支

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 分支。

2、Hotfix 分支

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