Git: Dealing with unrelated changes whilst working on a feature branch

How many times have you been working in a Git feature branch, and come across something in code that you want to change, but isn't related to the feature your on? Perhaps a code tidyup, or fixing some unrelated warnings?

What do you do?

The long way

You could do it the very long way and interrupt your workflow... Stash/commit all your current changes; switch to the main branch; make these unrelated changes; commit them; switch back to your feature branch; rebase your feature branch back onto the main branch; unstash your changes if you stashed them in step 1; try to remember what you were doing before all this started.

The messy history way

Or you could just include it in your feature branch, and leave it as that. The downside of this, is that this change is then part of your feature branch, not its own dedicated commit in your main branch.

A better way

A better option is to tidy up afterwards. This achieves the same as option 1, but doesn't interrupt your workflow at the time of doing the work...

1. Just commit the unrelated changes into your feature branch. Make sure they're in dedicated commits.
2. Carry on with your feature.
3. Once feature is complete - switch to the main branch, and cherry-pick any unrelated commits (ie. commits that shouldn't be part of your feature branch). At this point, those commits will be duplicated in both branches.
4. Rebase your feature branch onto the main branch. This will remove those duplicate commits from your feature branch.

This will leave you with a nice clean graph where your unrelated changes are on your main branch, and then your feature branch will branch off after those unrelated commits.

In step 4 - the rebase will remove those duplicate commits from your feature branch because a rebase is just a "replay" of commits. It's "replaying" your feature branch commits on top of the main branch commits. So when it tries to replay the duplicate commits, there are no changes to replay because those changes are already in the code - so those duplicate commits will get discarded.

If all commits have to go in a feature branch...

Your company's Git policy might be that all changes have to come from feature branches (perhaps you use PRs for everything). If this is the case, you can create your new unrelated feature branch in step 3 and do exactly the same against this branch rather than the main branch.

Summary

The reason behind this blog post is that for a long time, I've been doing the first option (ie. the long way). I'm fairly quick with Git, so it didn't take that long, but it was still more of an interruption to my workflow than I'd have liked. I very recently realised that it's much faster to tidy up afterwards with the cherry-pick and rebase technique I describe in this post. At that point, I no longer have my head in the feature I'm working on. And also if there are multiple unrelated changes/commits in the feature branch, then they'll all get tidied up in one go as part of the same cherry-pick/rebase commands.

If you're a Git user, but haven't got your head around rebasing - definitely spend time trying to understand it. It's not as complicated as it sounds, and once you get it, it's actually quite simple. And is one of the most powerful features of Git.