git分支管理策略
1 总览
git 的分支整体预览图如下:
从上图可以看到主要包含下面几个分支:
master:git默认主分支(这里不作操作)。
stable:稳定分支,替代master,主要用来版本发布。
develop:日常开发分支,该分支正常保存了开发的最新代码。
feature:具体的功能开发分支,只与 develop 分支交互。
release:release 分支可以认为是 stable分支的未测试版。比如说某一期的功能全部开发完成,那么就将 develop 分支合并到 release分支,测试没有问题并且到了发布日期就合并到 stable分支,进行发布。
bugfix:线上 bug 修复分支。
1.1 主分支
因为master分支我们不作操作,所以针对stable和develop这两个主分支来讲解。
stable分支:用来发布,管理着多个稳定的版本。
develop分支:就是我们日常开发的分支。
使用这两个分支就具有了最简单的开发模式:develop 分支用来开发功能,开发完成并且测试没有问题后,则将 develop 分支的代码合并到 stable分支并发布。
在开发中如果我们只用主分支来进行管理,那么就会造成develop发布完成之后才能进行下一迭代的开发,开发会比较缓慢。如果线上代码发现bug之后,很难进行bug修复。
针对以上问题,建立辅助分支就能完美的解决。
1.2 辅助分支
辅助分支主要有一下几个:
1、feature分支。
2、release分支。
3、bugfix分支。
通过这些分支,我们可以做到:团队成员之间并行开发,增加新功能更加容易,可以同时进行开发和版本发布、线上bug修复等。
1.2.1 feature分支
feature 分支用来开发具体的功能,一般基于develop分支,最后完成功能后再合并到develop分支。
比如,目前我们针对develop分支来做功能开发,在开发的过程中会有紧急需求需要开发,且在本次版本发布时间之前要能测试完成。我们可以基于之前稳定版本另开一个feature分支来做紧急需求的开发,发布并进行测试,完成之后再合并到develop分支上。
![]()
1.2.2 release分支
release分支作为预发布分支,release 分支从 develop 分支 fork 出来,最终会合并到 develop 分支和 stable 分支,合并到 stable分支上就是可以发布的代码了。
为什么我从develop分支fork出来,还要合并到develop分支中呢?因为我们在release分支上难免会有bug产生,修复bug也是在release分支上,所以必须要合并到develop分支。
![]()
1.2.3 bugfix分支
bugfix 分支用来修复线上bug。当线上代码出现 bug 时,我们基于 stable 分支开一个bugfix分支,修复 bug之后再将 bugfix分支合并到stable分支并进行发布,同时develop 分支作为最新最全的代码分支,bugfix分支也需要合并到 develop 分支上去。
1.3 Tag标签
在我们用git做版本管理的时候,每次提交代码都会生成唯一标识本次提交的编码,对于这个编码我们直观的看是没有任何意义的。为了很好标识每个版本的变化,我们会在每个版本发布的同时打上一个tag,通常和版本名称相同。
比如我们开发了V1.0、V1.1,不同的版本对应不同的代码,当我们在V1.1上面发现bug时,但并不确定V1.0是否存在bug,那我们怎么确认V1.0存在bug呢?怎么知道哪些提交的代码属于V1.0?此时tag就很有用了。我们在发布V1.0和V1.1这两个版本时,分别为这两个版本加上tag1.0和tag1.1,当我们需要验证V1.0是否存在bug时,切换到tag1.0上就可以验证了。