git分支实例.docVIP

分支的新建 首先，我们假设你正在项目中愉快地工作，并且已经提交了几次更新（见图 3-10）。 图 3-10. 一个简短的提交历史 现在，你决定要修补问题Qone系统上的 #53 问题。这里为了说明要解决的问题，才把新建的分支取名为 iss53。要新建并切换到该分支，运行 git checkout 并加上 -b 参数： $ git checkout -b iss53 Switched 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?唯一需要的仅仅是切换回 master 分支。假设目前已经提交了所有的修改，所以接下来可以正常转换到 master 分支： $ git checkout master 接下来，你得进行紧急修补。我们创建一个紧急修补分支 hotfix 来开展工作，直到搞定（见图 3-13）： $ git checkout -b hotfix 图 3-13. hotfix 分支是从 master 分支所在点分化出来的 有必要作些测试，确保修补是成功的，然后回到 master 分支并把它合并进来，然后发布到生产服务器。用 git merge 命令来进行合并： $ git checkout master $ git merge hotfix 在那个超级重要的修补发布以后，你想要回到被打扰之前的工作。由于当前 hotfix 分支和 master 都指向相同的提交对象，所以 hotfix 已经完成了历史使命，可以删掉了。使用 git branch 的 -d 选项执行删除操作： $ git branch -d hotfix Deleted branch hotfix (3a0874c).现在回到之前未完成的 #53 问题修复分支上继续工作（图 3-15）： $ git checkout iss53 Switched to branch iss53 $ vim index.html $ git commit -a -m finished the new footer [issue 53] [iss53]: created ad82d7a: finished the new footer [issue 53] 1 files changed, 1 insertions(+), 0 deletions(-) 用担心之前 hotfix 分支的修改内容尚未包含到 iss53 中来。如果确实需要纳入此次修补，可以用 git merge master 把 master 分支合并到 iss53；或者等 iss53 完成之后，再将 iss53 分支中的更新并入 master。 分支的合并 在问题 #53 相关的工作完成之后，可以合并回 master 分支。实际操作同前面合并 hotfix 分支差不多，只需回到 master 分支，运行 git merge 命令指定要合并进来的分支： $ git checkout master $ git merge iss53 这次，Git 没有简单地把分支指针右移，而是对三方合并后的结果重新做一个新的快照，并自动创建一个指向它的提交对象（C6）（见图 3-17）。这个提交对象比较特殊，它有两个祖先（C4 和 C5）。因为这次你的开发历史是从更早的地方开始分叉的。由于当前 master 分支所指向的提交对象（C4）并不是 iss53 分支的直接祖先，Git 不得不进行一些额外处理。就此例而言，Git 会用两个分支的末端（C4 和 C5）以及它们的共同祖先（C2）进行一次简单的三方合并计算。图 3-16 用红框标出了 Git 用于合并的三个提交对象： 图 3-16. Git 为分支合并自动识别出最佳的同源合并点。 既然之前的工作成果已经合并到 master 了，那么 iss53 也就没用了。你可以就此删除它，并在问题追踪系统里关闭该问题。 $ git branch -d iss53 遇到冲突时的分支合并 有时候合并操作并不会如此顺利。如果在不同的分支中都修改了同一个文件的同一部分，Git 就无法干净地把两者合到一起（译注：