How to Write a Git Commit Message (2014)
chris.beams.io
How to Write a Git Commit Message (2014)
1–10 of 121 posts
Re: How to Write a Git Commit Message (2014)
#2The most important tip is "Use the body to explain what and why vs. how".
I'd also say: remove thw -m option from git and force people to open the editor. Do not accept messages shorter than 3 lines, start the editor with a template
Title
What changed and why it changed.Re: How to Write a Git Commit Message (2014)
#3The most important tip is "Use the body to explain what and why vs. how". I'd also say: remove thw -m option from git and force people to open the editor. Do not accept messages shorter than 3 lines, start the editor with a template Title What changed and why it changed.
You can easily enforce this if you want through a pre-commit hook, but this is frankly ridiculous to enforce on everybody.
Re: How to Write a Git Commit Message (2014)
#4The most important tip is "Use the body to explain what and why vs. how". I'd also say: remove thw -m option from git and force people to open the editor. Do not accept messages shorter than 3 lines, start the editor with a template Title What changed and why it changed.
It's likely that this would push the tools toward being too opinionated. I spend a lot of time pushing little WIPs so I know where I am and my macros rely heavily on -m, e.g. I end up with a commit message like "WIP: don't merge these debugging lines" or "WIP: Tweak the IO timeout and profile". -m is also useful for making trivial commits, I don't use it for this often because it's easy to violate 50 chars but it's a perfectly valid use of the tool IMO.
Re: How to Write a Git Commit Message (2014)
#5The most important tip is "Use the body to explain what and why vs. how". I'd also say: remove thw -m option from git and force people to open the editor. Do not accept messages shorter than 3 lines, start the editor with a template Title What changed and why it changed.
For my own commits in my personal repos I often find that less than 80 chars are sufficient to describe the change entirely. I generally don't care about surpassing 80 chars for commit messages though, so even if my commit message is somewhat long I won't split it up.
I commit very often and usually small, "atomic" changes most of the time.
What I will do, is that I start the commit message with the most important sentence and add less important sentences after, so even if it exceeds 80 chars and you can't see the whole message you will still get the most relevant info without having to scroll sideways.
For reference, here are the commits to a project I am currently working on: https://github.com/eriknstr/jumper/commits/master
Re: How to Write a Git Commit Message (2014)
#6I really like that Gerrit code reviews allow reviewers to comment on the commit message in the same way as on the code. The way to ensure useful commit message practices is the review process, if you ask me.
Re: How to Write a Git Commit Message (2014)
#7The most important tip is "Use the body to explain what and why vs. how". I'd also say: remove thw -m option from git and force people to open the editor. Do not accept messages shorter than 3 lines, start the editor with a template Title What changed and why it changed.
Dogmatism like "commit messages must be at least three lines" will result in commit messages like:
here's
some
code.
Re: How to Write a Git Commit Message (2014)
#8My team uses a git commit message convention that helps us read fast and also is parsable by toolchains.
We agree on a short list of leading active verbs:
Add = Create a capability e.g. feature, test, dependency.
Cut = Remove a capability e.g. feature, test, dependency.
Fix = Fix an issue e.g. bug, typo, accident, misstatement.
Bump = Increase the version of something e.g. dependency.
Make = Change the build process, or tooling, or infra.
Start = Begin doing something; e.g. create a feature flag.
Stop = End doing something; e.g. remove a feature flag.
Refactor = A code change that MUST be just a refactoring.
Reformat = Refactor of formatting, e.g. omit whitespace.
Optimize = Refactor of performance, e.g. speed up code.
Document = Refactor of documentation, e.g. help files.
Re: How to Write a Git Commit Message (2014)
#9How to write good git commit messages literally from the person who wrote git (Linus Torvalds):
https://github.com/torvalds/subsurface-for-dirk/blob/0f58510...
I always send this to people as I teach them git.
Re: How to Write a Git Commit Message (2014)
#10[deleted]