Chris Beams is a software developer who writes about Git practice and small-business technology.
HN commenters repeatedly recommend his Git commit message guide to teammates and others, and one notes that magit's commit formatting follows its advice.
> Good developers engineer repetition away. Great developers share what they build. Hence Git Town.
As someone who has engineered repetition away and shares what he builds, I agree, and admire your gumption.
> intentionally designed as a low-level and generic tool.
git is high level. and opinionated. It has branches and tags baked right in. Compare to SVN or CVS where the support is second class.
> requires running many Git commands for each operation, and is highly repetitive.
I run lots of git commands by hand, and can be pretty verbose in commit messages. I (sort of) try to follow this: https://chris.beams.io/posts/git-commit/
However, to speed things up, I will sometimes at shell prompt use `ctrl-r` and search history a bit, then `ctrl-e` to start scrolling in a line brought back up if I want to both 1. see what I committed last, and 2. get a head start on writing the commit message.
I also find the staging workflow git has (another thing I personally consider high-level, purposeful, opinionated to git, and use regularly) to be very convenient. I can type `git status`, `git diff`, `git diff --cached` to see what's staged and unstaged. I can use `git reset` to unstage a file. Overall, I get more granularity on which files I want to add to that commit. This comes in really handing when reverting, merging and rebasing.
So in my workflow, I don't want to give up control of these things.
Apparently, while I don't use these features, `git bisect` and `git blame` also…
`squash` is a tool and it's neither good nor bad; it needs to be applied where it makes sense.
The title is indeed click-baity. It would have been more interesting to read that the bug/mistake was caused as a result of squashing. It's not the case and I take issue with the way the author describes his commits.
The problematic commit is described "Extract CreateTokenValidationParameters method", without an explanation of why the refactoring is necessary or what problem is it solving. It looks like it is improving code readability, but it doesn't go as far as fixing the more glaring issue with global variables. Other commit messages seem to follow the same pattern.
In other words, the commit:
- has minor code readability improvements
- contains no useful message for the future programmer (why is it needed?)
- provides no new functional feature/improvement/business value
- is later found to contain a bug
I find squash/rebase/cherry-pick useful when reviewing my work and deciding what should go in the current pull-request. For example, a refactoring might be postponed for later if it is deemed too time-consuming or irrelevant to the current PR. Or, one can squash logically related commits together, add a useful message and merge them separately. The resulting commit log will still be bisect-able.
For beginners: there's a very good article with tips for Git Commit Messages[0] that helped me have git histories I enjoy reading.
[0]…
This is a good article that covers how to communicate in a pull request. I think there are two other essentials in making good pull requests.
1. Good commit messages. Follow this guide: https://chris.beams.io/posts/git-commit/
2. Following the pull request workflow correctly. Follow this guide: https://github.com/susam/gitpr
Writing good and consistent commit messages make the commit log easy to read and search.
Pull request workflow is equally important. It is kind of a rules of engagement that co-developers follow to keep working on their stuff concurrently. It keeps unnecessary merges to minimum and keeps the commit history clean.
By following these two things, you are not only going to be nice to your co-developers but you are going to be nice to your managers and release departments too who could look at your commit log and figure out what bugs were fixed and what features were released.
At about the same time, Chris Beams wrote this, which I have loved ever since:
https://chris.beams.io/posts/git-commit/
I note with some glee that magit colorizes my commit text and flags long lines,etc. largely in the style of this advice.
The money:
The seven rules of a great Git commit message
Keep in mind: This has all been said before.
Separate subject from body with a blank line
Limit the subject line to 50 characters
Capitalize the subject line
Do not end the subject line with a period
Use the imperative mood in the subject line
Wrap the body at 72 characters
Use the body to explain what and why vs. how*
I wonder why is it so hard for people to right good commit messages. At my company I've actually tried trying talking in-person to people, even write a doc explaining the benefits and how to do it, pointing people to good resources like this one: https://chris.beams.io/posts/git-commit/
And still, I can't get people to do it. I find it so valuable to look at commit messages that are written, that explains the why behind the changes in the commit but can't get people to see the same value as I do. Any tips on that? Would be really appreciated. :)
Would you add a full stop in an email subject? I think of commit messages like an email. The first line is just the subject and sometimes that is all you need. The body of the commit message is for describing other details.
edit: Another blog has a simple reason https://chris.beams.io/posts/git-commit/
> 4. Do not end the subject line with a period
> Trailing punctuation is unnecessary in subject lines. Besides, space is precious when you’re trying to keep them to 50 chars or less.