| 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. |
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.