理解git结构与简单操作(四)合并分支的方法与策略

接上节,此时的dev分支与master分支的进度就不一样了,所以需要将dev分支与master分支同步。这里需要的就是合并分支的操作,大家应该都知道用git merge或者git rebase

git merge

merge,即「合并」。

fast-forward

当出现我们上面图中的那种情况时,时间线只有一条,dev分支只不过是落后master分支而已。此时我们在dev分支上执行git merge maseter时,git就仅仅会把dev分支指针移动到master分支所在的位置,假装合并了,就变成了这样:

这种merge的方式叫做「fast-forward」,也是git默认的merge方式。

如果情况改变了,举个例子:我们在开发过程中,一直使用的是master分支,这时出了一个很严重的bug,我们就需要建立一个叫topic的分支来处理这个bug,但主要的功能工期又不能拖,所以master分支与topic分支就同时向前推进,此时时间线如图所示(此图出自git自己的帮助文件,使用命令git help merge即可看到。想看其他命令的帮助就git help <command>即可):

这时候,topic上的bug修改完毕,需要合并回master分支,需要的操作为:切换到master分支git checkout master,合并topicgit merge topic

注意,这时候的这两条分支是真正的「分支」了,他们在时间线上岔开了,各自分支都有自己独有的东西。因为此时的topic分支的末端并不在master分支的父端,需要把不同的修改同步起来,单纯的指针移动不能完成这一步,fast-forward方式也就不可能实现了。

这时,git便会将两个分支不同的地方取出,合并成一个commit,然后把master指针指向这个新的commit(就是在master上生成了一次commit)。这样,topic分支上的修改就同步到master分支上了。此时分支情况如图:

no fast-forward

BTW,能够进行fast-forward的merge情况下,也可以通过增加--no-ff命令来强制不使用fast-forward模式。假如还是回到我们master-dev两个分支的例子,master领先于dev分支:

这时我们不用fast-forward,在落后的dev分支上执行git merge master --no-ff,git会在dev上强行创建一个commit,把master分支上不同于dev的修改加进去,分支线就会变成这种诡异的样子:

(本手残渣画图实在是不好看,就直接用GUI工具source tree上的情况截图了)

底层上,git会把将要合并的两个分支的各个commit快照进行差异比较,求出它们之间的最长公共子序列,并把公共子序列从中去掉,得出各自存在两个分支中的不同修改,并将其合并成一个commit放在当前分支的顶端。

这里仅仅说明一点原理,具体实现方式与算法本人也只是懂一点皮毛,只要明白fast-forward与不使用的情况下merge,分支会产生什么样的情况,用来工作就没有任何问题了。

squash

除了--no-ff,merge还有另一种合并的方式:--squash。这种方法在符合fast-forward的情况下依然会执行fast-forward方式,不会有任何改变。但当遇到如下情况时:

假设我们要将topic合并到master上来,squash方式会集中topic的「A、B、C」三次commit中的修改合并,并添加到暂存区中。这时master分支与topic分支不会有任何的变动,只不过暂存区中会被添加topic上修改的集合(暂存区=A+B+C)。这时我们就可以查看暂存区中的内容是不是符合一次提交,之后commit就可以了。git help merge里是这么描述的:「create a single commit instead of doing a merge」,结合上面的讲解就可以理解squash的意思了吧。

git merge 解决冲突

fast-forward中是没有冲突的(不明白为啥没冲突的面壁思过)。而在其他情况时,如果两个分支同时有对同一个文件(行)的修改,就会产生冲突。这时git会在产生冲突的文件里写一堆这样的东西:

上面的「<<<<<<<< HEAD」直到「========」的部分,就是当前分支的修改(看到HEAD就知道是指向当前分支的指针了)。而「========」到下面的「>>>>>>> dev」的部分自然就是dev分支合并过来的修改啦。这时需要你仔细对比冲突,如果跟同事合作的话就要商量好,然后把「<<<<< HEAD ===== >>>>> dev」之类git给你加上的东西和不需要的修改部分删掉。接下来git status就会看到下面的提示:

上面绿的的东西自然就在暂存区了,这些代表dev分支上并不冲突的部分。下面的红色文件就代表你冲突的文件,当你修改之后需要走一遍add -> commit的流程(这个commit可以不指定commit message),也可以直接执行git commit -a,就完成merge创建新commit的过程了。

涉及操作:git merge <branch>, git merge <branch> --no-ff, git merge <branch> --squash, git checkout <branch>, git help <command>

git rebase

除了merge,git还有一种分支合并的方式,叫做git rebase。

rebase,就是「re」与「base」结合,官方译名「变基」(咖喱gaygayʕ •ᴥ•ʔ)。这个「变基」的含义从字面上确实不是很好理解,先来看一下rebase示例:

回到我们master-dev两个分支的例子,master领先于dev分支:

这时候我们在dev分支上执行git rebase master,master便与dev合并了,如图所示:

此时你内心OS:这不是跟fast-forward模式下的merge一样么?莫急莫急,我们再看一下出现这样情况下的分支(作者偷懒拿前面图糊弄了嘿嘿嘿):

不着急解释原理,我们先看看在topic上执行git rebase master的结果(就是将master合并到topic上):

看图得知:master上的「F」「G」两次提交,变成了topic分支的父节点,整个分支又重新合成为一条时间线。在本例中,你可以想象「biu」的一下把topic分支拔下来,然后「pu」的一下把它插到了master的顶端(大雾)。

当然,git肯定不是像上面那样「biu」「pu」地操作分支的。

git help rebase中是这样描述git rebase的:

git-rebase - Reapply commits on top of another base tip

翻译一下,就是「将你的commit们在另一个基准点上重新应用」。注意这里的「reapply」,git并不会直接移动commit本身,而是会为需要rebase的分支上的commit分别创建一个patch「补丁」,然后将patch在基准点上依次应用,重建出一条时间线

可以参照上面的两张图梳理一下流程:

当我们在topic分支上执行git rebase master时,代表了我们要将我们当前的分支(topic)应用到指定的master分支上。此时topic与master的共同父节点是「E」,topic的特有commit是「A」「B」「C」,git就会按照时间点,分别创建「A」「B」「C」的patch「A'」「B'」「C'」,然后将topic分支的基准点设置为master分支的顶点「G」(「变基」了!),依次将「A'」「B'」「C'」Apply到「G」上。

现在是不是理解「rebase变基」是什么意思了!

git rebase 解决冲突

rebase产生的冲突与merge其实是相同的。但由于rebase操作会按照patch一个个打补丁上去,每打一个都有可能会产生冲突,跟merge的产生一个commit这种一次性操作不一样,解决冲突之后也就不是提交commit,而是git add <file>之后执行git rebase --continue

也就是「打一个补丁,解决一次冲突,然后继续下一个补丁」的过程。

如果你不耐烦了,也可以git rebase --abort直接不进行rebase了。

涉及操作:git rebase <branch>, git rebase --continue, git rebase --abort

关于分支处理策略的选择

上面讲了好多关于分支的东西,可能会让人困惑:分支涉及到的东西这么多,本身又复杂,多分支处理也复杂,应该怎样利用分支才好?分支合并的策略选哪一种呢?这里我说一下个人的见解:

首先,git保存的是修改这一点,可以很清楚的让我们知道代码发生了哪些改变。在这样的情况下,我们利用commit时间线就可以明确地区分哪个人在什么时间做了什么事情,也就是给了你「查看历史」与「修改历史」的权力,这对一个软件项目来说是至关重要的。

有关git多个分支的设计,其实是非常巧妙的。多个分支解决了以代码本身不同版本、不同功能或不同目的的开发方向(比如开发新功能或改bug,又暂时不想修改主要版本)开发时的代码版本管理问题,能够很方便地管理工作区的文件内容。

所以,我对多分支系统利用的理解是这样的:

  • 分支是需要充分利用的。首先要确定一个master分支,作为这个项目最终上线的版本,要保证合并到master分支上的代码都是确定无误的、测试通过的。
  • 在开发过程中,可以使用一个development分支来开发,用其部署测试环境,使这个分支成为可以随意修改的分支,增加开发的灵活度。
  • 在master或者dev分支出现问题,或者要分头行动时,为每个分支在合适的父节点上创建新的功能分支或bug分支来处理这些问题,可以保证主要的代码不会出错,就算是开发出问题,直接删除该分支便是,基本不用涉及到文件层面的修改。
  • 所以,对工作区的修改应该仅限于增加新内容和修复bug之类的操作,其他的都应该交给git去处理,保证版本树是一条路,复杂的功能删除也不用一行一行找。
  • 当某个分支的某些commit出现问题时,可以先将没有问题的部分建立分支保存起来,保证那些内容不会出问题。

有关git代码合并策略的选择,虽然git提供了非常丰富的方法,但一个team使用的方法应该大体固定成同一个,这样能避免很多混乱,然后在适当的时机使用不同的策略。在《Pro Git》这本书中总结的就很好,我摘下来总结下:

选择merge还是rebase取决于你对commit历史时间线的定义。

有两种观点:第一种认为,commit历史应该显示的是什么时候具体发生了什么事,比如分支的创建与合并过程,有哪些分支,分别合并在了什么地方等等。另一种认为,commit历史应该显示的是这个项目经历过的状态,而不考虑具体的分支构建过程。

每一个团队,每一个人都是不同的。git作为一个如此强大的工具提供给了你解决任何问题的思路,你就要考虑清楚你的团队到底需要什么。

一个两全其美的方法就是:rebase你本地的修改,push到多人环境中时用merge。

乱糟糟的时间线&&完整的分支结构 vs 清爽的一条线&&舍弃修改过程,看你团队取舍咯。



评论

666

2018-8-8 10:53

666

2018-5-7 21:26

在这里输入