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

总结一下——

切换分支

**那如何切换到 dev 分支下进行开发呢？**使用 git checkout 命令即可完成切换，示例如下：

user@host:~$ git checkout dev
Switched to branch 'dev'
user@host:~$ git branch
* dev
  master
user@host:~$ cat .git/HEAD
ref: refs/heads/dev

我们发现：HEAD 已经指向了 dev——表示我们已经成功的切换到了 dev 上！

接下来，在 dev 分支下修改 ReadMe 文件，新增一行内容，并进行一次提交操作：

user@host:~$ vim ReadMe
user@host:~$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write aaa for new branch
user@host:~$ git add .
user@host:~$ git commit -m"modify ReadMe"
[dev 3740dce] modify ReadMe 1 file changed, 1 insertion(+)

现在，dev 分支的工作完成，我们就可以切换回 master 分支：

user@host:~$ git checkout master
Switched to branch 'master'
user@host:~$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3

切换回 master 分支后，发现 ReadMe 文件中新增的内容不见了！赶紧再切回 dev 看看：

user@host:~$ git checkout dev
Switched to branch 'dev'
user@host:~$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write aaa for new branch 

在 dev 分支上，内容还在——为什么会出现这个现象呢？

我们来看看 dev 分支和 master 分支指向，发现两者指向的提交是不一样的：

user@host:~$ cat .git/refs/heads/dev
bdaf528ffbb8e05aee34d37685408f0e315e31a4
user@host:~$ cat .git/refs/heads/master
5476bdeb12510f7cd72ac4766db7988925ebd302

看到这里就能明白了，因为我们是在 dev 分支上提交的，而 master 分支此刻的提交点并没有变，此时的状态如图如下所示。

当切换到 master 分支之时，HEAD 就指向了 master，当然看不到提交了！

合并分支

为了在 master 主分支上能看到新的提交，就需要将 dev 分支合并到 master 分支，示例如下：

user@host:~$ git branch
* dev
  master
user@host:~$ git checkout master # 切换到 master 上进⾏合并
Switched to branch 'master'
user@host:~$ git merge dev # 合并 dev 分⽀
Updating 16623e1..3740dce Fast-forward
ReadMe | 1 +
1 file changed, 1 insertion(+)
user@host:~$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write aaa for new branch 

git merge 命令用于合并指定分支到当前分支。合并后，master 就能看到 dev 分支提交的内容了。此时的状态如图如下所示。

Fast-forward 代表**'快进模式'**：也就是直接把 master 指向 dev 的当前提交，所以合并速度非常快。当然，也不是每次合并都能 Fast-forward，我们后面会讲其他方式的合并。

删除分支

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

**注意：**如果当前正处于某分支下，就不能删除当前分支，举个例子——

user@host:~$ git branch
* dev
  master
user@host:~$ git branch -d dev
error: Cannot delete branch 'dev' checked out at '/home/hyb/gitcode'

可以在其他分支下删除当前分支，比如——

user@host:~$ git checkout master
Switched to branch 'master'
user@host:~$ git branch -d dev
Deleted branch dev (was bdaf528).
user@host:~$ git branch
* master

此时分支的状态如图如下所示——

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

合并冲突

在实际分支合并的时候，并不是想合并就能合并成功的，有时候可能会遇到代码冲突的问题。 为了演示这问题，我们再创建一个新的分支 dev1，并切换至目标分支，我们可以使用命令：

git checkout -b dev1

一步完成创建并切换的动作，示例如下：

user@host:~$ git checkout -b dev1
Switched to a new branch 'dev1'
user@host:~$ git branch
* dev1
  master

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

user@host:~$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch # 将 aaa 该为 bbb
user@host:~$ git add .
user@host:~$ git commit -m"modify ReadMe"
[dev1 0854245] modify ReadMe 1 file changed, 1 insertion(+), 1 deletion(-)

切换至 master 分支，观察 ReadMe 文件内容：

user@host:~$ git checkout master
Switched to branch 'master'
user@host:~$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write aaa for new branch

我们发现：切回来之后，文件内容又变成了老的版本，这种现象很正常，我们现在也完全能理解。 此时在 master 分支上，我们对 ReadMe 文件再进行一次修改，并进行提交，如下：

user@host:~$ git branch dev1 * master
user@host:~$ vim ReadMe
user@host:~$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write ccc for new branch
user@host:~$ git add .
user@host:~$ git commit -m"modify ReadMe"
[master c10f6d0] modify ReadMe 1 file changed, 1 insertion(+), 1 deletion(-)

现在，master 分支和 devi 分支各自都分别有新的提交，此时状态如下所示——

这种情况下，Git 只能试图把各自的修改合并起来，但这种合并就可能会有冲突，如下所示：

user@host:~$ git merge dev1
Auto-merging ReadMe
CONFLICT (content): Merge conflict in ReadMe
Automatic merge failed; fix conflicts and then commit the result.
user@host:~$ git status
On branch master
You have unmerged paths. (fix conflicts and run "git commit")
(use "git merge --abort" to abort the merge)
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: ReadMe
no changes added to commit (use "git add" and/or "git commit -a")

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

user@host:~$ 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

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

user@host:~$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
user@host:~$ git add .
user@host:~$ git commit -m"merge ReadMe"
[master 2976afc] merge ReadMe

到这里冲突就解决完成，此时的状态变成了——

用带参数的 git log 也可以看到分支的合并情况，大家可以自行搜索 git log 的用法：

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

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

user@host:~$ git branch
* master
user@host:~$ git branch -d dev1
Deleted branch dev1 (was c594fd1).

分支管理策略

合并分支时，如果可能，Git 通常会采用 Fast forward 模式。还记得如果我们采用 Fast forward 模式之后，形成的合并结果是什么呢？我们回忆一下——

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

但在合并冲突部分，我们也看到通过解决冲突问题，会再进行一次新的提交，得到的最终状态为：

这就不是 Fast forward 模式了，这样的好处是：从分支历史上就可以看出分支信息。例如我们现在已经删除了在合并冲突部分创建的 dev1 分支，但依 l 旧能看到 master 其实是由其他分支合并得到：

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

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

下面我们实战一下-no-ff 方式的 git merge。首先，创建新的分支 dev2，并切换至新的分支：

user@host:~$ git checkout -b dev2
Switched to a new branch 'dev2'

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

user@host:~$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch a,b,c,d hyb
user@host:~$ git add .
user@host:~$ git commit -m"modify ReadMe"
[dev2 41b082f] modify ReadMe 1 file changed, 1 insertion(+)

切回 master 分支，开始合并：

user@host:~$ git checkout master
Switched to branch 'master'
user@host:~$ git merge --no-ff -m "merge with no-ff" dev2
Merge made by the 'recursive' strategy.
ReadMe | 1 +
1 file changed, 1 insertion(+)
user@host:~$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch a,b,c,d hyb

请注意--no-ff 参数，表示禁用 Fast forward 模式。

禁用 Fast forward 模式后合并会创建一个新的 commit，所以加上-m 参数，把描述写进去。

合并后，查看分支历史：

user@host:~$ git log --graph --pretty=oneline --abbrev-commit
* 5bd16b4 (HEAD -> master) merge with no-ff
| |
| * 41b082f (dev2) modify ReadMe
|/ 

可以看到，不使用 Fast forward 模式，merge 后就像这样:

所以在合并分支时，加上--no-ff 参数就可以用普通模式合并，合并后的历史有分支，能看出来曾 经做过合并，而 fast forward 合并就看不出来曾经做过合并。

分支策略

在实际开发中，我们应该按照几个基本原则进行分支管理——

首先，master 分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在 dev 分支上，也就是说，dev 分支是不稳定的，到某个时候——比如 1.0 版本发布时，再把 dev 分支合并到 master 上，在 master 分支发布 1.0 版本；

你和你的小伙伴们每个人都在 dev 分支上干活，每个人都有自己的分支，时不时地往 dev 分支上合并就可以了。

所以，团队合作的分支看起来就像这样：

Bug 分支

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

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

user@host:~$ git branch
* dev2
  master
user@host:~$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch a,b,c,d hyb
i am coding ...
user@host:~$ git status
On branch dev2
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: ReadMe
no changes added to commit (use "git add" and/or "git commit -a")

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

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

用 git status 查看工作区，就是干净的（除非有没有被 Git 管理的文件），因此可以放心地创建分支来修复 bug。

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

user@host:~$ git checkout master # 切回 master
Switched to branch 'master'
user@host:~$ git checkout -b fix_bug # 新建并切换到 fix_bug 分 ⽀
Switched to a new branch 'fix_bug'
user@host:~$ vim ReadMe
user@host:~$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch a,b,c,d,e # 修复 bug--忘记写 e
user@host:~$ git add ReadMe # 重新 add，commit
user@host:~$ git commit -m"fix bug"
[fix_bug 4bbc0c4] fix bug 1 file changed, 1 insertion(+), 1 deletion(-)

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

user@host:~$ git checkout master
Switched to branch 'master'
user@host:~$ git merge --no-ff -m"merge fix_bug branch" fix_bug
Merge made by the 'recursive' strategy.
ReadMe | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
user@host:~$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch a,b,c,d,e
user@host:~$ git branch -d fix_bug
Deleted branch fix_bug (was 4bbc0c4).

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

user@host:~$ git checkout dev2
Switched to branch 'dev2'
user@host:~$ git status
On branch dev2
nothing to commit, working tree clean

工作区是干净的，刚才的工作现场存到哪去了？用 git stash list 命令看看：

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

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

user@host:~$ git stash pop
On branch dev2
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: ReadMe
no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (4f873250b35e496998a9f446dbd2cade)

再次查看的时候，我们已经发现已经没有现场可以恢复了——

user@host:~$ git stash list
user@host:~$

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

你可以多次 stash，恢复的时候，先用 git stash list 查看，然后恢复指定的 stash，用命令 git stash apply stash@[0}，这部分请自行使用。

恢复完代码之后我们便可以继续完成开发，开发完成后便可以进行提交，例如：

user@host:~$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch a,b,c,d hyb
i am coding ...
Done!
user@host:~$ git add .
user@host:~$ git commit -m"modify ReadMe"
[dev2 ed0916d] modify ReadMe 1 file changed, 1 insertion(+)

但我们注意到了修复 bug 的内容并没有在 dev2 上显示。此时的状态图如下所示——

master 分支目前最新的提交，是要领先于新建 dev2 时基于的 master 分支的提交的，所以我们在 dev2 中当然看不见修复 bug 的相关代码。

我们的最终目的是要让 master 合并 dev2 分支的，那么正常情况下我们切回 master 分支直接合并即可，但这样其实是有一定风险的。

是因为在合并分支时可能会有冲突，而代码冲突需要我们手动解决（在 master 上解决）。我们无法保证对于冲突问题可以正确地一次性解决掉，因为在实际的项目中，代码冲突不只一两行那么简单，有可能几十上百行，甚至更多！解决的过程中难免手误出错，导致错误的代码被合并到 master 上。此时的状态如下图所示——

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

对应的实操演示如下，要说明的是，以下演示的 merge 操作，没有使用--no-ff，但上述的图示是禁用 Fast forward 模式后得出的，主要是为了方便解释问题。

# dev 合并 master
user@host:~$ git branch
* dev2
  master
user@host:~$ git merge master
Auto-merging ReadMe
CONFLICT (content): Merge conflict in ReadMe
Automatic merge failed; fix conflicts and then commit the result.
# 发⽣冲突
user@host:~$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
<<<<<<< HEAD
a,b,c,d hyb
i am coding ...
Done!
=======
a,b,c,d,e
>>>>>>> master
# 解决冲突并重新提交
user@host:~$ vim ReadMe
user@host:~$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d hyb
a,b,c,d,e
i am coding ...
Done!
user@host:~$ git add .
user@host:~$ git commit -m"merge master"
[dev2 447d29f] merge master
user@host:~$ git status
On branch dev2
nothing to commit, working tree clean
# 切回 master
user@host:~$ git checkout master
Switched to branch 'master'
# master 合并 dev2---⽆需解决冲突！！
user@host:~$ git merge dev2
Updating 193421f..447d29f Fast-forward
ReadMe | 1 +
1 file changed, 1 insertion(+)
user@host:~$ git status
On branch master
nothing to commit, working tree clean
# 删除 dev2 分⽀
user@host:~$ git branch -d dev2
Deleted branch dev2 (was 447d29f).

删除临时分支

软件开发中，总有无穷无尽的新的功能要不断添加进来。

添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个分支，我们可以将其称之为 feature 分支，在上面开发，完成后再合并，最后，删除该 feature 分支。

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

# 新增并切换到 dev3 分⽀
user@host:~$ git checkout -b dev3
Switched to a new branch 'dev3'
# 开始开发新功能并提交
user@host:~$ vim ReadMe
user@host:~$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch a,b,c,d hyb
i am coding ...
Done!
i am writing new features ...
user@host:~$ git add .
user@host:~$ git commit -m"modify ReadMe for new features"
[dev3 cd2f149] modify ReadMe for new features 1 file changed, 1 insertion(+)
# 此时新功能叫停
# 切回 master 准备删除 dev3
user@host:~$ git checkout master
Switched to branch 'master'
# 常规删除 dev3 分⽀时失败
user@host:~$ 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'.

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

user@host:~$ git branch -D dev3
Deleted branch dev3 (was cd2f149).
user@host:~$ git branch
* master

分支管理部分小结

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

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

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

结尾

创作过程中难免有所缺漏，如果读者发现文章哪里有所疏忽，望不吝赐教！感谢支持！