> I used to do a squash rebase This probably wouldn't apply to the "initial commit" problem, but I almost always use fixup instead of amend, ex: git add f

> I used to do a squash rebase This probably wouldn't apply to the "initial commit" problem, but I almost always use fixup instead of amend, ex: git add foo.code git commit --fixup {commit_with} git rebase -i --autosquash {main_or_whatever} Unlike amend, you can target an older commit rather than just the very-most-recent (great if you're separating the rename/refactor from the rewrite) and you can delay the second step of actually changing history until you're sure stuff is in a good state. This is particularly useful for the review process: All the changes during the review process can be "fixup" commits, allowing reviewers to easily see what did (or didn't) change since their last interaction. At the same time, all the fiddly fixes and back-and-forth stuff won't be in the final history, only a smaller number of "real" commits that future maintainers would care about.