Development/Tutorials/Git/Feature Development Workflow/Rebase vs Merge
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.
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
As a result of the merge pro