Git Merging Vs Rebasing

When I first started using git I would always merge the code with a:

git merge 'branch-to-be-merge'

However recently I discovered a second way by rebasing, which is

git rebase master

The two commands go about accomplishing the same task, but have different approaches in how it goes about it underneath the hood.

For most of my career in using git, I would have just merge my code back into a branch like 'testing' or 'qa' branch. I didn't really think much about it afer that, until I had to go recently look at it underneath the hood of what git does when you do a git merge. Merging is a non-destructive operation, which is nice, since it does not change the history of the branches. When doing a 'git merge' it ties together the histories of both branches. As a result, both branches history aren't changed, some will argue this isn't desired and would rather have a cleaner branch history.

This is where rebasing comes in. Having all the history of multiple branches on a master branch might not be desired and can create a lot of noises for other developers. By using 'git rebase', it moves the entire feature branch to begin on the tip of the master branch, effectively incorporating all of the new commits in master. This makes the project history cleaner.

Both two ways accomplish the same task, but underneath the hood is how it keeps the branches history. I don't have a prefer way, since I still in general like merging my code to keep all the history, but on a bigger team I can see the need to rebase.