I'm still reading Kent Beck's new book (not quite a book but something not far off) called Tidy First?. Being a late subscriber and all there is a lot to read. And now I stumbled over a chapter on untangling behaviour changes from tidyings. The idea is, and I agree fully, that we don't want to mix changes in behaviour and changes in structure. But we all now how hard that can be. We start to do some behaviour change just to realise we just made a bunch of small structural changes to allow for the original change.

Then comes the question, how do we untangle the two? Or do we even try? Naturally there are situations where it's worth untangling, just as there are to not bother. But most of the time we'd like to not have to do either.

Kent Beck argues, and I think he's right, that if you end up here you're better off starting from scratch. This gives you an opportunity to revisit all your decisions which is usually a really good idea. You are after all wiser now than you were before (even if just an hour has passed).

I have successfully used another technique though. Given a behaviour change I check out a branch that I use to sketch it, a scratch branch. Scratch branches are never to be main lined.

On this branch I start making the behaviour change. As soon as I find a reason to tidy I do this on trunk (in git speak that's main). If you need PRs and all that you make a PR for the tidying. Once your tidying has been mainlined and preferably released without issue you merge it back into your scratch branch.

Once you have completed the behaviour change in the scratch branch you can be reasonably sure that trunk is tidy enough that you can now do your behaviour change on trunk with little effort.

I hope you find this useful.