什么是分支
在玩剧情类游戏时,不同的选择会触发不同的剧情路线,每条剧情路线都会独立发展,最终走向不同的结局。
Git中所谓的“分支(branch)”就如同游戏中的剧情路线,用户可以为项目建立不同的分支,使得项目能在不同的分支里独立进行,并且互不干预。
当用户初始化一个仓库时,Git会自动为其建立一条主分支,默认称其为master。若用户没有创建其他分支,那么项目发展的各个版本就默认存储在这条 master
分支上。
分支指令介绍
分支的新建和切换
假设你正在项目上工作,并且在 master
分支上已经有了如下的提交。
对应的图即为如下:
master
指针指向该分支上最新的提交; HEAD
指针指向的是当前所在分支。
此时你发现了项目中有一个代号为#11的bug需要你解决。你决定专门新建一个分支,在那条分支上把该问题解决。于是你敲入了新建分支的指令。
上面两行命令可以仅用一条命令替代:$ git branch -b bug#11
。
当我们在创建新的分支时,实际上是创建一个新的指针。它会指向 master
此时指向的提交。当我们切换到分支 bug#11
时,HEAD
指针就会指向 bug#11
,如下图所示。
此外,我们可以用如下命令查看了目前仓库中存在的分支。
可以看到目前共存在2个分支,其中带*号的是目前所在分支:master
。
分支的作用
于是你开始在 bug#11
这条分支上工作,并作出了如下的提交(commit)。
于是 bug#11
指针往前移动了一步,而 master
指针还是留在原地。
这时,当你用 $ git checkout master
命令切换回 master
分支时,你发现刚才在 bug#11
分支上新建的 log.txt
文件不见了,当前的工作目录和你开始在 bug#11
分支工作前一模一样。
这就是分支的好处,它将工作切分开来,让工作多线独立发展。
合并分支
我们将介绍在合并分支时会遇到的3种情况。
Fast-Forward
此时,你已经把 #bug11
修复完毕,你决定把这项修复合并到主线 master
中。于是,你使用了 $ git merge
命令来实现这个目的。
在合并的时候,你注意到了“快进(Fast-forward)”这个词。当你试图合并两个分支时, 如果顺着一个分支走下去能够到达另一个分支,那么 Git 在合并两者的时候, 只会简单的将指针向前推进,因为这种情况下的合并操作没有需要解决的分歧——这就叫做 “快进(fast-forward)”,如图所示。
此时合并完成,所以你也不再需要 bug#11
分支了。你可以使用带 -d
选项的 $ git branch
命令来删除分支:
‘recursive’ strategy
此时,你又发现了项目中有一个代号为 bug#31
的漏洞需要修复,于是你先用 $ git branch bug#31
命令新建了一个分支。
现在的你还在 master
这条分支上工作:你将 Scheduling.txt
的文件内容修改为 Project Scheduling - 85% Done.
, 然后commit这次的修改。
此时,对应的图为如下:
现在的你感到心满意足,决心切换到 bug#31
分支上开始修复 bug#31
。于是你先用 $ git checkout bug#31
命令切换到了该分支。
接着你辛辛苦苦了一整天,总算把 bug#31
修复完了。于是你修改了 log.txt
文件里的内容,加上了一行Fixed bug#31.
,并commit这次的修改,此时的图对应如下:
现在,你决定把对 bug#31
的修复应用到 master
分支中来,于是你切换回 master
分支,然后再次调用了 $ git merge
命令:
你发现这次提示的和之前在合并 bug#11
分支时提示的不太一样。因为此时,你想合并的 bug#31
指向的最新提交 C4
并不是 master
指向的最新提交 C3
的直接后继(换句话说,C3
不能顺着一条路走到 C4
)。所以Git没法再那么通过简单的移动指针来完成合并了。
Git会找到 C3
和 C4
的共同祖先 C2
,然后做一个三方合并。
那么什么是三方合并呢?
例子1:A是B和C的共同祖先。B相对A的改动是删掉了3,C相对A的改动是增加了1。那么B和C合并的结果就是123。
例子2:A是B和C的共同祖先。B相对A的改动是删掉了1,C相对A的改动是增加了3。那么B和C合并的结果就是23。
所以简单来说,三方合并就是把B方和C方相对于共同祖先A方的改动分别应用到合并结果上。
刚才,C3
相对于 C2
的改动是修改了 Scheduling.txt
文件的内容,而 C4
相对于 C2
的改动是修改了 log.txt
文件里的内容,将这两项改动都应用到合并结果中,就得到了一个既修改了 Scheduling.txt
又修改了 log.txt
的 C5
。
遇到冲突时的合并
有时候合并操作不会如此顺利。 如果你在两个不同的分支中,对同一个文件进行了不同的修改,Git 就没法干净的合并它们。
例如:你在 bug#31
分支中在 README.md
文件中添加了一行 I like Git.
;在 master
分支中对 README.md
文件添加了一行 Git is good.
,然后再执行 $ git merge
命令:
在两个分支中,你都对 README.md
文件进行了修改,因此就会产生合并冲突。
打开 README.md
文件会看到如下内容,其中 <<<<<<< HEAD
到 =======
之间的内容是 HEAD
指向分支里的内容,即 master
;=======
到 >>>>>>> bug#31
之间的是 bug#31
分支里的内容。
你手动修改了这个文件,修改后的内容如下。
在Git轻松入门1:本地仓库篇,我们提到过,文件修改后,需要执行 $ git add
和 $ git commit
两个步骤。所以现在,你同样需要执行这两个步骤,而当你敲完命令,你会发现提示合并成功。
总结
总结一下今天出现过的几个Git命令:
# 列出该仓库存在的分支,当前分支的前面会带有*号
$ git branch
# 创建分支
$ git branch [branch-name]
# 切换分支
$ git checkout [branch-name]
# 创建分支并立刻切换到该分支下
$ git checkout -b [branch-name]
# 删除分支
$ git branch -d [branch-name]
# 合并分支
$ git merge [branch-name]
分支的作用在于将工作切分开来,使得工作可以多线独立发展。以上是本讲关于分支命令的概括。此外,本讲还介绍了Git采取的3种合并策略:Fast-forward(直接移动指针),recursive strategy(采取三方合并)以及merge conflict(手动修改存在冲突的文件)。
参考
- http://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
- https://www.zhihu.com/question/30200228
- https://www.liaoxuefeng.com/wiki/896043488029600/900003767775424
- https://www.runoob.com/git/git-branch.html
有问题欢迎大家在评论区留言,转载请注明出处。