Git Interactive Rebasing – It's a Must-Have!

I’ve been having discussions with friends & colleagues of late about Git’s interactive rebasing feature. 

If you’re not familiar with it, interactive rebasing is a feature unique to Git, which allows a developer to manipulate their commit history in a variety of ways, including:

• reordering commits
• changing commit messages
• merging multiple commits together

It supports this – even if the work’s been pushed to remote repositories. For me – it’s a standout feature!

Not Everyone Agrees

From time to time I see people take issue with it, believing that it has no place in a version control system. I completely disagree, with one strict caveat: don’t rewrite history – EVER!

This might sound a little counter to what I’ve said so far. What I mean is, change your history around to your heart’s content – but never after it’s pushed. That’s akin to ripping the rug out from under your young child, who’s just taken her first steps. A dramatic analogy perhaps, but it indicates the importance of what is and is not acceptable.

Imagine it happened to you. You were working on a feature then pulled code only to see history all rewritten. What would your feelings be of the colleague who did it? Not too positive I’m sure. There must be consistency.

Why It’s Needed

It’s been oft said:

Computers do really well at steps which need to be repeated the same way, repeatedly – but humans don’t.

That’s the key reason for me for its inclusion. Despite our best efforts, discipline,  attention to detail, we make mistakes, we overlook things, forget, we can be over-worked and stressed. As a result, we can be inconsistent, forget steps we’ve done a thousand times, or fail to see the glaringly obvious.

Source code management systems that don’t offer this flexibility, consequently, necessitate so high a level of discipline as to be unrealistic. It’s not to say that excellent apps can’t be written with them; they can, are and have been for many years.

But git’s interactive rebasing offers an approach more akin to how we, as people, operate. It is forgiving of our mistakes, allowing us to fix or tidy up our work before sending code out into the world.

A Practical Example

You’ve been working away all day and a number of files were involved. But not all the changes related to the same task.

You work through the changes, committing the relevant hunks and commit, with “A Note About Git Commit Messages” – a proper commit message. You do the same for the next change and commit again. Then, when preparing for the last change, you spot a file, a hunk, a changed line, which belongs to the first change.

Now yes, you could make another commit and when someone pulled your changes, they’d have everything. But I’m a firm believer in work being atomic, being all-inclusive, being self-contained. They shouldn’t be interspersed through multiple commits.

Because of this, it’s a personal rule of mine, before pushing changes, to always give my work a once over. I review all commit messages and commit contents asking myself these questions:

• Is the commit summary clear  & concise?
• Is the work in the commit to do with one task?
• Is there sufficient information in the longer commit description?
• Are the commits in the right, logical, order?

If I can answer yes to all of these questions, then I’m happy to push the work out.

Winding up

This is why git interactive rebasing is a key feature and should be available to all developers. We aren’t perfect creatures. But we can use tools that forgive our mistakes and help us bridge the gap. Tell me what you think. Rant, critique, find fault. But share your thoughts.

Related Links

• Git: Rewriting History – http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages
• A Note About Good Commit Messages: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html