4 ms·

You should be answering the question “why does this commit exist?” when you write your commit messages. You’ll be asking yourself that same question when you co

by teeray 4y ago

You should be answering the question “why does this commit exist?” when you write your commit messages. You’ll be asking yourself that same question when you come across the commit via git blame or bisect later. Summarizing the content of the commit usually isn’t enough to provide that context.

indeyets 4y ago
I prefer to have both. First line — a short summary of changes, further lines telling reasons and relevant comments
curun1r 4y ago
I think it really depends on the type of project. An open source project is going to have different goals for commit messages than an internal corp project or a private personal project. I'm a big fan of conventional commits, but only in the context of a project that needs to generate a changelog so that users can quickly decide if they'd like to update. In that context, the why is totally inappropriate and should be part of a linked issue, not the commit message. But in a corp environment, it's really much more about preserving context so that future developers can figure out why something happened, so the why is super important. Corporate teams will have turnover and, when someone leaves, they're not going to be available to answer questions. And a private personal project is often just about using git as a checkpoint saving tool so that I can preserve known-working states. In that context, I'm really only interested in describing the state I'm preserving rather than describing what changed or why. If I ever decide to release it publicly, I'll rebase to hide the mess of my initial explorations anyways. Not being able to adapt your commit message style to the purpose it's serving is overly dogmatic. I wouldn't use the same language or tools for every project, so why would I use the same commit message style?

4 ms·

You should be answering the question “why does this commit exist?” when you write your commit messages. You’ll be asking yourself that same question when you co

by teeray 4y ago

indeyets 4y ago
I prefer to have both. First line — a short summary of changes, further lines telling reasons and relevant comments
curun1r 4y ago
I think it really depends on the type of project. An open source project is going to have different goals for commit messages than an internal corp project or a private personal project. I'm a big fan of conventional commits, but only in the context of a project that needs to generate a changelog so that users can quickly decide if they'd like to update. In that context, the why is totally inappropriate and should be part of a linked issue, not the commit message. But in a corp environment, it's really much more about preserving context so that future developers can figure out why something happened, so the why is super important. Corporate teams will have turnover and, when someone leaves, they're not going to be available to answer questions. And a private personal project is often just about using git as a checkpoint saving tool so that I can preserve known-working states. In that context, I'm really only interested in describing the state I'm preserving rather than describing what changed or why. If I ever decide to release it publicly, I'll rebase to hide the mess of my initial explorations anyways. Not being able to adapt your commit message style to the purpose it's serving is overly dogmatic. I wouldn't use the same language or tools for every project, so why would I use the same commit message style?