What sets Git apart from other version control systems is the amount of control it provides to its users. If you’re used to Subversion or Mercurial, where history is permanent and immutable, you’ll probably have two reactions upon discovering the rebase command: horror that such a thing even exists, and confusion as to why anyone would want it in the first place.
Why do I want this?
If you’ve spent much time working on software, you’ve probably been in at least one of these situations:
- While working on a feature, you find that you’ve written a utility that’s useful in other parts of the system, but it’s tangled up with your feature.
- You forgot to delete a file, and a two-line bug fix got spread across 3 commits.
- You had to make a commit that only undoes some changes introduced in an older commit.
- You started working on a bugfix, which later turned into a deploy-it-yesterday hotfix.
Rebase can help you solve these problems, or avoid them entirely. It’s easiest to think about this by seeing it in action. Let’s look at a couple of examples.