87
Linus Torvalds on how and when to maintain a clean git history (2009)
(www.mail-archive.com)
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Follow the wormhole through a path of communities !webdev@programming.dev
While exploring solutions, I use
f
orff
to mean "follow-up/to-squash" anda
to mean logically separate. Sometimes other (additional) short abbreviations to know where to move, squash, and edit the changes to.Other than maybe initial development until the first stable/usable version, these never persist, though. And even then, only if it's not a collaborative project. If it is shared or collaborative, "Iterate on x" is preferable as a non-descriptive title.
I guess my commit descriptions get better with project lifetime, not worse.
I recently discovered
git commit --fixup=abcd1234
: it will make a new commit with a message offixup! <message from abcd1234>
. (It's the only special thing that flag does: a specially formatted commit message, which you can craft yourself if you remember the spelling of thefixup!
marker.)When you later rebase,
git rebase --interactive --autosquash
will automatically mark that commit to be a fixup ofabcd1234
.magit for emacs has shortcut for creating a fixup commit selecting the previous commit, I'm sure other interfaces do too.
I've found that too, which I think is because as the project matures, you're more likely to make fixes or contained features, as opposed to regular "change everything" as you explore the design in a young project.