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.
git is a means, not an end
code review is about the code as a unit whole, not the steps along the way!
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)
It does require a bit of a paradigm shift sometimes to not rely as much on seeing all cumulative changes for the ticket highlighted as you code, and instead compartmentalize your immediate view to the current commit's task, but often the above 2 alternatives help suffice. Of course, you did mention that you'll commit stuff you're not likely to touch again, which helps a lot too
Seems like it would be even better if VS Code provided a way to highlight all lines changed relative to a particular commit like the start of a branch. Maybe it's worth filing a feature request?
(I don't use VS Code this way so I'm assuming it doesn't already have this.)
Meaning, I can keep committing while also able to see the full changes evolve.
If you’re interested in trying these strategies anyway, does your editor of choice have an inline “git blame”? In IntelliJ, I can see who and when committed the most recent change in the line around the one I’m working on.
It doesn’t resolve the “which files have I worked on” issue; but it might help the others? Not as nice as a different colored line like uncommitted code would otherwise be highlighted, but it could be enough of a step in that direction?
git add --patch
...is your friend if you want to leave all your changes unstaged for awhile then break it out into multiple commits later. * squash everything I’ve done into one commit
* create a new branch off main/master that will be the “first commit”
* cherry-pick changes (easy from some git guis) that represent a modular change.
* push and make an MR from the new branch
* rebase “the big commit” on top of the partial change.
* wash, rinse and repeat for each change, building each MR off its requisite branch.
The squashing part is vital because otherwise you enter merge conflict hell with the rebase. * squash into one commit
* git reset HEAD~1
* git add -p
* git commit -m commit1
* repeat until no changes are left
* add any file deletions/additions
I use this because you can have several commits marked e.g. "commit1". Then you make a final interactive rebase to squash them together.