Development/Tutorials/Git/Feature Development Workflow/Rebase vs Merge

Warning

This page refers to a draft policy which is still to be agreed and implemented. Please take it as a reference for a work in progress project.

Rebasing and merging are two different strategies for synchronizing changesets between two or more branches. Besides aiming for the same purpose, they are completely different one from the other.

Rebase and merge explained

Let's try to explain what each method does. We assume of having a branch my-feature we want to synchronize with the master branch.

How rebase works

Suppose you want to rebase my-feature onto master. The rebase process finds which commits in my-feature are not present in master, and cherry-picks them. Afterwards, your branch is reset to the HEAD of the branch you want to rebase on (master in this case), and commits are sequentially applied afterwards.

This means that now all your commits sit on top of the other branch's HEAD, which is now a base for your branch.

It has the advantage of keeping a clean, linear history. It also does not create merge commits (as no merge is actually happening).

It has the disadvantage of rewriting commit hashes, and subsequently rewrite history, making it unsuitable for tracking remote branches.

In addition, rebase can be used for editing, amending, squashing and deleting commits.

How merge works

When merging a branch into another one, the history of the two branches intersect. This means that the history order will be preserved in a chronological way: the commits will be ordered by date.

A merge can be either fast-forward or not: fast-forward means that no merging process has to be done: a fast-forward merge's result looks exactly the same as a rebase result (even though the process still remains very different).

If a merge is non fast-forward, the history of the two branches must be intersected. As a result of the process, an additional commit is added to the repository, carrying the merge result.

It has the advantage of keeping history consistent (commit hashes are not altered) and preserving chronological history.

It has the disadvantage of making it harder to track a branch's changes, and scattering a branch's commits throughout the repository

Merge is also able to use different merging strategies, and squash the merge in a single commit (strongly discouraged).

Merge and Rebase cheat sheet

Merge and rebase have a very similar syntax, and their usage is quite similar. The most popular and used command related to merge and rebase is git pull.

git pull is nothing but a combination of git fetch and git merge. It fetches changes from the remote branch tracked by the local branch you have currently checked out, and merges them afterwards.

If git pull had ever generated merge commit messages, now you know why - and you should know how to prevent that. git pull has a --rebase option, which instead of fetching+merging does fetching+rebasing. It is good practice, as it will be explained afterwards, to always use git pull --rebase.

The bare rebase and merge commands accept as a compulsory argument the name of the branch you want to synchronize with. So, in your local checkout of the branch you want to synchronize, issue:

git rebase master

or

git merge master

As easy as that goes.

In particular, merge has a --no-ff options, which makes fast-forward merges behave as if they were non fast-forward, e.g.: generating a merge commit.