Jujutsu has a command which is helpful for this sort of workflow called absorb which pushes all changes from the current commit into the most recent commit which modified that file. (Each file may be merged into a different commit).
This seems very similar to how I work by default. I sort of think in terms of "keyframes" and "frames", or "commits" and "fixes to commits."
Whenever I sit down to code with a purpose, I'll make a branch for that purpose:
git checkout -b wip/[desc]
When I make changes that I think will be a "keyframe" commit, I use:
git add .
git commit -m "wip: desc of chunk" (like maybe "wip: readme")
if I make refinements, I'll do:
git add .
git commit --amend
and when I make a nee "keyframe commit":
git commit -m "wip: [desc 2]"
and still amend fixes.
Occasionally I'll make a change that I know fixes something earlier (i.e. an earlier "keyframe" commit) but I won't remember it. I'll commit and then do:
git add .
git commit -m "fixup: wip desc, enough to describe which keyframe commit should be amended"
at the end I'll do a git rebase -i main and see something like:
123 wip: add readme (it's already had a number of amends made to it)
456 wip: add Makefile (also has had amendments)
789 wip: add server (ditto)
876 fixup: readme stuff
098 fixup: more readme
543 fixup: makefile
and I'll use git rebase -i to change it to reword for the good commits, and put the fixups right under the ones they edit. then i'll have a nice history to fast forward into main.
I think you might be aware given the specific words you use but for the benefit of others:
Git commit --fixup lets you attach new commits to previous hashes you specify and then can automatically (or semi-manually depending on settings) squash them in rebases.
They are quite different methods, explained by the respective implementations. IME autofixup finds the relevant commit successfully more often. There's no reason you can't use both, of course. I would always check the results of either before actually doing the rebase.
