Git 分支管理完全指南：从创建、合并到冲突解决

删除分支

合并完成后，如果 dev 分支对于我们来说就没用了，那么就可以被删除掉。

**注意：**如果当前正处于某分支下，就不能删除当前分支。

$ git checkout master
$ git branch -d dev
Deleted branch dev (was bdaf528).

因为创建、合并和删除分支非常快，所以 Git 鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在 master 分支上工作效果是一样的，但过程更安全。

合并冲突

在实际分支合并的时候，并不是想合并就能合并成功的，有时候可能会遇到代码冲突的问题。

为了演示这个问题，我们再创建一个新的分支 dev1，并切换至目标分支：

$ git checkout -b dev1
Switched to a new branch 'dev1'

在 dev1 分支下修改 ReadMe 文件，更改文件内容如下所示，并进行一次提交：

$ git add .
$ git commit -m "modify ReadMe"
[dev1 0854245] modify ReadMe
 1 file changed, 1 insertion(+), 1 deletion(-)

切换至 master 分支，观察 ReadMe 文件内容。此时在 master 分支上，我们对 ReadMe 文件再进行一次修改，并进行提交：

$ git checkout master
$ git add .
$ git commit -m "modify ReadMe"
[master c10f6d0] modify ReadMe
 1 file changed, 1 insertion(+), 1 deletion(-)

现在，master 分支和 dev1 分支各自都分别有新的提交。这种情况下，Git 只能试图把各自的修改合并起来，但这种合并就可能会有冲突：

$ git merge dev1
Auto-merging ReadMe
CONFLICT (content): Merge conflict in ReadMe
Automatic merge failed; fix conflicts and then commit the result.

我们发现 ReadMe 文件有冲突后，可以直接查看文件内容，Git 会用 <<<<<<<, =======, >>>>>>> 来标记出不同分支的冲突内容：

$ cat ReadMe
hello bit hello git hello world hello version1 hello version2 hello version3
<<<<<<< HEAD
write ccc for new branch
=======
write bbb for new branch
>>>>>>> dev1

此时我们必须要手动调整冲突代码，并需要再次提交修正后的结果（再次提交很重要！）：

$ cat ReadMe
# 保留需要的内容，移除冲突标记
$ git add .
$ git commit -m "merge ReadMe"
[master 2976afc] merge ReadMe

到这里冲突就解决完成。用带参数的 git log 也可以看到分支的合并情况：

$ git log --graph --pretty=oneline --abbrev-commit
* 2976afc (HEAD -> master) merge ReadMe
| |
| * c594fd1 (dev1) modify ReadMe
* | c10f6d0 modify ReadMe
|/

最后的最后，大家不要忘记 dev1 分支使用完毕后就可以删除了！

分支管理策略

合并分支时，如果可能，Git 通常会采用 Fast forward 模式。在这种模式下，删除分支后，查看分支历史时，会丢掉分支信息，看不出来最新提交到底是 merge 进来的还是正常提交的。

但在合并冲突部分，我们也看到通过解决冲突问题，会再进行一次新的提交，得到的最终状态就不是 Fast forward 模式了。这样的好处是：从分支历史上就可以看出分支信息。

Git 支持我们强制禁用 Fast forward 模式，那么就会在 merge 时生成一个新的 commit，这样，从分支历史上就可以看出分支信息。下面我们实战一下 --no-ff 方式的 git merge。

首先，创建新的分支 dev2，并切换至新的分支：

$ git checkout -b dev2
Switched to a new branch 'dev2'

修改 ReadMe 文件，并提交一个新的 commit：

$ git add .
$ git commit -m "modify ReadMe"
[dev2 41b082f] modify ReadMe
 1 file changed, 1 insertion(+)

切回 master 分支，开始合并：

$ git checkout master
$ git merge --no-ff -m "merge with no-ff" dev2
Merge made by the 'recursive' strategy.
ReadMe | 1 +
 1 file changed, 1 insertion(+)

请注意 --no-ff 参数，表示禁用 Fast forward 模式。禁用 Fast forward 模式后合并会创建一个新的 commit，所以加上 -m 参数，把描述写进去。合并后，查看分支历史，可以看到不使用 Fast forward 模式，merge 后就像这样：分支历史保留了合并节点，能看出来曾经做过合并，而 fast forward 合并就看不出来曾经做过合并。

Bug 分支处理

假如我们现在正在 dev2 分支上进行开发，开发到一半，突然发现 master 分支上面有 bug，需要解决。在 Git 中，每个 bug 都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

可现在 dev2 的代码在工作区中开发了一半，还无法提交，怎么办？例如：

$ git status
On branch dev2
Changes not staged for commit:
  modified: ReadMe

Git 提供了 git stash 命令，可以将当前的工作区信息进行储藏，被储藏的内容可以在将来某个时间恢复出来：

$ git stash
Saved working directory and index state WIP on dev2: 41b082f modify ReadMe
$ git status
On branch dev2
nothing to commit, working tree clean

储藏 dev2 工作区之后，由于我们要基于 master 分支修复 bug，所以需要切回 master 分支，再新建临时分支来修复 bug：

$ git checkout master
$ git checkout -b fix_bug
Switched to a new branch 'fix_bug'
$ vim ReadMe
# 修复 bug
$ git add ReadMe
$ git commit -m "fix bug"
[fix_bug 4bbc0c4] fix bug
 1 file changed, 1 insertion(+), 1 deletion(-)

修复完成后，切换到 master 分支，并完成合并，最后删除 fix_bug 分支：

$ git checkout master
$ git merge --no-ff -m "merge fix_bug branch" fix_bug
$ git branch -d fix_bug
Deleted branch fix_bug (was 4bbc0c4).

至此，bug 的修复工作已经做完了，我们还要继续回到 dev2 分支进行开发。切换回 dev2 分支：

$ git checkout dev2
$ git stash list
stash@{0}: WIP on dev2: 41b082f modify ReadMe

工作现场还在，Git 把 stash 内容存在某个地方了，但是需要恢复一下。我们可以使用 git stash pop 命令，恢复的同时会把 stash 也删了：

$ git stash pop
Dropped refs/stash@{0}

另外，恢复现场也可以采用 git stash apply stash@{0} 恢复，但是恢复后，stash 内容并不删除，你需要用 git stash drop 来删除。

恢复完代码之后我们便可以继续完成开发，开发完成后便可以进行提交。但我们注意到了修复 bug 的内容并没有在 dev2 上显示。此时的状态图显示 master 分支目前最新的提交，是要领先于新建 dev2 时基于的 master 分支的提交的。

我们的最终目的是要让 master 合并 dev2 分支的，那么正常情况下我们切回 master 分支直接合并即可，但这样其实是有一定风险的。因为在合并分支时可能会有冲突，而代码冲突需要我们手动解决。我们无法保证对于冲突问题可以正确地一次性解决掉。

解决这个问题的一个好的建议就是：最好在自己的分支上合并下 master，再让 master 去合并 dev，这样做的目的是有冲突可以在本地分支解决并进行测试，而不影响 master。

对应的实操演示如下：

# dev 合并 master
$ git merge master
# 发生冲突，解决冲突并重新提交
$ vim ReadMe
$ git add .
$ git commit -m "merge master"

# 切回 master
$ git checkout master
# master 合并 dev2---无需解决冲突！！
$ git merge dev2
Updating 193421f..447d29f Fast-forward
$ git status
On branch master
nothing to commit, working tree clean
# 删除 dev2 分支
$ git branch -d dev2
Deleted branch dev2 (was 447d29f).

删除临时分支

软件开发中，总有无穷无尽的新的功能要不断添加进来。每添加一个新功能，最好新建一个分支，我们可以将其称之为 feature 分支，在上面开发，完成后再合并，最后，删除该 feature 分支。

可是，如果我们今天正在某个 feature 分支上开发了一半，被产品经理突然叫停，说是要停止新功能的开发。虽然白干了，但是这个 feature 分支还是必须就地销毁，留着已经无用了。这时我们使用传统的 git branch -d 命令删除分支的方法是不行的。

$ git checkout master
$ git branch -d dev3
error: The branch 'dev3' is not fully merged. If you are sure you want to delete it, run 'git branch -D dev3'.

直接使用传统的删除分支的方法不行，按照提示，才有了如下方式：

$ git branch -D dev3
Deleted branch dev3 (was cd2f149).

小结

分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你已经写了 50% 的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

现在有了分支，就不用怕了。你创建一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样既安全又不影响别人工作。

并且，Git 无论创建、切换和删除分支，Git 在 1 秒钟之内就能完成！无论你的版本库是 1 个文件还是 1 万个文件——高效。