在使用rebase -ir处理之前不相关的提交之后,如何重做合并冲突解决方案? [英] How to redo merge conflict resolution after working with unrelated commits that came before it with rebase -ir?

查看:56
本文介绍了在使用rebase -ir处理之前不相关的提交之后,如何重做合并冲突解决方案?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

举个简单的例子,假设我们有一个回购协议,其中在文件 a 中添加了错误的行.

For a simple example, let's say we have a repo where an incorrect line was added to a file a.

$ git init 
Initialized empty Git repository in /someplace/.git/
$ echo "a1\nb2" > a
$ echo b1 > b    
$ git add .
$ git commit -m init  
[master (root-commit) 917f3b9] init
 2 files changed, 3 insertions(+)
 create mode 100644 a
 create mode 100644 b

分支 master 然后派生出新的分支 f .

The branch master then forks off new branch f.

$ git branch f

然后在 master 中,将另一行添加到错误的文件中.

In master, we then add another line to the incorrect file.

$ echo b3 >> a
$ git commit -am 'added b3 to a' 
[master e44bc9f] added b3 to a
 1 file changed, 1 insertion(+)

在分支 f 中,我们做一些无关的事情,提交它,

In branch f, we do something unrelated, commit it,

$ git checkout f
$ echo c1 > c 
$ git add .
$ git commit -m "added c"
  1 label onto
[f 7cb63b2] added c
 1 file changed, 1 insertion(+)
 create mode 100644 c

然后我们将错误地放置在文件a中的行移动到文件b.

then we move the line incorrectly placed in file a to file b.

$ echo b2 >> b
$ sed -i '/b2/d' a
$ git commit -am "moved b2 to where it really belongs"
[f 32cee76] moved b2 to where it really belongs
 2 files changed, 1 insertion(+), 1 deletion(-)

然后我们尝试将 master 合并到 f ,但是遇到了冲突,即 master f 删除了第一个.

Then we try to merge master to f but are met with the conflict that master added another incorrect line while f removed the first.

$ git merge master 
Auto-merging a
CONFLICT (content): Merge conflict in a
Automatic merge failed; fix conflicts and then commit the result.
$ cat a
a1
<<<<<<< HEAD
=======
b2
b3
>>>>>>> master

为解决冲突,我们将第二行错误的行移至正确的文件,然后提交合并.

To resolve the conflict, we move the second incorrect line to the correct file, and commit the merge.

$ echo b3 >> b
$ sed -i '/HEAD/,$d' a
$ git commit -a --no-edit 
[f 28d8543] Merge branch 'master' into f

然后,我们意识到有关 c 的提交不应在此分支中,因此我们用 rebase -ir 删除"了它,并且遇到了与以下相同的冲突较早.

Then, we realize the commit about c should not be in this branch, so we "remove" it with rebase -ir and are met with the same conflict as earlier.

$ git rebase -ir $(git merge-base master @) # remove the commit about c
Auto-merging a
CONFLICT (content): Merge conflict in a
Could not apply 28d8543... onto # Merge branch 'master' into f
$ cat a
a1
<<<<<<< HEAD
=======
b2
b3
>>>>>>> refs/rewritten/onto

那么,考虑到没有添加到冲突中的 b 中添加的内容,重做以前的分辨率的最简单,最有效和通用的解决方案是什么?

So, what's the simplest, most effective and versatile solution here to redo the previous resolution, taking into account what was added to b which does not appear in the conflict?

推荐答案

有一个git实用程序,用于记录解决冲突的方式,以便您稍后重播.它称为 git rerere .

There is a git utility for recording how a conflict is resolved so that you can replay it later. It's called git rerere.

这实际上是针对特定用例的-由于该用例是基于我不同意的假设而进行的,因此我几乎从不使用 git rerere .

It's really meant for a specific use case - and as that use case is predicated on assumptions I disagree with, I almost never use git rerere.

我还要说的是,在良好的工作流程中,您所描述的场景应该很少见,甚至不存在,因此我个人不会立即使用 rerere 来记录每个冲突的解决方案以后我会再次需要它.

I would also say that with a good workflow, the scenario you describe should be infrequent if not nonexistent, so I personally wouldn't start using rerere to record every conflict resolution just on the off chance that I'll need it again later.

但是...因为这是您提出的问题, git rerere 可能是答案".

But... as that's the question you've presented, git rerere is probably the "answer'.

这篇关于在使用rebase -ir处理之前不相关的提交之后,如何重做合并冲突解决方案?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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