In both cases we need a starting point. In each development process with GIT there is always situation when we have more than one branch.
Besides **master** we usually have release branches, bugfix/hotfix branches and feature branches. The last one you will probably merge/rebase more often.
So, let's assume we created new feature branch **feature-1** from **master**, commit few things and we want to combine these two branches together again.
But in a meantime someone else also developed few things and now there are on **master**. Current situation looks like:
We have two options on how to do it now: merge or rebase. With both we obtain the same result. The main difference here is how this result is achieved.
In a few words: by merging our **feature-1** to **master** we are creating new commit.
Merge commit contains every change that has been made on feature branch since it branched from master.
If we have any conflicts we should resolve it during merge and after that there will be included in merge commit also.
Our flow will look like:
We can understand rebasing as a moving the base of our feature branch onto a different position - in this case we are moving base from one commit in master to two commits forward:
After that we can simply do fast-forward merge to move label **master** two commits forward - to the last commit with our feature branch label.
Now our master is also up to date:
##How not to rebase
You should remember the most important rule of rebasing: never use it on public branches.
Because of on public branches other people can work at the same time if you rebase that branch they'll lose synchronization.
So the best scenario when to use rebase is your local development, before you push your changes to public repository.
##Pros and cons
Let's start from rebase. If you decide to use rebasing your code history will be flat and readable.
Your commit messages can be clear but it needs some discipline - it's important not to pollute history with many commits for a single feature or bug fix.
It also allows manipulating a single commit very easily. From cons: rebasing can be dangerous - we mentioned that before!
Rebasing also doesn't play well with pull requests.
On the other hand merging helps to keep information about all the changes made in feature branch.
But your history can become very polluted by tons of unnecessary commits, and your git charts will be looking like rainbow:
By the way - have you tried to import your git history to Guitar Hero?
If you want a clean, simple history you should use git rebase instead of git merge.
On the other hand, if you prefer to save complete history of your project or you are operating on public branches, you should choose git merge.
Both options can now be used by you in the most appropriate situations.