重新设置基准是否是修复错误的“摘樱桃"的唯一方法? [英] Does a rebase the only way to fix a wrong cherry-pick?

问题描述

分支#1包含一个错误修复程序C1.#2分支首先进行 cherry-pick ，然后#2分支所有者意识到在C1中完成的工作实际上错误，因此他提交了正确的修订C2.

在C2中，他基本上删除了C1中的更改​​，并替换为正确的更改.当分支#1的所有者想要提取"此修复程序时，合并将不起作用.因为合并后结果C3将包含C1和C2中引入的正确修订，即C1将通过合并保留.

 因为分支#2现在根本不包含C1代码，所以合并将不起作用.基本-C1'-C2'(删除C1'更改)-C2''(添加正确的定位)<-分支#2/---- C1 --------------- C3(不会合并b/c C1将被保留)<-分支#1根据                      /\ ---- C1'---- C2 ----/<-分支#2 

Rebase之所以会这样做是因为它将丢弃C1，将跳过上游已接受的具有不同提交消息或时间戳的补丁程序."

 /---- C1 ------ xxxxx ---- C3(Rebase将丢弃C1)<-分支#1根据                      /\ ---- C1'---- C2 ---/<-分支#2 

我的问题实际上与此相关，何时您使用git rebase而不是git merge?尽管没有答案提到我的情况.所以问题是，如果我知道有人认真地选择我的提交，那么我最好将其分支重新设置基础，而不是合并?

还有其他方法可以避免(或解决)我在这里提到的问题吗?

------更新-------

我了解摘樱桃"是发生这种情况的原因.但是我几次面对这样的情况，我现在只想要一个特定的提交，但是我不希望它们分支中的其他提交.所以我不知道是否有更好的方法.

解决方案

所以问题是，如果我知道有人认真挑选我的提交，那么我最好将其分支重新设置基础，而不是合并?

是的，因为正如我之前说过的，樱桃拾取"在分支之间重复了一次提交.由于重新设置会跳过重复的提交，因此这是一个好方法.
请参阅" Git樱桃选择和数据模型完整性".进行具体说明.

还有其他方法可以避免(或解决)我在这里提到的问题吗?

如果您打算最终合并两个分支，那么在两个分支之间应该不要挑剔.仅合并或变基.

只有在不应该合并分支的情况下，才选择错误修复程序是个好主意.

The branch #1 contains a bug fix C1. The branch #2 first cherry-picked C1, then the branch #2 owner realised the work done in C1 was wrong actually, so he committed the correct fix C2.

In C2 he basically removed the change in C1, replaced with the correct change. When the branch #1 owner wants to "pick-up" the fix, the merge won't work. Because with merge the result C3 will then contain C1 and the correct fix introduced in C2, i.e. C1 will be keep by merge.

Because the branch #2 now does NOT contain C1 codes at all so merge won't work.

base -- C1'-- C2'(remove C1' change) -- C2''(add the correct fix) <--branch #2


     /---- C1---------------C3 (merge won't do b/c C1 will be kept)  <-- branch #1
base                       /
     \---- C1' ---- C2----/  <--branch #2

Rebase will do because it will discard C1, "a patch already accepted upstream with a different commit message or timestamp will be skipped".

      /---- C1------ xxxxx  ----C3 (Rebase will discard C1) <-- branch #1
base                       /
      \---- C1' ---- C2---/  <--branch #2

My question is actually related this, When do you use git rebase instead of git merge? Although none of answers mentioned my case. So the question is if I know someone cherry-pick my commit I better rebase his branch instead of merge ?

Is there other way to avoid (or fix) the problem I mentioned here ?

------ update-------

I understand cherry-pick is the reason why this happened. But I have faced the situation several times that I just want a specific commit now, I don't want other commits in their branch yet. So I don't know if there is a better way to do it.

解决方案

So the question is if I know someone cherry-pick my commit I better rebase his branch instead of merge ?

Yes because, as I stated before, a cherry-pick duplicates a commit between branches. Since a rebase skip a duplicate commit, that is a good way out.
See "Git cherry pick and datamodel integrity" for a concrete illustration.

Is there other way to avoid (or fix) the problem I mentioned here ?

If you intent to eventually merge two branches, there should be no cherry-picking between the two. Only merges or rebase.

Cherry-picking a bug-fix is a good idea only if the branches are not supposed to be merged.

这篇关于重新设置基准是否是修复错误的“摘樱桃"的唯一方法?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！