4

I was exploring the possible merge strategies on Bitbucket Server and one strategy caught my eye: "Rebase and merge" rebase + merge --no-ff

I understand that most of the debate about merge strategies revolves around rebase vs merge. This merge strategy seems to be rebase and merge. Is this correct? What advantages would this bring as opposed to only rebase or only merge?

Kkarsko
  • 103
  • 1
  • 7

2 Answers2

12

The "rebase and merge" strategy is usually what people mean by "rebase". It just also indicates what happens next. When you use --no-ff, it makes a merge commit. Without it, you get a fast-forward so both refs would point to the same commit and it hides the fact that you had branched at all.

Merge B onto A:

A  *---*              A  *---*---*
    \       merge ->      \     /
B    *---*            B    *---*

Rebase B onto A:

A  *---*              A  *---*
    \      rebase ->          \
B    *---*            B        *---*

Rebase and merge (--no-ff) B onto A:

A  *---*              A  *---*                  A  *---*-------*
    \      rebase ->          \       merge ->          \     /
B    *---*            B        *---*   --no-ff  B        *---*

Rebase and merge (--ff) B onto A:

A  *---*              A  *---*                  A,B  *---*---*---*
    \      rebase ->          \       merge ->
B    *---*            B        *---*   --ff
Ian MacDonald
  • 13,472
  • 2
  • 30
  • 51
  • 2
    So rebase with `--no-ff` allows me to have a (somewhat) cleaner history without losing the traceability branches provide? I have always understood the "rebase" strategy to mean your last example. This clears thing up – Kkarsko Jan 31 '19 at 14:55
  • 1
    You have understood that correctly. I'm glad I could help. :) – Ian MacDonald Jan 31 '19 at 15:09
0

Bitbucket Server documentation says this for Rebase, merge (rebase + merge --no-ff) AND Rebase, fast-forward (rebase + merge --ff-only) merge strategies.

"The PR branch is not modified by this operation"

As per this statement, in your example the commitSHA for the commits in branch B would remain unchanged. Bitbucket would assign new commitSHA for the same commits when applied in branch A.

prichard
  • 1