Git入门书籍 Pro Git 书籍系列 13.docx

3.2Git分支-分支的新建与合并
分支的新建与合并
现在让我们来看一个简单的分支与合并的例子，实际工作中大体也会用到这样的工作流程：
开发某个网站。
为实现某个新的需求，创建一个分支。
在这个分支上开展工作。
假设此时，你突然接到一个电话说有个很严重的问题需要紧急修补，那么可以按照下面的方式处理：
返回到原先已经发布到生产服务器上的分支。
为这次紧急修补建立一个新分支，并在其中修复问题。
通过测试后，回到生产服务器所在的分支，将修补分支合并进来，然后再推送到生产服务器上。
切换到之前实现新需求的分支，继续工作。
分支的新建与切换
首先，我们假设你正在项目中愉快地工作，并且已经提交了几次更新（见图3-10）。

图3-10.一个简短的提交历史
现在，你决定要修补问题追踪系统上的#53问题。顺带说明下，Git并不同任何特定的问题追踪系统打交道。这里为了说明要解决的问题，才把新建的分支取名为iss53。要新建并切换到该分支，运行gitcheckout并加上-b参数：
$gitcheckout-biss53
Switchedtoanewbranch'iss53'
这相当于执行下面这两条命令：
$gitbranchiss53
$gitcheckoutiss53
图3-11示意该命令的执行结果。

图3-11.创建了一个新分支的指针
接着你开始尝试修复问题，在提交了若干次更新后，iss53分支的指针也会随着向前推进，因为它就是当前分支（换句话说，当前的HEAD指针正指向iss53，见图3-12）：
$vimindex.html
$gitcommit-a-m'addedanewfooter[issue53]'

图3-12.iss53分支随工作进展向前推进
现在你就接到了那个网站问题的紧急电话，需要马上修补。有了Git，我们就不需要同时发布这个补丁和iss53里作出的修改，也不需要在创建和发布该补丁到服务器之前花费大力气来复原这些修改。唯一需要的仅仅是切换回master分支。
不过在此之前，留心你的暂存区或者工作目录里，那些还没有提交的修改，它会和你即将检出的分支产生冲突从而阻止Git为你切换分支。切换分支的时候最好保持一个清洁的工作区域。稍后会介绍几个绕过这种问题的办法（分别叫做stashing和commitamending）。目前已经提交了所有的修改，所以接下来可以正常转换到master分支：
$gitcheckoutmaster
Switchedtobranch'master'
此时工作目录中的内容和你在解决问题#53之前一模一样，你可以集中精力进行紧急修补。这一点值得牢记：Git会把工作目录的内容恢复为检出某分支时它所指向的那个提交对象的快照。它会自动添加、删除和修改文件以确保目录的内容和你当时提交时完全一样。
接下来，你得进行紧急修补。我们创建一个紧急修补分支hotfix来开展工作，直到搞定（见图3-13）：
$gitcheckout-bhotfix
Switchedtoanewbranch'hotfix'
$vimindex.html
$gitcommit-a-m'fixedthebrokenemailaddress'
[hotfix3a0874c]fixedthebrokenemailaddress
1fileschanged,1deletion(-)

图3-13.hotfix分支是从master分支所在点分化出来的
有必要作些测试，确保修补是成功的，然后回到master分支并把它合并进来，然后发布到生产服务器。用gitmerge命令来进行合并：
$gitcheckoutmaster
$gitmergehotfix
Updatingf42c576..3a0874c
Fast-forward
README|1-
1filechanged,1deletion(-)
请注意，合并时出现了“Fastforward”的提示。由于当前master分支所在的提交对象是要并入的hotfix分支的直接上游，Git只需把master分支指针直接右移。换句话说，如果顺着一个分支走下去可以到达另一个分支的话，那么Git在合并两者时，只会简单地把指针右移，因为这种单线的历史分支不存在任何需要解决的分歧，所以这种合并过程可以称为快进（Fastforward）。
现在最新的修改已经在当前master分支所指向的提交对象中了，可以部署到生产服务器上去了（见图3-14）。

图3-14.合并之后，master分支和hotfix分支指向同一位置。
在那个超级重要的修补发布以后，你想要回到被打扰之前的工作。由于当前hotfix分支和master都指向相同的提交对象，所以hotfix已经完成了历史使命，可以删掉了。使用gitbranch的-d选项执行删除操作：