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上就可以验证了。