Git分支 - 利用分支进行开发的工做流程

利用分支进行开发的工做流程

长期分支

因为 Git 使用简单的三方合并，因此就算在较长一段时间内，反复屡次把某个分支合并到另外一分支，也不是什么难事。也就是说，你能够同时拥有多个开放的分支，每一个分支用于完成特定的任务，随着开发的推动，你能够随时把某个特性分支的成果并到其余分支中。

许多使用 Git 的开发者都喜欢用这种方式来开展工做，好比仅在 master 分支中保留彻底稳定的代码，即已经发布或即将发布的代码。与此同时，他们还有一个名为 develop 或 next 的平行分支，专门用于后续的开发，或仅用于稳定性测试 — 固然并非说必定要绝对稳定，不过一旦进入某种稳定状态，即可以把它合并到 master 里。这样，在确保这些已完成的特性分支（短时间分支，好比以前的 iss53 分支）可以经过全部测试，而且不会引入更多错误以后，就能够并到主干分支中，等待下一次的发布。

本质上咱们刚才谈论的，是随着提交对象不断右移的指针。稳定分支的指针老是在提交历史中落后一大截，而前沿分支老是比较靠前（见图 3-18）。

图 3-18. 稳定分支老是比较老旧。

或者把它们想象成工做流水线，或许更好理解一些，通过测试的提交对象集合被遴选到更稳定的流水线（见图 3-19）。

图 3-19. 想象成流水线可能会容易点。

你能够用这招维护不一样层次的稳定性。某些大项目还会有个 proposed（建议）或 pu（proposed updates，建议更新）分支，它包含着那些可能尚未成熟到进入 next 或 master 的内容。这么作的目的是拥有不一样层次的稳定性：当这些分支进入到更稳定的水平时，再把它们合并到更高层分支中去。再次说明下，使用多个长期分支的作法并不是必需，不过通常来讲，对于特大型项目或特复杂的项目，这么作确实更容易管理。

特性分支

在任何规模的项目中均可以使用特性（Topic）分支。一个特性分支是指一个短时间的，用来实现单一特性或与其相关工做的分支。可能你在之前的版本控制系统里从未作过相似这样的事情，由于一般建立与合并分支消耗太大。然而在 Git 中，一天以内创建、使用、合并再删除多个分支是常见的事。

咱们在上节的例子里已经见过这种用法了。咱们建立了 iss53 和 hotfix 这两个特性分支，在提交了若干更新后，把它们合并到主干分支，而后删除。该技术容许你迅速且彻底的进行语境切换 — 由于你的工做分散在不一样的流水线里，每一个分支里的改变都和它的目标特性相关，浏览代码之类的事情于是变得更简单了。你能够把做出的改变保持在特性分支中几分钟，几天甚至几个月，等它们成熟之后再合并，而不用在意它们创建的顺序或者进度。

如今咱们来看一个实际的例子。请看图 3-20，由下往上，起先咱们在 master 工做到 C1，而后开始一个新分支 iss91 尝试修复 91 号缺陷，提交到 C6 的时候，又冒出一个解决该问题的新办法，因而从以前 C4 的地方又分出一个分支 iss91v2，干到 C8 的时候，又回到主干 master 中提交了 C9 和 C10，再回到iss91v2 继续工做，提交 C11，接着，又冒出个不太肯定的想法，从 master 的最新提交 C10 处开了个新的分支 dumbidea 作些试验。

图 3-20. 拥有多个特性分支的提交历史。

如今，假定两件事情：咱们最终决定使用第二个解决方案，即 iss91v2 中的办法；另外，咱们把dumbidea 分支拿给同事们看了之后，发现它居然是个天才之做。因此接下来，咱们准备抛弃原来的iss91 分支（实际上会丢弃 C5 和 C6），直接在主干中并入另外两个分支。最终的提交历史将变成图 3-21 这样：

图 3-21. 合并了 dumbidea 和 iss91v2 后的分支历史。

请务必牢记这些分支所有都是本地分支，这一点很重要。当你在使用分支及合并的时候，一切都是在你本身的 Git 仓库中进行的 — 彻底不涉及与服务器的交互。