Rebase From the Ground Up

Git's rebase command was one of those things that it took me forever to figure out. This was partly because I just had a lot to learn about managing branches in general, but it was also partly because it seemed like the only time people bothered to write about rebase was to say how incredibly weird and dangerous it was.

This is a damn shame, because rebase is the single most useful command I use in Git. More importantly, it's actually pretty easy to understand once you get the hang of it.

Danger, Will Robinson!

I've tried to demystify rebase in this section, and I do plan to write up a strategy for experimenting with rebase, just as I have with merge. However, I recently realized that I forgot to mention something very important about rebase: it is generally considered rude to rewrite history in public! I hope to write more on this soon.

NOTE: Many of the questions I've received so far have had to do with rebase. I have a lot more to say on this topic, but finding the time to sit down and write has been rather difficult. For now, this writeup of the workflow my team has been using for over a year may help shed some light.

End of Public Service Announcement.

With that said, I'm going to take a brief digression, because I think it's much easier to explain rebase in the context of another Git command: git cherry-pick.