git分支模型介绍先看一下分支模型总览图，咱们不要害怕看不明白，我一一细说，认真看完，还不懂就找我。使用分支把你的工作从开发主线上分离开来，
以免影响开发主线，导致发布版本紊乱。再直白点讲：分支就是从主线上分离出来进行另外的操作，而又不影响主线，主线可以继续干它的事，嗯
，有点像线程，最后分支做完事后合并到主线上而分支的任务完成就可以删掉了。主线继续做它的事，分支用来解决临时需求，二者互不相干。咱们
把Git分支模型称为“必杀技特性”，为何这么称呼它？超轻量，创建新分支这一操作瞬间完成，并且在不同分支之间的切换操作也是一样便捷。
Git鼓励在工作流程中频繁地使用分支与合并，哪怕一天之内进行许多次。理解和精通这一特性，你便会意识到Git是如此的强大而又
独特，并且从此真正改变你的开发方式。master和develop并行：master分支默认就存在我们称它为原始分支是一个主分支，我
们一般用来发布新版本。develop是一个开发主分支，在版本确定代码稳定情况下，我们可以推送至master分支上打上标签形成一个发
布版的变更。master分支：看上图，可以看到master分支上有0.1，0.2，...，1.0的tag(标签)。master分支
上始终是最稳定的代码，你可以理解为经过测试后发布到现场运行的代码，比如我们发布了程序0.1版本，这个时候master上的代码即是发
布时的代码，下次需要发布0.2版本了，所有新增功能，变更功能等代码都在其develop分支上进行，也就时说没正式发布0.2版本的时
候都不会推到master分支上。直至测试无误确认发布0.2版本，此时代码回归到master分支上，同时打上标签0.2。所以，每次变
更合并到了master，这就是新产品的定义。在这一点，我们倾向于严格执行这一点。develop分支：这是开发主分支，当develo
p分支的源码到达了一个稳定状态待发布，所有的代码变更才可以合并到master分支，然后标记一个版本号。也就是说当代码没有达到一个稳
定要发布的时候，其某一项功能完成都只能推送至develop分支。除了master和develop分支，其它分支我们都称其为辅助性分
支。这些分支与关键分支（master和develop）一起，用来支持团队成员们并行开发，使得易于追踪功能，协助生产发布环境准备，以
及快速修复实时问题。与关键分支不同，这些分支总是有一个有限的生命期，因为他们最终会被移除。我们用到的辅助性分支类型包括也就是上图中
的三个分支：●featurebranches功能分支●releasebranches发布分支●hotfixesbran
ches热修复分支功能分支featurebranches：即将发布或未来发布而开发的新功能分支，当然了新功能开始研发，包含该功能
的发布版本版本在这个时候还是无法确定发布时间的。功能分支的实质是只要这个功能还没结束开发它就一直会存在，一旦确定该功能通过测试并确
实需要此时可以添加到develop分支上，并删除该分支。通俗点讲：也就是说可以从develop分支上拉出若干功能分支供若干人进行并
行开发，开发完毕合并至develop分支，对应的功能分支结束。发布分支releasebranches：这个发布分支从develo
p分支分离而来，但这个分支一旦结束，一定是要合并到develop和master分支上。因为发布分支是为新产品的发布做准备的，它允许
我们在最后时刻做一些细小的修改，允许小bug的修改和准备发布元数据(版本号、开发时间等等)。当发布分支完成所有工作以后，对于下一次
的发布，develop分支接受功能会更加明确。你如果从develop分支创建release发布分支的关键原因是develop分支
能达到发布的理想状态，至少这次的发布分支必须要及时的合并到develop分支上。对于所有为了未来准备的功能分支必须等到发布分支创建
以后再合并。在发布分支创建的时候要为即将发行的版本分配一个版本号，此时develop分支反应的变化都是为了下一个发行版本服务的。但
是在发布分支创建之前，下一个发行版到底叫0.3还是0.4都是不明确的。因为这个决定是在发布分支创建时根据项目在版本号上的规则制定的
。发布分支可能会存在一段时间，直到该发布版到达预定目标，在此期间，bug的修复可能被提交到该分支上而不是develop分支上。我们
严格禁止此时增加大的新功能分支，他们必须合并到develop分支上，然后等待下一次大的发布分支。如果我们发布分支准备好了以后，首先
就是要合并到master分支上，因为每一次提交到master上的都是一个新定义的发布版。然后，在master上必须打上一个标签，以
便以后更加方便的引用这个历史版本。最后，在发布分支上的修改必须合并到develop分支上，以便未来发行版也包含这个bug的修复。这
个时候我们可以将这个发布分支删除掉了，因为我们不再需要它了。热修复分支hotfixesbranches：基于master分支，
但必须合并回develop和master分支。热修复分支和发布分支有点像，因为它们都是为新的发布环境做准备的。他们都是来自与现场或
生成环境处于异常状态下或基于客户压力的产物。当生产环境验证缺陷并且必须马上修复的时候，此时热修复分支基于master分支对应与线上
版本的tag创建。其本质是其它团队成员可以在开发分支上的工作继续不受影响，而另一个准备生产环境的也可以快速修复bug。完成热修复分
支之后，要把热修复合并到master和develop分支上去，这样可以保证修复的这个Bug也可以包含到下一个发行版本中，和发布分支
很相似。但是有一个例外，如果此时有一个发布分支，那么应该把热修复分支合并到这个发布分支，而不是合并到develop分支上。但是如果此时开发分支继续这个热修复分支支撑，等不到发布分支的完成，那么此时可以把热修复合并到develop分支上，但原则上尽量避免这种情况。 |
|
