Development/Tutorials/Git/Feature Development Workflow/Rebase vs Merge: Difference between revisions

From KDE TechBase
(Created page with '{{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 a...')
 
No edit summary
Line 15: Line 15:
It has the disadvantage of rewriting commit hashes, and subsequently rewrite history, making it unsuitable for tracking remote branches.
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====
====How merge works====
Line 27: Line 28:
It has the disadvantage of making it harder to track a branch's changes, and scattering a branch's commits throughout the repository
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''.


As a result of the merge pro
''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.

Revision as of 23:16, 27 April 2011

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.