1. 长期分支
因为 Git 使用简单的三方合并
所以就算在一段较长的时间内，也可反复把一个分支合并入另一个分支
也就是说，在整个项目开发周期的不同阶段，可以同时拥有多个开放的分支
可以定期地把某些特性分支合并入其他分支中
许多使用 Git 的开发者都喜欢使用这种方式来工作
比如只在 master 分支上 保留完全稳定的代码
还有一些名为 develop 或者 next 的平行分支，被用来做 后续开发 或者 测试稳定性
但是一旦达到稳定状态，它们就可以被合并入 master 分支了
事实上，随着的提交而不断右移的指针
稳定分支的指针总是在提交历史中落后，而前沿分支的指针往往比较靠前
通常想象成流水线（work silos）更好理解
那些经过测试考验的提交会被遴选到更加稳定的流水线上去
可以用这种方法维护不同层次的稳定性
一些大型项目还有一个 proposed（建议） 或 pu: proposed updates（建议更新）分支
它可能因包含一些不成熟的内容而不能进入 next 或者 master 分支
这么做的目的是使你的分支具有不同级别的稳定性
当它们具有一定程度的稳定性后，再把它们合并入具有更高级别稳定性的分支中
建议在一个非常庞大或者复杂的项目中工作使用
2. 特性分支
而特性分支对任何规模的项目都适用
特性分支是一种 短期分支，它被用来 实现单一特性或其相关工作
其实已经在 Git学习笔记（12） 分支使用 中的 iss53 和 hotfix 其实就是特性分支
iss53 和 hotfix 特性分支中提交了一些更新
并且在它们合并入主干分支之后，又删除了它们
这项技术能快速并且完整地进行上下文切换（context-switch）
考虑这样一个例子
在 master 分支上工作到 C1
这时为了解决一个问题而新建 iss91 分支，在 iss91 分支上工作到 C4
然而对于那个问题又有新想法，再新建 iss91v2 分支试图用另一种方法解决那个问题
接着又回到 master 分支工作了一会儿
又冒出了一个不太确定的想法，便在 C10 时新建 dumbidea 分支，并在做些实验
则提交历史看起来像下面这个样子：
现在，假设两件事情：
决定使用第二个方案来解决那个问题，即使用在 iss91v2 分支中方案
另外，将 dumbidea 分支拿给同事看过之后，结果发现这是个惊人之举
这时你可以抛弃 iss91 分支（即丢弃 C5 和 C6 提交）
然后把dumbidea 分支和 iss91v2 分支并入主干分支
最终提交历史看起来像下面这个样子：
请牢记，当做这么多操作的时候，这些分支全部都存于本地
当新建和合并分支的时候
所有这一切都只发生在本地的 Git 版本库中，没有与服务器发生交互
参考： git
以上内容，均根据git官网介绍删减、添加和修改组成
相关推荐：
Git笔记（13） 分支管理
Git笔记（12） 分支使用
Git笔记（11） 分支简介
Git笔记（10） 别名
Git笔记（9） 打标签
谢谢
