21–30 of 58 posts
Commit messages are whatever an individual, community, or organization decides they should be. Debating beyond that is like debating tabs vs spaces. It doesn't matter as long as everyone you're working with is on the same page.
Commit messages are whatever an individual, community, or organization decides they should be. Debating beyond that is like debating tabs vs spaces. It doesn't matter as long as everyone you're working with is on the same page.
Nothings worse than digging through a ton of diffs to find the breaking change.
Commit messages are not titles, or subjects, they are COMMANDS, written in the present tense, that describe exactly what will be done to the codebase if you merge in the commit. That’s pretty much all there is to say about it.
Well, I'll say more... They are a summary of what will happen if the commit (which is a bunch of commands) is applied. They also can elaborate on the context around the commit. It's thoughtful of the commiter if your coworkers don't need to dive into the detailed changes to get a broad picture of why the commit exists.
Also, commit messages are sometimes the "documentation of last resort".
In my organization, putting comments in the code is frowned upon. "Comments are lies! The documentation is in the tests!"
But the tests don't lend themselves to _reasons_ behind why the code was written a certain way, why a given approach was taken (for example, we needed to re-write a Rails database migration in a somewhat contorted manner to avoid a deadlock that was occurring in production).
In such organizations, the git commit message are often the best place to warn future programmers of pitfalls: "don't even think of parallelizing these table updates—you'll get deadlocks!"
[edited for brevity]
Commit messages are whatever an individual, community, or organization decides they should be. Debating beyond that is like debating tabs vs spaces. It doesn't matter as long as everyone you're working with is on the same page.
The "rule" I like when it comes to commit messages it that they should be clear enough that someone who gets woken up for a production issue at 3am can quickly parse what was in the commit and how dangerous it is. Nothings worse than digging through a ton of diffs to find the breaking change.
1. really short summary in a few words, ideally mentioning the relevant issue(s) in the bug tracker 2. Blank line 3. Longer message, if necessary, to explain the change
If I'm going to be looking back through commit messages, that's the type of commit message I want to read. I want to know whether this commit is interesting or if I can safely skip it.
It doesn't need to be complicated. Just write a short note as if you wanted to remind yourself where you left off when you come back from vacation.
Just use {JIRA Reference} - {JIRA title} and get on with your life.
The irony of this comment being that managing JIRA tickets is probably the absolute biggest time-sink of any organization that uses it.
JIRA ain't perfect though. The constant UX changes drive me nuts. At least HN still works the same way as 10 years ago, but JIRA keeps changing like a shapeshifter.
Commit messages are whatever an individual, community, or organization decides they should be. Debating beyond that is like debating tabs vs spaces. It doesn't matter as long as everyone you're working with is on the same page.
The "rule" I like when it comes to commit messages it that they should be clear enough that someone who gets woken up for a production issue at 3am can quickly parse what was in the commit and how dangerous it is. Nothings worse than digging through a ton of diffs to find the breaking change.
> If the first line of a commit message is a title, it changes the way you write it. It becomes just some text to introduce some more text, without any stress on the information density . I agree with the author that commit messages should optimize for information density. However the example they provide does a poor job of this: > This is a smart synopsis, as information dense as possible. "This is a" is the type of…
Commit messages are whatever an individual, community, or organization decides they should be. Debating beyond that is like debating tabs vs spaces. It doesn't matter as long as everyone you're working with is on the same page.
Summarizing a diff frequently doesn't add information that the diff itself already includes. Title or no title.
I'm surprised we don't think about how to shout into the future more effectively. It might be ourselves that we're helping the most.
> If the first line of a commit message is a title, it changes the way you write it. It becomes just some text to introduce some more text, without any stress on the information density . I agree with the author that commit messages should optimize for information density. However the example they provide does a poor job of this: > This is a smart synopsis, as information dense as possible. "This is a" is the type of…
> I led an initiative at my current company to enforce all commit messages start with an imperative verb and be less than 72 characters. You are truly doing god’s work :). I’ve led a similar initiative and same outcome, some love, but those who don’t, really hate it.