Git 分支的新建与合并.pdf

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