3 ms·
Something I learnt about good commit messages over my career was that the more useful messages don't summarize what is in a change, but why the change was neede
by bdg 4y ago
Something I learnt about good commit messages over my career was that the more useful messages don't summarize what is in a change, but why the change was needed. Usually everyone can quickly figure out what changed if the commit is of some kind of reasonable size, but why it was changed is lost forever.
That said, a lot of my personal projects that will never get published are just "foo" messages.
- Narushia 4y agoI personally try to always include at least a short explanation on why the change was done, unless it’s self-explanatory. But I’m under the assumption that most people don’t do this because they already have that info in a relevant issue or merge/pull request. Which I think is a fine approach, especially if you leave the relevant link or identifier to the commit message.
- gerad 4y agoIn my experience ticketing systems come and go, but the commit history remains forever (yay dvcs), so it's a good idea to summarize the why in the commit message - even if it's already also somewhere else.
- Narushia 4y agoAgreed. I usually end up writing the thing in at least one place besides the commit. Takes more time, but should be more future-proof as well. :)
- altf4 4y agoThe best advice that I got was to write commit messages as a letter to your future self.