好,我们回到了第一次合并前的时间点,并且我们想要将 master 中的更改集成到 greet 分支。
$ go greet
Switched to branch 'greet'
$
$ git rebase master
Applying: hello uses Greeter
Applying: updated Rakefile
$
$ git hist
* 2fae0b2 2013-04-13 | Updated Rakefile (HEAD, greet) [Jim Weirich]
* 1c23048 2013-04-13 | Hello uses Greeter [Jim Weirich]
* 96ee164 2013-04-13 | Added a Rakefile. [Jim Weirich]
* 0f36766 2013-04-13 | Moved hello.rb to lib [Jim Weirich]
* eb30103 2013-04-13 | Add an author/email comment [Jim Weirich]
* 1f7ec5e 2013-04-13 | Added a comment (v1) [Jim Weirich]
* 582495a 2013-04-13 | Added a default value (v1-beta) [Jim Weirich]
* 323e28d 2013-04-13 | Using ARGV [Jim Weirich]
变基的最终结果与合并很相似。greet 分支现在包含它的全部 更改以及来自 master 分支中的所有更改。然而,提交树却十 分不同。greet 分支的提交树已被重写,以致 master 分支成 为了其提交历史的一部分。这使提交链更加线性,且更易阅读。
何时变基,何时合并?
如果是公开且与其他人共享的分支,那么重写公开的共享分支 将会搞砸团队中的其他会员。
根据上述准则,我会针对短期生命的本地分支使用变基,而对 公开仓库的分支使用合并。