Git 分支
几乎每一种版本控制系统都以某种形式支持分支。使用分支意味着你可以从开发主线上分离开来,然后在不影响主线的同时继续工作。
Git 的分支非常轻量。它们只是简单地指向某个提交纪录——仅此而已。所以许多 Git 爱好者会念叨:
早点建分支!经常建分支!
创建分支没有储存或内存上的开销,所以按逻辑分解工作比维护单一的代码树要简单。
同时使用分支和提交时,我们会看到两者如何配合。现在,只要记住使用分支其实就是在说:“我想包含本次提交及所有的父提交记录。”
举例 :建立分支 : git branch newImage
提交 : git commit :
master
分支前进了,但 newImage
分支没有哇!这是因为我们没有“在”这个新分支上,这也是为什么星号(*)只在 master
上。
使用如下命令告诉 Git 我们想要切换到新的分支
git checkout [name]
这可以让我们在提交修改之前切换到新的分支。
并 git commit :
我们已经知道怎么提交和使用分支了。接下来要学的一招是如何合并两个不同分支的工作。这让我们可以新建一个分支,在其上开发新功能,然后合并回主线。
git merge
是我们要学习的合并工作的第一个方法。合并产生一个特殊的提交记录,它包含两个唯一父提交。有两个父提交的提交记录本质上是:“我想把这两个父提交本身及它们的父提交集合都包含进来。”
当前有两个分支:各有一个唯一的提交。这意味着没有一个分支包含我们对代码库的所有修改。让我们合并这两个分支来解决这个问题。
我们要把 bugFix
合并到 master
git merge bugFix :
master
现在指向一个拥有两个父提交的提交记录。假如从 master
开始沿着箭头向上游走,在到达起点的路上会经过所有的提交记录。这说明有master
包含了对代码库的所有修改。
现在我们把 master
分支合并到 bugFix
吧。
git checkout bugFix; git merge master :
因为 bugFix
分支在 master
分支的下游,Git 什么都不用做,只是简单地把 bugfix
分支移动到 master
指向的提交记录。
现在所有的提交记录的颜色都是一样的啦,这表明每一个分支都包含了代码库的所有修改!走起!
Rebasing 是在分支之间合并工作的第二种方法。Rebasing 就是取出一系列的提交记录,"复制"它们,然后把在别的某个地方放下来。
虽然听上去难以理解,rebasing 的优势是可以创造更线性的提交历史。假如只允许使用 rebasing,代码库的提交日志/历史会更好看。
这里,还是有两个分支;注意当前分支是 bugFix(看那颗星)
我们想要把 bugFix 里面的工作直接移到 master 分支上。使用这个方法,两个分支的功能看起来像是按顺序开发,实际上它们是平行开发的。
用 git rebase
实现此目标
现在 bugFix 分支上的工作在 master 的最前端,同时我们也得到了一个更线性的提交序列。
注意,提交记录 C3 仍然存在(阴影的那货就是你了,还看什么看),而我们已经将 C3 复制到了 master。
现在唯一的问题是 master 分支还没有更新…… 下面就来更新它吧
master
分支。接下来就把它 rebase 到
bugFix
吧……
因为 master
是 bugFix
的下游,所以 git 只把master
分支的记录前移到 bugFix
上。