为什么当我使用git rebase时，同样的冲突再次出现？

问题描述

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

这是我们的分支情况：

   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:
Is git rebase suitable for our situtation? Or is rebase only good for pulling in few (1 or 2) changes?
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:
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.
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:
Here you can find more details on how to deal with conflicts using git rerere.
                        
这篇关于为什么当我使用git rebase时，同样的冲突再次出现？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！