4 ms·
You're right -- the diff answers the what, so being able to answer the why concisely is what makes a good commit message. Ticket numbers are important context,
by Smudge 12y ago
You're right -- the diff answers the what, so being able to answer the why concisely is what makes a good commit message.
Ticket numbers are important context, but unless it is a one-off commit you can instead put that info in the merge commit (as if saying, all of these commits I'm merging were made as part of fixing Issue #17).
Some people like to use squash extensively for that reason, but then you don't have the same granularity when it comes to reverting individual bits of that commit without reverting the entire bugfix. (This assumes that every commit leaves the code in a working state with passing tests).
- erichurkman 12y agoIssue numbers in each commit can also help when you end up cherry-picking commits from one branch to another.
- VBprogrammer 12y agoYeah, I prefer the issue number in each commit as it makes the commit log more readable to me. But do a decent job of everything else and that is a very small nit-pick.
- jipiboily 12y agoI agree it useful, but it's more useful overtime than anything, on the short term, issue numbers are not really useful. You are right, those examples were not our best ones ;)
- Smudge 12y agoI guess in that scenario my preference would be to amend the cherry-picked commit's message to include why it was cherry-picked. The alternative in your case (leaving it as-is, with an issue number) implies that the entire commit addresses that particular issue number, which may not be true. (It may be part of a series of commits for that issue)
- reledi 12y agoThis creates a lot of noise on GitHub though. I prefer to put the issue number in the branch name and in the PR description. But for one-off commits, it goes in the commit message.