3 ms·
I follow the format of the first line being a tag with a short one line description, followed by a new line, followed by further explaining of the what and why.
by tuckerpo 7y ago
I follow the format of the first line being a tag with a short one line description, followed by a new line, followed by further explaining of the what and why.
Example:
"Fix: router now asynchronous.
Our previously implementation of a synchronous router was causing a 30% slowdown when tested with `wrk` (hyperlink to utility used to test)."
with an additional link to a Jira ticket if the particular commit addresses one.
Seems to float well with everyone I've worked with.
- jgalt212 7y agothis makes perfect sense and one should show care when constructing commit messages. That being said, if commit messages require too much care, then folks will start to make less commits as they become rather expensive to do. As with all things in life, when and how often to commit is a balance.
- iudqnolq 7y agoWhat do you think about committing with one-liners as you develop so that you can rollback, and then completely rewriting history before pushing?
- pavon 7y agoI absolutely agree that you should commit early and often, and that short one-liners for those commits are fine. It is when you go to merge that you need to have good messages and there are several ways you can do that, depending on your team's preferences: * You can rebase and groom your commits into meaningful sets of changes each with good descriptions (how Linux uses git). * You can squash all the commits, and always just have a single commit for each merge with a detailed description. * You can keep your full commit history as a record of how the work was actually done (Fossil encourages this philosophy), but always have a detailed merge commit that can stand-alone in describing all the work done in that merge.