Merge or Rebase?

Tensions often run high in the "merge vs. rebase" debate. A big part of the problem is that there is no single right answer to this question. It will always depend on how you've set things up, and how you've decided to optimise your team's workflow.

Presentations

You've heard Emma wail about how hard SVG animations are...now you can replay the glory!

A Rebasing Workflow for Git - OSCON AMS 2015 slides

If you would like to submit changes, there is a repository on GitHub. (Animations have only been tested in Chrome on OS X. Please don't submit bug reports if it doesn't work in your browser. Sadly this deck is not meant to be a comprehenisve resource...just a support tool for when Emma gives the presentation.)

An older version of the same presentation is also available as a browser-more-compatible version on speaker deck (no animations, sadly).

Diagrams

A few of the diagrams from the presentation are also available separately.

Decision tree outlining when to choose rebase, and when to choose merge. tl;dr: if you're bringing in 'pre-approved' work from an outside source, use rebase. Otherwise, merge.

This diagram was created with Balsamiq v3. The source is available on GitHub.

Generally when we compare rebase to merge, we are referring to the shifting of a set of commits from one parent commit object, to a new one. This form of rebasing is generally used to bring a branch up-to-date with an outside source of "pre-approved" commits. For example: bringing your master branch up-to-date with changes from the project repository.

Out of date feature branch; updated by a merge strategy (new commit added), or a rebase + merge with fast forward strategy

Rebasing to bring a branch up to date. (Note: you may need to refresh the page to see the animation. It currently starts automatically instead of waiting for an onclick cue.)

Animation of commits being replayed onto an upstream branch.

A different form of rebasing, interactive rebasing, is used to alter the commits themselves, as opposed to the parent commit that a branch starts from. (Note: you may need to refresh the page to see the animation. It currently starts automatically instead of waiting for an onclick cue.)

Animation of four commits being squashed into a single commit.

Understanding the difference between these two forms of rebasing will radically improve your chances of knowing what to do with your work. Interactive rebasing is used right before sharing your work to compress a series of commits into a whole idea which represents the reasons why the work was done. Once a series of commits have been "squashed", they might be shared with others via a Pull Request, or sharing via a merge into a shared / integration branch.

Resources