Both rebase and merge commands are used to integrate changes from one branch to another but in a different manner.
As seen in the below two images, suppose you have commits (this is before merge/rebase). After the merge, you will get the result as a combination of commits. It binds together the histories of both the branches and creates a new ‘merge commit’ in the feature branch.
On the other hand, rebase will move the whole feature branch to begin at the tip of the master branch.
300w" data-ll-status="loaded" style="border-style:initial; border-width:0px; height:auto; max-width:100%; width:525px" class="alignnone lazyloaded size-full wp-image-115468">
Commits will look like:
300w" data-ll-status="loaded" style="border-style:initial; border-width:0px; height:auto; max-width:100%; width:617px" class="alignnone lazyloaded size-full wp-image-115469">
Rebasing is not recommended for public branches as it creates inconsistent repositories. However, rebasing is a good option for private branches/individual developers. It is not very suitable for branch-per-feature mode. But if you have a branch-per-developer model, then rebasing is of no harm.
Also, rebase is a destructive operation, so your development team should be skilled enough to apply it correctly. Otherwise, committed work can be lost.
Furthermore, reverting a merge is easier than reverting a rebase. So, if you know that there can be possibilities for revert required, then you should use the merge.
Merge perseveres history as it is whereas rebase rewrites history. Thus, if you want to see the history completely as it occurred then you should use merge.