现在已经学会新建、删除和合并分支等操作，那么接下来会介绍一些利用分支，进行开发的工作流程。
正是由于Git分支管理的便捷，才衍生出这些典型的工作模式，你可以根据项目实际情况选择一种用用看。
1、长期分支因为Git使用简单的三方合并，所以就算在一段较长的时间内，反复把一个分支合并入另一个分支，也不是什么难事。也就是说，在整个项目开发周期的不同阶段，你可以同时拥有多个开放的分支；你可以定期地把某些主题分支合并入其他分支中。
许多使用Git的开发者都喜欢使用这种方式来工作，比如只在master分支上保留完全稳定的代码，有可能仅仅是已经发布或即将发布的代码。
他们还有一些名为develop或者next的平行分支，被用来做后续开发或者测试稳定性，这些分支不必保持绝对稳定，但是一旦达到稳定状态，它们就可以被合并入分支了。
这样，在确保这些已完成的主题分支（短期分支，比如之前的dev分支）能够通过所有测试，并且不会引入更多bug之后，就可以合并入主干分支中，等待下一次的发布。
事实上我们刚才讨论的，是随着你的提交而不断右移的指针。稳定分支的指针总是在提交历史中落后一大截，而前沿分支的指针往往比较靠前。
如下图：
通常把他们想象成流水线（worksilos）可能更好理解一点，那些经过测试考验的提交，会被遴选到更加稳定的流水线上去。
你可以用这种方法维护不同层次的稳定性。
一些大型项目还有一个proposed（建议）或pu:proposedupdates（建议更新）分支，它可能因包含一些不成熟的内容而不能进入或者分支。
这么做的目的是使你的分支，具有不同级别的稳定性。当它们具有一定程度的稳定性后，再把它们合并入具有更高级别稳定性的分支中。
再次强调一下，使用多个长期分支的方法并非必要，但是这么做通常很有帮助，尤其是当你在一个非常庞大或者复杂的项目中工作时。
2、主题分支（短期分支）主题分支对任何规模的项目都适用。主题分支是一种短期分支，它被用来实现单一特性或其相关工作。
也许你从来没有在其他的版本控制系统（VCS）上这么做过，因为在版本控制系统中，创建和合并分支通常很费劲。然而，在Git中一天之内多次创建、使用、合并、删除分支都很常见。
你在之前的文章中，创建的和hotfix主题分支中看到过这种用法。在主题分支（和分支）中提交了一些更新，并且在它们合并入主干分支之后，你又删除了它们。
这项技术能使你快速并且完整地进行上下文切换（context-switch）。因为你的工作被分散到不同的流水线中，在不同的流水线中，每个分支都仅与其目标特性相关。因此，在做代码审查之类工作的时候，就能更加容易地看出你做了哪些改动。
你可以把做出的改动，在主题分支中保留几分钟、几天甚至几个月，等它们成熟之后再合并，而不用在乎它们建立的顺序或工作进度。
考虑这样一个例子，你在分支上工作到C1提交，这时为了解决一个问题而新建iss91分支，在分支上工作到C4提交，然而对于那个问题你又有了新的想法，于是你再新建一个iss91v2分支，试图用另一种方法解决那个问题，接着你回到分支工作了一会儿，你又冒出了一个不太确定的想法，你便在C10提交的时候，新建一个dumbidea分支，并在上面做些实验。
你的提交历史如下图：
现在，我们假设两件事情：
你决定使用第二个方案来解决那个问题，即使用在分支中方案。
另外，你将分支拿给你的同事看过之后，结果发现这是个惊人之举。
这时你可以抛弃分支（即丢弃C5和C6提交），然后把另外两个分支合并入主干分支。
最终你的提交历史，如下图：
3、总结当你做了这么多操作之后，但其实这些分支全部都存于本地。当你新建和合并分支的时候，所有这一切都只发生在你本地的Git版本库中，没有与服务器发生交互。
在以后学习了分布式Git后，会有更多有关分支工作流的细节。
因此，等学习完后，你可以再来决定下个项目中，要使用什么样的分支策略（branchingscheme）。
转载请注明：http://www.0431gb208.com/sjszlff/1354.html
