git分支管理规范

个人总结

熟悉概念的直接看总览图即可：

master——相当于生产库

develop——开发库，

release——用于开发到生产之前的调试工作

feature——多人协同开发develop，加快develop库的开发速度

hotfix——bug紧急修复

总览图

它主要体现了Git对我们源代码版本的管理。

一般情况：

● master和develop并行。

● master上始终是最稳定的代码，develop是正在开发的代码。

● feature则是某个开发为了自己的功能拉的分支。

不一般情况：

● develop正在开发，如果你上线突然被拒绝了，这时候就要从master上开一个热分支，或者release分支也行，改好之后在分别合并到其他分支。但，本人感觉release通常意味着终止。别在从release上拉分支了。

简单和重复的特性带来的结果是：分支与合并不再是什么可以害怕的东西。分支/合并被认为对于版本管理工具比其他功能更重要。

主分支

在核心部分，研发模型很大程度上靠其他现有模型支撑的。中心库有2个可一直延续的分支：

● master分支

● develop分支

每个Git用户都要熟悉原始的master分支。与master分支并行的另一个分支，我们称之为develop分支。

我们把原始库/master库认作为主分支，HEAD的源代码存在于此版本中，并且随时都是一个预备生产状态。

当develop分支的源码到达了一个稳定状态待发布，变更都合并到了master，这就是新产品的定义。

辅助性分支

我们的开发模型使用了各种辅助性分支，这些分支与关键分支（master和develop）一起，用来支持团队成员们并行开发，使得易于追踪功能，协助生产发布环境准备，以及快速修复实时在线问题。与关键分支不同，这些分支总是有一个有限的生命期，因为他们最终会被移除。

我们用到的分支类型包括：

● 功能分支

● 发布分支

● 热修复分支

每一种分支有一个特定目的，并且受限于严格到规则，比如：可以用哪些分支作为源分支，哪些分支能作为合并目标。我们马上将进行演练。

从技术角度来看，这些分支绝不是特殊分支。分支的类型基于我们使用的方法来进行分类。它们理所当然是普通的Git分支。

功能分支

可能是develop分支的分支版本，最终必须合并到develop分支中。

分支命名规则：除了master、develop、release-*、orhotfix-*之外，其他命名均可。

创建一个release分支

Release分支是从develop分支创建的。例如，当前产品的发行版本号为1.1.5，同事我们有一个大的版本即将发行。develop 分支已经为下次发行做好了准备，我们得决定下一个版本是1.2（而不是1.1.6或者2.0）。所以我们将Release分支分离出来，给一个能够反映新版本号的分支名。

热修复分支

热修复分支与发布分支很相似，他们都为新的生成环境发布做准备，尽管这是未经计划的。他们来自生产环境的处于异常状态压力。当生成环境验证缺陷必须马上修复是，热修复分支可以基于master分支上对应与线上版本的tag创建。

其本质是团队成员（在develop分支上）的工作可以继续，而另一个人准备生产环境的快速修复。

创建修补bug分支

hotfix branch(修补bug分支)是从Master分支上面分出来的。例如，1.2版本是当前生产环境的版本并且有bug。但是开发分支（develop）变化还不稳定。我们需要分出来一个修补bug分支（hotfix branch）来解决这种情况。

【1】https://blog.csdn.net/hj7jay/article/details/84527062    Git分支模型(master/hotfix/develop/feature/release)