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?
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