What does GIT --rebase do ?

Tahir, In explanation to your question about rebase: I wouldn't say that it's suggested to 'never do a rebase', as in the professional world you sometimes have to.

Pro's to Rebase:

• Simplifies your history
• Is the most intuitive and clutter-free way to combine commits from multiple developers in a shared branch

Con's to Rebase:

• Slightly more complex, especially under conflict conditions. Each commit is rebased in order, and a conflict will interrupt the process of rebasing multiple commits. With a conflict, you have to resolve the conflict in order to continue the rebase.
• Rewriting of history has ramifications if you’ve previously pushed those commits elsewhere. In Mercurial, you simply cannot push commits that you later intend to rebase, because anyone pulling from the remote will get them. In Git, you may push commits you may want to rebase later (as a backup) but only if it’s to a remote branch that only you use. If anyone else checks out that branch and you later rebase it, it’s going to get very confusing.

Looking at the above pros/cons, it’s clear that it’s generally not a case of choosing between one or the other, but more a case of using each at the appropriate times.

To explore this further, let’s say you work in a development team with many committers, and that your team uses both shared branches as well as personal feature branches.

With shared branches, several people commit to the same branch, and they find that when pushing, they get an error indicating that someone else has pushed first. In this case, I would always recommend the ‘Pull with rebase’ approach. In other words, you’ll be pulling down other people’s changes and immediately rebasing your commits on top of these latest changes, allowing you to push the combined result back as a linear history. It’s important to note that your commits must not have been shared with others yet.

By taking this approach, when developing in parallel on a shared branch, you and your colleagues can still create a linear history, which is much simpler to read than if each member merges whenever some commits are built in parallel.

The only time you shouldn’t rebase and should merge instead is if you’ve shared your outstanding commits already with someone else via another mechanism, e.g. you’ve pushed them to another public repository, or submitted a patch or pull request somewhere.

However, as a lone developer, you won't be using rebase really at all. Unless you dev on multiple machines, make some changes to done and forget that you've already done some code on the other and pushed it to your remote repository. In this case, you would rebase to bring the remote code into your current code so you can then run your push.