为什么当我使用git rebase时，同样的冲突再次出现？ [英] Why does the same conflict reappear when I use git rebase?

问题描述

我已经阅读了关于git merge和git rebase的相关问题，但我仍然不能完全理解底层的情况。

这是我们的分支情况：

  MASTER ------------------------ 
 \\ 
 \\ ----特征B --- 
 \\ 
 \ -----特征A ---- ------ \ ---特征A + B 
  

我们有2个特征分支源于不同时间的主人，现在我们要结合这两个分支。我们希望遵循第一次rebase然后合并练习，但是当我们将feature A重新设置为feature B时，会发生冲突。这是预料之中的，因为这两个功能（和主控）在相同的区域都有变化。但奇怪的是，同样的冲突继续在 git rebase --continue 后重新出现。这让我们感到疯狂，所以我们最终放弃了rebase，并使用 git merge 。事实证明，冲突实际上很容易解决。

我的问题有两方面：

1. 是否适合我们的位置？ git rebase 或者是rebase只适用于少量（1或2次）更改？


2. 引发相同冲突再次出现的背后是什么？我的理解是 rebase 一次解决一个冲突，但是通过比较哪个提交什么？
   

SO上的相关帖子：

• 为什么我必须反复解决同一个冲突？


• 如何当git rebasing很多提交时，防止大量的git冲突？ \


• git rebase一次又一次解决冲突？

解决方案

是否适合您的情况？

基于以下事实：特征A 和特征B 似乎是共享分支，我会说 no 。

重新绑定是一种合并分支而不合并提交的方法。承诺有两个或两个以上的父母）使其显示为线性历史记录。它最好用于合并本地分支，这是仅存在于本地存储库中并且尚未发布给其他人的分支。为什么？由于至少有两个原因：
$ b $ ol

重新分配会更改提交ID（即 SHA-1 元数据的散列值）。这意味着，一旦将重新发布的提交推送到共享分支，它们将完全呈现给任何在本地回购中获取它们的人的新提交，即使它们仍包含相同的变化。现在，如果有人在此期间添加了新的提交，他们将不得不移动它们。这会造成不必要的混淆。

当您合并公共分支时，您经常希望将这些合并提交以便能够跟踪跨分支提交的提交方式。这些信息与重新绑定一起丢失。

发生了什么？

只是一个常规合并。不同之处在于 git rebase 从共同父项开始，一次合并一个一次提交。 git merge 将两个提交（包括它们的整个更改集合为一个操作）合并，因此您只需解决一次冲突。

更新：解决重复冲突

正如@Jubobs在评论中指出的那样，Git确实有一个自动解决方案来解决多次发生的冲突： git rerere 或重新使用记录的分辨率 / em>。

在您的配置文件（ rerere.enabled true rerere $ c>），每次发生合并冲突时，Git都会在合并之前和之后记录冲突文件的状态。下一次发生同样的冲突 - 在合并的两边都有一个涉及完全相同的行的冲突 - Git将自动应用它先前记录的相同分辨率。它也会让你知道它在合并输出：

lockquote
CONFLICT（内容）合并冲突'somefile'
$


在这里你可以找到 git rerere 处理冲突的详细信息。

b $ b

I have read relevant questions about git merge and git rebase on SO, but I still cannot fully understand what is happening under the hood.

Here is our branching situation:

MASTER------------------------
        \        \
         \        \----Feature B---
          \                        \
           \-----Feature A----------\---Feature A+B

We have 2 feature branches that stem from master at different time, now we want to combine the 2 branches. We want to follow the first rebase then merge practice, but when we rebase Feature A to Feature B, we get conflicts. That's expected, because both features (and master) have changes in the same areas. But the strange thing is that the same conflict keep reappearing after git rebase --continue. This drives us crazy, so we end up aborting the rebase, and use git merge. It turns out the conflicts are actually easy to resolve.

My question is two-fold:

1. Is git rebase suitable for our situtation? Or is rebase only good for pulling in few (1 or 2) changes?
2. What is happening under the hood that causes the same conflict to reappear again and again? My understanding is rebase resolve conflicts one at a time, but by comparing which commit to what?

Relavant posts on SO:

• Why do I have to resolve the same conflict over and over?
• How to prevent lot of git conflicts when git rebasing lot of commits?\
• git rebase resolve conflicts again and again?

解决方案

Is rebase suitable for your situation?

Based on the fact that Feature A and Feature B seem to be shared branches, I'd say no.

Rebasing is a way to merge branches without having merge commits (i.e. commits that have two or more parents) making it appear as a linear history. It's best used to merge local branches, that is branches that only exist in your local repository and haven't been published to other people. Why? Because of at least two reasons:

1. Rebasing changes the commit IDs (i.e. the SHA-1 hashes of their metadata). This means that once you push the rebased commits to the shared branch, they will appear as completely new commits to anyone that fetches them on their local repo, even if they still contain the same changes. Now, if someone has added new commits on top of the old ones in the meantime, they will have to move them. This creates unnecessary confusion.

2. When you merge public branches you often want to have those merge commits in order to be able to track how commits moved across branches. That information is lost with rebasing.

What's happening under the hood?

Just a regular merge. The difference is that git rebase merges one commit at a time on top of the previous one starting from the common parent. git merge merges two commits – with their entire set of changes – as a single operation, so you only have to resolve the conflicts once.

Update: Resolving recurring conflicts

As @Jubobs pointed out in the comments, Git does have an automated solution for resolving conflicts that occur multiple times: git rerere, or "reuse recorded resolution".

After you enable rerere in your configuration file (rerere.enabled true) every time a merge conflict occurs, Git will record the state of the conflicting files before and after you merge them. Next time the same conflict occurs – a conflict involving the exact same lines on both sides of the merge – Git will automatically apply the same resolution it had recorded previously. It will also let you know about it in the merge output:

CONFLICT (content): Merge conflict in 'somefile'
Resolved 'somefile' using previous resolution.

Here you can find more details on how to deal with conflicts using git rerere.

这篇关于为什么当我使用git rebase时，同样的冲突再次出现？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！