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.
Comments
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.
You can combine this with the `:/<text>` syntax [0] for matching the most recent commit with a given text in the commit message, e.g.
0: https://stackoverflow.com/a/52039150Thanks, I am —- but I always found it easier to just give the new commit a name I know how to squash rather than type in a SHA.
The other post about being able to do it on a substring match sounds way more ergonomic though, I’ll have to try that!