Git Merge vs. Rebase

"Merge creates a new “merge commit” in the target branch that ties together the histories of both branches. Merging is nice because it’s a non-destructive operation. The existing branches are not changed in any way.
On the other hand, the target branch will have an extraneous merge commit every time you merge. 
Rebase moves the entire source branch to begin on the tip of the target branch, effectively incorporating all of the new commits in target. 
But, instead of using a merge commit, rebasing re-writes the project history by creating brand new commits for each commit in the original branch.
You get a much cleaner project history and it eliminates the unnecessary merge commits.
But, there are two trade-offs for this pristine commit history: safety and traceability.
The Golden Rule of Rebasing:
The golden rule of git rebase is to never use it on public branches.
Rebase moves all of the commits in source onto the tip of target. The problem is that this only happened in your repository. 
All of the other developers are still working with the original source.
Since rebasing results in brand new commits, Git will think that your source branch’s history has diverged from everybody else’s. 
So, before you run git rebase, always ask yourself, “Is anyone else looking at this branch?”
From : https://www.atlassian.com/git/tutorials/merging-vs-rebasing