Is merge without conflicts equivalent to rebase without conflicts?

Is it correct that a git merge will succeed with no conflicts if and only if the corresponding git rebase will succeed with no conflicts?

  • Duplicate commits in git branch after rebase / pull request workflow on bitbucket
  • GIT creating extraneous ~HEAD files during rebase
  • Why git rebase creates conflicts, but git rebase -i does not?
  • How to bring back my changes from some commits to the index?
  • How to merge a commit with the next commit in git interactive rebase?
  • git rebase, keeping track of 'local' and 'remote'
  • not sure what to use rebase or merge?
  • Git merge to a old point in history
  • One Solution collect form web for “Is merge without conflicts equivalent to rebase without conflicts?”

    No, and in fact there’s a trivial case where merge works fine but rebase doesn’t:

    ...--o--A   <-- mainline
           B--C--!C   <-- branch

    where C is a commit that conflicts with A, and !C is its reversion. Merging branch back into mainline is equivalent in source-tree effect to merging commit B back into mainline, while rebasing copies both C (which conflicts with A) and then !C (which when being resolved, also conflicts with A).

    Of course, you can rebase interactively and simply drop both C and !C in this case, but in more complex chains, you can see how a commit might conflict with A but a subsequent commit might effectively resolve that conflict “in advance”, so that merging the tip of the branch back into the mainline has no conflicts.

    Git Baby is a git and github fan, let's start git clone.