Chris Beams

In a perfect world... You'd find that in the commit log for the code. Comments aren't the right place for things you forgot to do, or things that occur to you after the code sort of works. The commit message, and unit tests, are where those ideas can be best captured. I tend to point my team at this as a practice: https://chris.beams.io/posts/git-commit/

I can recommend that article: https://chris.beams.io/posts/git-commit/

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 have been recommending this article to my teammates: http://chris.beams.io/posts/git-commit/

I read the following tutorial on the topic few years ago and it has really helped me with commit messages: https://chris.beams.io/posts/git-commit/

I agree here. OP's article mentions Chris Beam's page [1] and I have all our developers follow that structure which helps but ultimately the biggest strength is the final line with the link to our JIRA. [1] https://chris.beams.io/posts/git-commit/

I always recommend this article: https://chris.beams.io/posts/git-commit/ The recommendations are the same, it's longer and provides more rationale at some points.

Speaking of Git commit messages, it's worth pointing out this wiki[1], written and reviewed by some long time open source contributors. It's a bit verbose, but rewarding to the patient reader. On writing Git commit subject lines, I've come to appreciate why the imperative mood is nicer (as opposed to the and indicative mood). Some related reasoning here[2]. [1] https://wiki.openstack.org/wiki/GitCommitMessages [2] http://chris.beams.io/posts/git-commit/

`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.

> 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…

Making regular commits is a good thing to do. Not sure why would you squash all the commits from a day? It is common to squash all commits from a branch, when merging though (https://softwareengineering.stackexchange.com/questions/263164/why-squ… Try writing good commit messages (https://chris.beams.io/posts/git-commit/).

Why good commit messages matter. https://chris.beams.io/posts/git-commit/#intro

This is a good start: https://chris.beams.io/posts/git-commit/

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.

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. :)

I use these 7 git commit message style rules [1] to establish my foundation of "committese". Things like "Use the imperative mood in the subject line" give commit messages a succint, consistent style. Everything after that is finesse, personal effort, and ability to express things succinctly (much like the personalized "headlinese" styles mentioned). [1]: https://chris.beams.io/posts/git-commit/

I would suggest making sure to explain why there staging step exists: to create coherent commits. Then go into "why distributed version control." How to write a Good Commit Message (https://chris.beams.io/posts/git-commit/).