[conradludgate]

My recommendation: don't treat the development process as the final draft.

Write everything in one go, and then afterwards rework the commits to tell the story you want to tell. This does require getting very comfortable with git rebase, but I can absolutely recommend it.

Using this technique, I've managed to merge several large refactors lately with no issues, and the reviewers didn't hate me.

[kiitos]

holy moly absolutely not

git is a means, not an end

code review is about the code as a unit whole, not the steps along the way!

[conradludgate]

Hard disagree. I've found this way of working benefits both me and my colleagues.

I'm able to work on long lived branches without getting into conflict hell because when I rebase, I'm only dealing with small conflicts.

I'm able to slim down initially large changes into smaller total diffs because I realised one change wasn't actually necessary, but only because I took the time to reflect on the code and separate the concerns

Being able to separate your code into smaller units is a really great tool, and helps you really understand your own code changes in a new light. Amusingly despite me often rewriting the same code 3 times, I feel like I've never been more productive (and no, I don't use any LLMs)