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

参考：

https://mr-dai.github.io/git-branching-model/

https://juejin.cn/post/6844903609461637134

https://juejin.cn/post/6967981728619544606