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

3.2 Git 分支 - 分支的新建与合并分支的新建与合并现在让我们来看一个简单的分支与合并的例子，实际工作中大体也会用到这样的工作流程：开发某个网站。为实现某个新的需求，创建一个分支。在这个分支上开展工作。假设此时，你突然接到一个电话说有个很严重的问题需要紧急修补，那么可以按照下面的方式处理：返回到原先已经发布到生产服务器上的分支。为这次紧急修补建立一个新分支，并在其中修复问题。通过测试后，回到生产服务器所在的分支，将修补分支合并进来，然后再推送到生产服务器上。切换到之前实现新需求的分支，继续工作。分支的新建与切换首先，我们假设你正在项目中愉快地工作，并且已经提交了几次更新（见图 3-10）。图 3-10. 一个简短的提交历史现在，你决定要修补问题追踪系统上的 #53 问题。顺带说明下，Git 并不同任何特定的问题追踪系统打交道。这里为了说明要解决的问题，才把新建的分支取名为 iss53。要新建并切换到该分支，运行 git checkout 并加上 -b 参数：$ git checkout -b iss53Switched to a new branch iss53这相当于执行下面这两条命令：$ git branch iss53$ git checkout iss53图 3-11 示意该命令的执行结果。图 3-11. 创建了一个新分支的指针接着你开始尝试修复问题，在提交了若干次更新后，iss53 分支的指针也会随着向前推进，因为它就是当前分支（换句话说，当前的 HEAD 指针正指向 iss53，见图 3-12）：$ vim index.html$ git commit -a -m added a new footer [issue 53]图 3-12. iss53 分支随工作进展向前推进现在你就接到了那个网站问题的紧急电话，需要马上修补。有了 Git ，我们就不需要同时发布这个补丁和 iss53 里作出的修改，也不需要在创建和发布该补丁到服务器之前花费大力气来复原这些修改。唯一需要的仅仅是切换回 master 分支。不过在此之前，留心你的暂存区或者工作目录里，那些还没有提交的修改，它会和你即将检出的分支产生冲突从而阻止 Git 为你切换分支。切换分支的时候最好保持一个清洁的工作区域。稍后会介绍几个绕过这种问题的办法（分别叫做 stashing 和 commit amending）。目前已经提交了所有的修改，所以接下来可以正常转换到 master 分支：$ git checkout masterSwitched to branch master此时工作目录中的内容和你在解决问题 #53 之前一模一样，你可以集中精力进行紧急修补。这一点值得牢记：Git 会把工作目录的内容恢复为检出某分支时它所指向的那个提交对象的快照。它会自动添加、删除和修改文件以确保目录的内容和你当时提交时完全一样。接下来，你得进行紧急修补。我们创建一个紧急修补分支 hotfix 来开展工作，直到搞定（见图 3-13）：$ git checkout -b hotfixSwitched to a new branch hotfix$ vim index.html$ git commit -a -m fixed the broken email address[hotfix 3a0874c] fixed the broken email address 1 files changed, 1 deletion(-)图 3-13. hotfix 分支是从 master 分支所在点分化出来的有必要作些测试，确保修补是成功的，然后回到 master 分支并把它合并进来，然后发布到生产服务器。用 git merge 命令来进行合并：$ git checkout master$ git merge hotfixUpdating f42c576..3a0874cFast-forward README | 1 - 1 file changed, 1 deletion(-)请注意，合并时出现了“Fast forward”的提示。由于当前 master 分支所在的提交对象是要并入的 hotfix 分支的直接上游，Git 只需把 master 分支指针直接右移。换句话说，如果顺着一个分支走下去可以到达另一个分支的话，那么 Git 在合并两者时，只会简单地把指针右移，因为这种单线的历史分支不存在任何需要解决的分歧，所以这种合并过程可以称为快进（Fast forward）。现在最新的修改已经在当前 master 分支所指向的提交对象中了，可以部署到生产服务器上去了（见图 3-14）。图 3-14. 合并之后，master 分支和 hotfix 分支指向同一位置。在那个超级重要的修补发布以后