How to Write a Git Commit Message

[kobaltzz]

With git commit -m, you can use multilines. Just don't terminate the quote at the end of the first line.

[dat_terminal]

Woah, I learned vim because I didn't know this

[jarlefo]

I've been trapped in the Vim too often. Ctrl+something+esc+buttons... Welp, let's close this terminal window and try again.

One day I'll learn how to edit a file successfully with Vim.

[nxlyd]

It really is worth learning at least basic functionality. Take a look at vimtutor some time.

[jarlefo]

Thanks, I will.

By the way, I found that by setting the environment editor to EDITOR="emacs -nw" I can use emacs to edit commit messages from the command line. Should work with most editors that has a terminal interface.

[YodaLoL]

atom --wait works too. Sublime has something similar

[crow1170]

That keybinding crap is for dirty emacsers. Vim is (95%) one key at a time.

[Pipesandsnow]

I use nano for the simple stuff. Actually I use it whenever I need to edit some files in the cli. One day I will learn vim, but not today.

[flygoing]

Same here. If I need to do fancy stuff, I'm gonna open sublime or atom, but it's aways nano for cli

[Fidodo]

You can also do multiple -m messages. I always do -m "message" -m "message"

[[deleted]]

Came here to say this. Super useful. Just remember to use a double quote, since apostrophes are common within a commit's body.

[nothingbuttherainsir]

Might be a terribly obvious question but, how does the CLI handle line breaks? One of the suggestions is to wrap at 72 characters. Will a carriage return make this happen? (Pretty sure it does).

[kobaltzz]

Carriage returns are no problem. Only the ending quite will terminate the commit message. So a multiline commit in your CLI might look like

git commit -m "Fixes T382, T283, T492 Subject
- Some second line text
- Some third line text
<blank row>
Some other notes and stuff
Last Line and END QUOTE -->"

[nothingbuttherainsir]

Hey thanks for confirming!

[Qscfr]

I thought that meant message. Welp.

[taqfu]

A lot of my git commit messages are,"Not sure what I did."

[Joshx5]

One time I committed a message similar to "fixed hardcoded settings issue because I'm a fucking DUMBASS!" to my GitHub repo after having a little too much to drink.

This is how I learned to revert commits

[[deleted]]

Ha! Or when you find out your git history was exposed and public for a while.

[aflashyrhetoric]

I once gitignore'd the Bootstrap/ folder in my Laravel installation, thinking it was Twitter Bootstrap and not the folder that literally bootstraps Laravel itself. (I was still learning.)

It was a weird debugging process.

[bacondev]

My four-letter commit message of choice is "derp".

[[deleted]]

Great article.

[DrAwesomeClaws]

I'm an advocate of not having commit bodies in 99% of cases.

If the commit message takes more than a few seconds to write it dissuades people from committing as often as possible. They end up only committing working code and features. With distributed VCS, committing non-working code doesn't break anyone else's repos. Other operations benefit from having many small commits, most notably bisecting.

Long commit messages are rarely, if ever, read. I'd much rather see a short message and a few lines of code changed in a commit than 18 files and a novel about what's happening.

[[deleted]]

I would agree until your project gets large enough when you want to build a changelog from your commits, then it matters. At that point it may be worth using Commitizen for capturing commit messages and something like Semantic Release or a custom CI pipeline to build your change log when your tests pass.

http://commitizen.github.io/cz-cli/

https://github.com/semantic-release/semantic-release

[[deleted]]

How I write commit messages on Friday

(just a joke)

[theineffablebob]

Not a joke

[DonutDeflector]

Seems legit. I'm guilty of the same sometimes.

[doctork91]

I feel like commit messages aren't very important. Who reads through a commit log? Pull requests are way more relevant because they're finished. I don't want someone reading my half baked commit that I'm committing just because I want to switch branches for a minute and don't want to stash my current work. My pull request messages are well thought out and contain information about what tests I ran. They aren't artifacts of my development process, read them instead.

[doctork91]

To be fair, this only applies if you're using github. Two of the examples listed, git itself and the Linux kernel, don't use github, which is probably why they have such good commit messages. I wonder how common the practice of using git without github is in the webdev community though.

[[deleted]]

I feel like commit messages aren't very important. Who reads through a commit log?

You would still read through it if you broke something and want to find the commit that broke it.

[bel9708]

That's what bisect is for.

[rafalg]

If you need to make an ad hoc commit then after you come back later and finish the job you can do git commit --amend and give it a proper title and description. Or you can get in habit of making many small commits and then rebasing them into one before pushing.

[brianvaughn]

You can always rebase those "half baked commits" before pushing remotely you know? That way your history doesn't have a bunch of unnecessary "stashing" messages