git 分支管理

首先，我们假设正在进行项目上工作，并且已经有一些提交。

现在，为了解决一个#53 问题，想要新建一个分支并同时切换到那个分支上，你可以运行一个带有 参数的 命令：-bgit checkout

$ git checkout -b iss53
Switched to a new branch "iss53"

它是下面两条命令的简写：

$ git branch iss53
$ git checkout iss53

继续在 #53 问题上工作，并且做了一些提交。 在此过程中，iss53分支在不断的向前推进，因为你已经检出到该分支（也就是说，你的HEAD指针指向了iss53分支）

忽然有个紧急问题等待你来解决。 有了 Git ，所要做的仅仅是切换回master分支。


在切换回master分支之前，确保工作目录和暂存区里那些还没有被提交的修改，它可能会和你即将检出的分支产生冲突从而阻止 Git 切换到该分支。 最好的方法是，在你切换分支之前，保持好一个干净的状态。 有一些方法可以绕过这个问题（即，保存进度（stashing） 和 修补提交（commit amending））。 现在，我们假设你已经把你的修改全部提交了，这时你可以切换回master分支了：

切换回master分支后，工作目录和在开始 #53 问题之前一模一样，现在可以专心修复紧急问题了。

需要注意的是：当你切换分支的时候，Git 会重置工作目录，使其看起来像回到了你在那个分支上最后一次提交的样子。 

接下来，你要修复这个紧急问题。 让我们建立一个针对该紧急问题的分支（hotfix branch），在该分支上工作直到问题解决：

你可以运行你的测试，确保你的修改是正确的，然后可以使用git merge将其合并回你的master分支来部署到线上。 

$ git checkout master
$ git merge hotfix
Updating f42c576..3a0874c
Fast-forward
 index.html | 2 ++
 1 file changed, 2 insertions(+)

在合并的时候，可以看到"快进（fast-forward）"这个词。 由于当前master分支所指向的提交是你当前提交（有关 hotfix 的提交）的直接上游，所以 Git 只是简单的将指针向前移动。 换句话说，当你试图合并两个分支时，如果顺着一个分支走下去能够到达另一个分支，那么 Git 在合并两者的时候，只会简单的将指针向前推进（指针右移），因为这种情况下的合并操作没有需要解决的分歧——这就叫做 “快进（fast-forward）”。


现在，最新的修改已经在master分支所指向的提交快照中，可以发布该修复了。

关于这个紧急问题的解决方案发布之后，需要回到被打断之前时的工作中。 然而，应该先删除hotfix分支，因为master分支已经指向了同一个位置。 你可以使用带-d选项的git branch命令来删除分支：


现在你可以切换回你正在工作的分支继续你的工作，也就是针对 #53 问题的那个分支（iss53 分支）。

你在hotfix分支上所做的工作并没有包含到iss53分支中。 如果你需要拉取hotfix所做的修改，你可以使用git merge命令将master分支合并入iss53分支，或者你也可以等到iss53分支完成其使命，再将其合并回master分支。


假设你已经修正了 #53 问题，并且打算将你的工作合并入master分支。 为此，你需要合并iss53分支到master分支，这和之前你合并hotfix分支所做的工作差不多。 你只需要检出到你想合并入的分支，然后运行git merge命令：

在这种情况下，你的开发历史从一个更早的地方开始分叉开来（diverged）。 因为，master分支所在提交并不是ISS53分支所在提交的直接祖先。 出现这种情况的时候，Git 会使用两个分支的末端所指的快照（ C4和 C5）以及这两个分支的工作祖先（C2），做一个简单的三方合并。


和之前将分支指针向前推进所不同的是，Git 将此次三方合并的结果做了一个新的快照并且自动创建一个新的提交指向它。 这个被称作一次合并提交，它的特别之处在于他有不止一个父提交。

需要指出的是，Git 会自行决定选取哪一个提交作为最优的共同祖先，并以此作为合并的基础.

既然你的修改已经合并进来了，你已经不再需要iss53分支了。 现在你可以在任务追踪系统中关闭此项任务，并删除这个分支。

有时候合并操作不会如此顺利。 如果你在两个不同的分支中，对同一个文件的同一个部分进行了不同的修改，Git 就没法干净的合并它们。 如果你对 #53 问题的修改和有关hotfix的修改都涉及到同一个文件的同一处，在合并它们的时候就会产生合并冲突：

此时 Git 做了合并，但是没有自动地创建一个新的合并提交。 Git 会暂停下来，等待你去解决合并产生的冲突。 你可以在合并冲突后的任意时刻使用git status命令来查看那些因包含合并冲突而处于未合并（unmerged）状态的文件：

任何因包含合并冲突而有待解决的文件，都会以未合并状态标识出来。 Git 会在有冲突的文件中加入标准的冲突解决标记，这样你可以打开这些包含冲突的文件然后手动解决冲突。 出现冲突的文件会包含一些特殊区段，看起来像下面这个样子：

这表示HEAD所指示的版本（也就是你的master 分支所在的位置，因为你在运行 merge 命令的时候已经检出到了这个分支）在这个区段的上半部分（======= 的上半部分），而iss53分支所指示的版本在=======的下半部分。 为了解决冲突，你必须选择使用由==============分割的两部分中的一个，或者你也可以自行合并这些内容。 例如，你可以通过把这段内容换成下面的样子来解决冲突：


上述的冲突解决方案仅保留了其中一个分支的修改，并且<<<<<<< , =======, 和>>>>>>>这些行被完全删除了。 在你解决了所有文件里的冲突之后，对每个文件使用git add命令来将其标记为冲突已解决。 一旦暂存这些原本有冲突的文件，Git 就会将它们标记为冲突已解决。

等你退出合并工具之后，Git 会询问刚才的合并是否成功。 如果你回答是，Git 会暂存那些文件以表明冲突已解决： 你可以再次运行git status来确认所有的合并冲突都已被解决：

如果你对结果感到满意，并且确定之前有冲突的的文件都已经暂存了，这时你可以输入git commit来完成合并提交。 默认情况下提交信息看起来像下面这个样子：

如果你觉得上述的信息不够充分，不能完全体现分支合并的过程，你可以修改上述信息，添加一些细节给未来检视这个合并的读者一些帮助，告诉他们你是如何解决合并冲突的，以及理由是什么。

因为 Git 使用简单的三方合并，所以就算在一段较长的时间内，反复把一个分支合并入另一个分支，也不是什么难事。 也就是说，在整个项目开发周期的不同阶段，你可以同时拥有多个开放的分支； 你可以定期地把某些特性分支合并入其他分支中。

许多使用 Git 的开发者都喜欢使用这种方式来工作，比如只在master分支上保留完全稳定的代码——有可能仅仅是已经发布或即将发布的代码。 他们还有一些名为develop或者next的平行分支，被用来做后续开发或者测试稳定性——这些分支不必保持绝对稳定，但是一旦达到稳定状态，它们就可以被合并入master分支了。 这样，在确保这些已完成的特性分支（短期分支，比如之前的iss53分支）能够通过所有测试，并且不会引入更多 bug 之后，就可以合并入主干分支中，等待下一次的发布。


事实上我们刚才讨论的，是随着你的提交而不断右移的指针。 稳定分支的指针总是在提交历史中落后一大截，而前沿分支的指针往往比较靠前。

通常把他们想象成流水线（work silos）可能更好理解一点，那些经过测试考验的提交会被遴选到更加稳定的流水线上去。

你可以用这种方法维护不同层次的稳定性。 一些大型项目还有一个 proposedpu（建议） 或proposed updates（建议更新）分支，它可能因包含一些不成熟的内容而不能进入 next或者master分支。 这么做的目的是使你的分支具有不同级别的稳定性； 当它们具有一定程度的稳定性后，再把它们合并入具有更高级别稳定性的分支中。 再次强调一下，使用多个长期分支的方法并非必要，但是这么做通常很有帮助，尤其是当你在一个非常庞大或者复杂的项目中工作时.


特性分支对任何规模的项目都适用。 特性分支是一种短期分支，它被用来实现单一特性或其相关工作。 也许你从来没有在其他的版本控制系统（）上这么做过，因为在那些版本控制系统中创建和合并分支通常很费劲。 然而，在 Git 中一天之内多次创建、使用、合并、删除分支都很常见。VCS

你已经在上一节中你创建的 和 特性分支中看到过这种用法。 你在上一节用到的特性分支（ 和 分支）中提交了一些更新，并且在它们合并入主干分支之后，你又删除了它们。 这项技术能使你快速并且完整地进行上下文切换（context-switch）——因为你的工作被分散到不同的流水线中，在不同的流水线中每个分支都仅与其目标特性相关，因此，在做代码审查之类的工作的时候就能更加容易地看出你做了哪些改动。 你可以把做出的改动在特性分支中保留几分钟、几天甚至几个月，等它们成熟之后再合并，而不用在乎它们建立的顺序或工作进度。iss53hotfixiss53hotfix

考虑这样一个例子，你在 分支上工作到 ，这时为了解决一个问题而新建 分支，在 分支上工作到 ，然而对于那个问题你又有了新的想法，于是你再新建一个 分支试图用另一种方法解决那个问题，接着你回到 分支工作了一会儿，你又冒出了一个不太确定的想法，你便在 的时候新建一个 分支，并在上面做些实验。 你的提交历史看起来像下面这个样子：masterC1iss91iss91C4iss91v2masterC10dumbidea

现在，我们假设两件事情：你决定使用第二个方案来解决那个问题，即使用在 分支中方案； 另外，你将 分支拿给你的同事看过之后，结果发现这是个惊人之举。 这时你可以抛弃 分支（即丢弃 和 提交），然后把另外两个分支合并入主干分支。 最终你的提交历史看起来像下面这个样子：iss91v2dumbideaiss91C5C6

我们将会在 分布式 Git 中向你揭示更多有关分支工作流的细节，因此，请确保你阅读完那个章节之后，再来决定你的下个项目要使用什么样的分支策略（branching scheme）。

请牢记，当你做这么多操作的时候，这些分支全部都存于本地。 当你新建和合并分支的时候，所有这一切都只发生在你本地的 Git 版本库中 —— 没有与服务器发生交互。