git rebase vs git cherry-pick的独立分支 [英] git rebase vs git cherry-pick of detached branch

查看:336
本文介绍了git rebase vs git cherry-pick的独立分支的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有两个分行:


  1. master

  2. tmp

tmp 分支被分离

我需要把 tmp 分支位于 master 之上,解决冲突优先级 tmp



当我做时

  git checkout tmp 
git rebase --strategy = recursive -X他们的主人

我得到错误
首先,回头重播你的工作

 致命:无法解析对象'0a722ac51071ecb4d00b1ef45384aac227b942a0 ^'
未知退出码(128 )from git-merge-recursive 0a722ac51071ecb4d00b1ef45384aac227b942a0 ^ - HEAD 0a722ac51071ecb4d00b1ef45384aac227b942a0

当我做

  git checkout tmp 
git cherry-pick --strategy =递归-X他们的0a722ac..384144a

工作正常



与rebase有什么不同或者我该怎么做? 你得到 rebase 错误,因为您没有明确地告诉它开始的是哪个提交,并且因为您明确地告诉它要调用合并,所以它寻找合并基 1 。告诉它不要打扰,只需要整个分支,指定 - root

  git checkout tmp 
git rebase --strategy = recursive -X他们 - root master

您的 cherry-pick 没有达到您认为的效果。 .. 构造的意思是不是左边的提交或任何可以访问的东西......,特别是在这种情况下,它的意思是不是0a722ac。它没有选择整个分支。由于樱桃挑选是为期望单次提交而构建的,所以您必须明确指定一个范围,此处执行此操作的方法是将排除集缺省设置为 HEAD (自 HEAD tmp 没有任何共同之处,不会被排除在外):

  git checkout master 
git cherry-pick --strategy = recursive -X they're ..tmp

范围指定中的不对称只是两个命令最常见用法的结果:rebase适用于整个当前分支,而cherry-pick通常用于一个或多个单提交。






1 不是非常智能,与他们自己的复杂的合并历史批发(线性整支分行工作正常)会痒,所以很少有人我怀疑你会鼓起很多渴望帮助划伤它。


I have two branches:

  1. master
  2. tmp

tmp branch is detached
I need to put tmp branch on top of master with resolving conflicts in priority of tmp

When I do

git checkout tmp
git rebase --strategy=recursive -X theirs master

I got error First, rewinding head to replay your work on top of it...

fatal: Could not parse object '0a722ac51071ecb4d00b1ef45384aac227b942a0^'  
Unknown exit code (128) from command: git-merge-recursive 0a722ac51071ecb4d00b1ef45384aac227b942a0^ -- HEAD 0a722ac51071ecb4d00b1ef45384aac227b942a0  

When I do

git checkout tmp
git cherry-pick --strategy=recursive -X theirs 0a722ac..384144a 

Works fine

What the difference or how can I do the same with rebase ?

解决方案

You're getting the rebase error because you didn't explicitly tell it which commit to start with, and because you did explicitly tell it to invoke merge, it went looking for the merge base1. To tell it not to bother, to just take the whole branch, specify --root:

git checkout tmp
git rebase --strategy=recursive -X theirs --root master

Your cherry-pick didn't do what you think it did. The .. construct means "not the commit on the left or anything reachable from it ...", in particular, in this case, it means "not 0a722ac". It didn't cherry-pick the whole branch. Since cherry-pick is built to expect single commits, you do have to explicitly specify a range, the way to do it here is to simply default the exclusion set to HEAD (since HEAD has nothing in common with tmp, nothing will be excluded):

git checkout master
git cherry-pick --strategy=recursive -X theirs  ..tmp

The asymmetry in the range specification is just a consequence of the two commands' most common usage: rebase applies to the whole of the current branch, while cherry-pick is generally used for one or more single commits..


1 not very intelligently, but rebasing branches with their own complicated merge history wholesale (linear whole-branch rebase works fine) is going to itch so very few people I doubt you'll be able to drum up much desire to help scratch it.

这篇关于git rebase vs git cherry-pick的独立分支的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆