背景:
一直以为 git cherry-pick <branchname> 与 git rebase <branchname>是一样效果。今天在使用 cherry-pick <branchname> 的时候,发现了一些异常,与之前的认知不同。于是就去了解了一下这两者的区别。
cherry-pick <branchname> 与 rebase <branchname>
git cherry-pick [xx]; 这里的 [xx] 一般都是一个 commit id,但是这里写成一个 branch name 也可以,git 支持这种表达方式。这种支持其实是一个误导,会误导使用者以为这样跟 rebase <branchName> 是一样的效果。
先给出结论:
cherry-pick <branchname>的使用,实际上是把这个<branchname>的最后一笔提交pick过来了。假设最后这个branchName上面的最后一笔提交的commmit id是447561a,那么这个cherry-pick <branchname>准确表达是cherry-pick 447561a; 两者的作用完全一样,没任何区别;rebase <branchName>的使用,就不只是把最后一笔pick过来了,它会先找当前分支与目标分支的一个公共的基点,然后从目标分支的这个commit id开始到目标分支的最后一笔commit id(不包含公共的那个commit id),一笔一笔的pick进当前的分支;rebase会把这些目标分支的这些提交插入到当前分支的公共基点上,而不是你目标分支的最新的提交上; 而cherry-pick总是会将这些提交插入到你当前分支的最新的节点上。
ps: git cherry-pick ..<branchName> 作用与git rebase <branch name>类似,也是从公共基点开始,直到目标分支的最后一笔,把目标分支的这些提交全部pick过来。但是区别就是上面 第3点所说的,开始插入的位置不同。cp 总是直接插入到当前分支的最后一个节点之上;而rebase是从公共基点之上开始插入。(当然,如果你当前分支的最后一笔实际上就是公共基点,那么两者的效果是一样的。)
参考文档:
本文揭示了git cherry-pick和git rebase命令在应用中的实际效果差异,cherry-pick捡取指定分支的最新提交,而rebase则基于公共基点逐步合并。理解两者的关键在于操作位置和合并方式。
3141

被折叠的 条评论
为什么被折叠?



