4.3 分支管理(Branch Management)

　　现在，你已经创建，合并以及删除了一些分支，让我们来看一些分支管理工具它将会非常方便当你开始随时使用分支时。

　　Git branch命令并不只是创建和删除分支。如果你在运行它时没有附带参数，你会得到一个简单的你当前的分支列表：

　　$ git branch

　　iss53

　　* master

　　Testing

　　注意位于master分支前缀的*符号：它用来指示你当前已经检出的那个分支。这意味者如果你在此时提交，master分支将会随着你的新工作而向前移动。为了看一下每个分支上的最后的那个提交，你可以运行git branch –v：

　　$ git branch -v

　　iss53 93b412c fix javascript issue

　　* master 7a98805 Merge branch 'iss53'

　　testing 782fd34 add scott to the author list in the readmes

　　另外一个有用的选项用来指出你的分支处于什么状态，它可以根据你已经或者还没有合并到你现在所处的分支来过滤这个分支列表。--merged 以及--nomerged选项从1.5.6版本以后可用，可实现这个目的。为了看一下那些分支已经合并到你现在所处的分支，你可以运行git branch --merged :

　　$ git branch --merged

　　iss53

　　* master

　　因为你在之前已经合并了iss53分支，你可以在这个列表中看到它。那些在这个列表中的前面没有*的分支通常可以用git branch –d来删除它，你已经合并了它们的工作到另外的分支中了，因此，你不会丢失任何东西。

　　为了看一下所有的那些你还没有合并进来的工作分支，你可以运行git branch --no-merged ：

　　$ git branch --no-merged

　　Testing

　　这显示了你另外的一个分支。因为它包含了你还没有合并进来的工作，用git branch -d试图删除它将会失败：

　　$ git branch -d testing

　　error: The branch 'testing' is not an ancestor of your current HEAD.

　　If you are sure you want to delete it, run 'git branch -D testing'.

　　如果你确实想删除这个分支并放弃这些工作，你可以用-D强制删除它，就像帮助信息指出的那样。

 　　

　　4.4 分支工作流程(Branching Workflows)

　　现在，你已经掌握了基本的分支及合并的知识，使用它你能做或者应该做些什么呢？在本节中，我们将讲解一些常用的工作流程，因为Git这个轻型的分支使得这些流程可行，因此，你可以决定你是否想把它集成到你自己的开发周期中。

　　4.4.1 长期分支(Long-Runing Branches)

　　因为Git使用一个简单的三方合并，合并一个分支到另外一个成倍时间长度的分支通常很容易做到。这意味者你可以有几个分支总是开放的，你可以在你开发周期的不同阶段分别使用它们，你可以定期合并它们中的一些到另外的分支中。

　　很多Git的开发者们使用的工作流程都会拥抱这种方式，例如只有哪些整体稳定的代码在它们的master分支中—或许只有那些已经或即将发布的版本。他们有另外一个平行的分支命名为develop或者next，他们在此分支上工作或者测试稳定性—它们不总是很稳定，但无论何时一旦它们进入稳定状态，它们就可以被合并到master分支中。当需要时，这个分支被用来分离主题式分支(短期分支，例如你之前创建的iss53分支)，以确保它们通过了所有的测试而不会引入bugs。

实际上，我们正在讨论指针顺着你正在制造的提交向前移动。稳定的分支是你提交历史的父亲位于你提交历史线的下面，而那些新功能的分支则是历史上面那些部分的父亲。

　　这通常可以很容易的把它们考虑称为一个工作树，当它们被完全测试后，那些提交集会升级成为一个更稳定的工作区。（如图3-19）

　　你也可以这么做来实现多层稳定性。一些更大的项目也会有一个proposed或者pu(proposed updates)分支，它已经集成了那些可能还没有准备好进入到next或者master分支中的分支。这种思路的初衷是你的分支会在不同的稳定级别上；当它们达到一个更稳定的级别时，它们被合并到它上面的那个分支中。重复一遍，保持多个长期运作的分支不是必需的，但通常很有用，尤其是当你在处理那些非常大或者复杂的项目时。

　　

　　4.4.2 主题分支(Topic Branches)

　　然而，主题分支(Topic branches)对任何规模的项目都是有用的。一个主题分支是一个短期的分支，你用它来完成一个特定的功能或者相关的工作。这可能是你以前使用其它VCS时从未做过的事，因为在这些VCS 中创建和合并分支太过于昂贵了。但在Git中，创建，工作，合并以及删除分支一天几次都是常见的。

　　你在最后一节中从你创建的iss53以及hotfix分支中看到了这一点。你在上面做了一些提交，然后在把它们合并到你的主分支之后直接删除它们。这个技术允许你快速而全面地切换上下文环境――因为你的工作被分割进不同的分区中，在这个分区中，所有的更改都是与该主题有关的。这样在代码检查及其它阶段就很容易看出发生了什么。你可以保存这些更改几分钟，几天，或者几个月，然后当它们准备好时把它们合并进来而不用关心它们被创建的顺序以及工作的顺序。

　　考虑一下这个例子：你在master上做了一些工作，分离了一个分支来处理一个问题(iss91)，在上面工作了一些，又分离出第二个分支试图用另一种方法去解决同样的问题(iss91v2)，返回到你的master分支上又工作了一会，然后又分离一个分支来做一些你还不确定是否是好主意的工作(dumbidea分支)。你的提交历史将看起来如图3-20所示：

　　现在，让我们假设你喜欢第二种方案来解决你的问题(iss91v2)，而且你展示了dumbidea分支给你的同事，这是一个天才的想法。你可以扔掉你最初的iss91分支(丢掉C5和C6提交)并合并到其它两个分支中。那么，你的历史看起来如下：

　　特别需要记得的是：当你做所有这些事情时，这些分支完全是本地的。当你分支或合并时，所有做的事情都只发生在你的Git库中—没有任何与server间的通信发生。