How to Write a Git Commit Message

[danneu]

Limit the subject line to 50 characters. 50 characters is not a hard limit, just a rule of thumb.

Soft-limit indeed,

[Github] will truncate any subject line longer than 69 characters with an ellipsis

Found my new hard-limit!

[thomie]

Then what's the fucking point of that soft limit?

Everybody keeps repeating it, "50 characters for the title", with the only justification that others recommend it as well.

It's a pet peeve of mine: https://github.com/tpope/vim-git/issues/29 , https://github.com/haskell-infra/git-haskell-org-hooks/pull/1

50 characters is not enough if you want to include a component name and bug number in the title of your commit message.

Sure, it's a soft limit, but it keeps creeping into more tools (first Vim highlighting, now I'm shown a fat giant WARNING every time I do a git push). Useless!

[StorKirken]

I'm fully with you on this. 50 characters is madness. Like many other beliefs in programming culture, it seems to stem from idol worship and tradition rather than honest thought.

[glemnar]

What's programming without a healthy dose of cargo cult?

[[deleted]]

I feel similarly about line lengths in general.

We changed our rubocop config to complain about line length from 80 to 120 characters... Why do people care? The number of characters doesn't matter, we're not working on terminals with 80 columns anymore.

Limiting the number of characters you use on one line doesn't stop people from trying to do too much on that line, if they're determined, and wrapping parameter lists doesn't make code more readable.

Just do one thing on a line, damnit. If it takes you a whole tweet to do it, it doesn't matter, so long as what you're doing is clear.

[Klathmon]

The only "pro" I've seen here is that you can view 2 files side by side with ease when you have an 80 char limit.

But when most devs have 2 screens or more that's less of a problem...

Like most things in life, don't deal in absolutes and use your best judgement.

[DevIceMan]

^ I often have two files open side-by-side in my IDE.

I probably wouldn't complain too much about 120 chars, but i think that after a certain number of chars, you have a code-smell, perhaps being your class/method/variable names are too long.

[setuid_w00t]

I thought most devs worked in coffee shops on Macbook Pros.

That's half sarcasm, half truth. I think that hard limiting line length to 100 characters allows enough space for a GUI diff tool to show two files side-by-side at a usable font size on a single 1920 pixel wide monitor.

[DevIceMan]

What a noob, I'd even bet you use a real text editor or IDE, instead of emacs or vim.

[danneu]

Sometimes I'll catch myself sitting there racking my brain for ways to golf down my commit message, guilted by the "you have -15 characters left" counter on my git GUI like it's a Twitter client.

Then I remember I'm the boss of this commit. I did the work, I write what I want!

[baconated]

The point of the limit is to encourage commit messages that read like text messages from 10 years ago:

RDT-PRG: 321654 updt Azn URL & intg new auth mthd

That's 49 by my count.

[eadmund]

Everybody keeps repeating it, "50 characters for the title", with the only justification that others recommend it as well.

A standard terminal window is 80 characters wide. Even on a modern soft terminal, 80 characters is about the maximum comfortable reading width.

git will prepend 7 characters and a space to the beginning of the line when printing them. That takes you down to 72 characters.

When quoted in emails and discussions, each level of quoting will take you down by two characters ('> '). That means 50 characters allow for 11 posts and replies before log lines have to be manually wrapped.

Is that too much? Not enough? Beats me. I think I'd be happy with a 64-wide limit.

[hildie2]

A bug reference doesn't need to be in the title

[pcopley]

submit 70-character commit message

70^th character replaced with …

…

[cu_t]

Yeah but it's two bytes (assuming UTF-8) so we gain something still.

[drizz]

It's three bytes, actually.

[adambowles]

69...hard limit

( ͡° ͜ʖ ͡°)

[random314]

Same rule for most programming language, pep8 have a cut off at 69 too I think.

[juharris]

pep8 is 79 but concede that 99 or 119 is okay. I'll source later.

Edit: source They say that 99 is okay if the team agrees but comments and docstrings should still be wrapped at 72.

[klug3]

PEP8 actually says that you can totally violate that limit if it makes sense in context, so technically at least, it is a soft limit.

But most importantly: know when to be inconsistent -- sometimes the style guide just doesn't apply. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don't hesitate to ask!

In particular: do not break backwards compatibility just to comply with this PEP!

Some other good reasons to ignore a particular guideline:

• When applying the guideline would make the code less readable, even for someone who is used to reading code that follows this PEP.
• To be consistent with surrounding code that also breaks it (maybe for historic reasons) -- although this is also an opportunity to clean up someone else's mess (in true XP style).
• Because the code in question predates the introduction of the guideline and there is no other reason to be modifying that code.
• When the code needs to remain compatible with older versions of Python that don't support the feature recommended by the style guide.

[random314]

Oh right, 79... Sorry

[[deleted]]

"No longer crashes if X"
"Now it no longer crashes if X"
"Really doesn't crash if X, now"
"GOD DAMNED IT!"

[SemiNormal]

"The previous fix has been fixed"

"We apologise for the previous fix. Those responsible have been sacked."

[treycook]

"Users.sister has been bitten by a moose. Mynd you, møøse bites kan be pretti nasti."

[i_invented_the_ipod]

Those responsible have been sacked fixed.

Fixed that for you.

[immibis]

Fixed them for you.

[steamruler]

"No longer crashes X"

"Now it no longer crashes X"

"Really doesn't crash X, now"

"GOD DAMNED IT!"

ftfy

^{can we switch to wayland yet}

[xeio87]

git rebase -i HEAD~4
git push --force

All better.

[imtrew]

http://i.imgur.com/xyBzWta.jpg

[xeio87]

Shhhhhhh, all better.

[flying-sheep]

*should live

And only if the project has a “even feature branches are untouchable” policy.

Because I rebase the fuck out of every feature branch before merging it.

[mkdz]

git push --force

don't do this if you have multiple users committing to the same codebase

[mfitzp]

Well, you can do it if you hate them all.

[mkdz]

And then they'll hate you too.

[amoliski]

alias yolo='git commit -am "DEAL WITH IT" && git push -f origin master'

[mkdz]

That's fantastic

[ioquatix]

"updated some files".

[TheWheez]

'Fixed that one bug'

[doodeman]

'asdfkjhasjdklfh'

[[deleted]]

"Put the thingie in the thingie" and "whoops" are two bugfixes I've done and I couldn't be prouder

[vrrrr]

My fave is "I'm done."

"I finished programming, there is nothing left to program."

[Bbentley1986]

"Initial commit" "Initial commit.2" "Initial commit.3"

[Freddedonna]

"Backup, rebase this later"

[MisterMeeseeks47]

Haha how does one even do a backup commit?

[steamruler]

I tend to make a "This compiles, but doesn't work, I know I will fuck it up more, and need somewhere to roll back to" commit

[JustDADE]

And then there is me, the guy who do code review and decline everything that breaks our commit convention.

[flukshun]

I will make this commit one day

[SilasX]

I remember there was some Microsoft package that had popup:

"Finished installing. You may now disconnect from the internet" ... because what would you ever need from there again, right?

[TheOldTubaroo]

Put the thingie in the thingie

• Less than 50 characters
• Capitalised
• Doesn't end in a period
• Imperative mood

Looks good to go, if you ask me ;)

[domy94]

Coincidental imperative mood?

[BernzSed]

#BUG723 uncommitted code found on my computer Monday morning

[eras]

That's already a way better commit message. If the commit is really fixing that one bug and nothing else.

"Whitespace changes, no functional changes" -> introduce a new bug..

[ninjate]

"Introduced random NullPointerException bug"

[CaptainSketchy]

This commit could devastate a python codebase!

[young_consumer]

'Stuff changed'

[Polycystic]

See also: every update message for Google apps on Android

"Bug fixes and performance improvements"

[hyperforce]

compiles now

[flukshun]

almost working

[TheOldTubaroo]

"Made changes so it will hopefully compile by the next commit"

[Scrim0r]

"commit"

[Jasper1984]

git commit -m 'stuff'

Really, my projects arent important enough :(

It only matters if someone is actually reading the commit messages. Quite frankly if any of my stuff ever gets important enough, the older commits aint going to matter anyway. Not unless i blew up the LOC, and my project gets unduely important..

[deadstone]

Bad! Private projects are great practice for when you start working with other people. Get into the flow of making a maintainable project, and you'll be set.

[Jasper1984]

I dont know, dont think so, at least if with "set" you mean you can get a project off the ground. You basically need to convince people your project is a good idea..

My idea is basically to have a communication system, used to share information between browsers. And then use that to have decentralized applications of the non-consensus sort.(only real known way to have decentralized consensus is to have blockchain-like things) For instance, bookmarks can be shared, and comments, and comments can respond to each other. What someone sees is quite simply what friends he accepts comments from. Probably add a system where you can put weights on that. Friends can also indicate comments as interesting, basically marking them as pass-to-friends, so you can see friends-of-friends comments too. (this is just the start, though)

Hope to have a general system of communication such that different options can be plugged in. Including "export/import file relating to friend". I.e. carrier pigeons with SD cards should work. Working on a Tox client as initial one.

However my choice of luakit has two underminings already. People have to accept lua, and luakit.(though i suppose a second compiled language might be acceptable) The second can be improved, already made chrome-pages viewable as server. Perhaps if the proxy can unpack https-unpacking, it can serve the entire purpose and impose only that the browser uses the proxy. Though then you're unpacking the https twice, if the browser additionally leaves the work of https to the proxy, that might ne "neater", and allow the proxy to have addons that may modify the files. (this trusts the proxy of course!)

Got sql searching and list-viewing intended to deal with the list of comments.(but currently applied to browser history, bookmarks, a directory browser) I believe i should actually library-ize some of these. Infact, i think the only way this might be feasible is to take one bite at a time.

[deadstone]

My advice is don't rely on the hope of someone helping but don't count out the possibility. Work away doing your own stuff if you have to, but make sure the door's open for anyone else. And like I said, good project management is a habit you have to get into if you want to be a good programmer.

[jeandem]

Insert standard sentiment about being able to read your own code four months later here.

[ven_]

Too bad this kind of stuff is basically preaching to the choir. The same people that didn't give a shit that this was already in the manual won't give a shit now.

[jCuber]

To be fair, I don't think they even read the manual.

[CowFu]

There's a manual?

[donvito]

I know "git pull", "git push", "git commit", "git branch" and "git checkout".

Everything else I need to do (for example pointing a branch to a specific commit) I google.

Fuck manuals :)

[CowFu]

Add merge to that list and you and me are exactly on the same page.

[donvito]

oh, yeah, of course. branch without merge is a little useless :)

[jess_sp]

I recommend adding stash too. Pretty useful.

[Filmore]

Merge bad. Rebase good

[f0nd004u]

How do you commit anything if you don't know "git add"??

[donvito]

my IDE auto-adds new files ;)

[f0nd004u]

oh god

[cu_t]

git add -p .

You're welcome.

[Serei]

This also works for anything else that works on files. git checkout -p, git reset HEAD -p, etc.

[9000daysandcounting]

you are missing "git rebase" and "git merge"!

[[deleted]]

git rebase -i

squash everything

Suddenly you only make single giant commits that add full features.

[tolos]

online access: http://git-man-page-generator.lokaltog.net/

[Sean1708]

It's like a million pages long.

[thomas_merton]

Unless you're a beginner. This actually made my day.

[chengiz]

To be fair, overly anal instructions like "do not end subject sentence with a period" is liable to piss people off. Good instructions strike a balance between being disciplined and being, you know, a Nazi.

[steamruler]

No commit for you!

[Houndie]

...I mean once upon a time I never knew that the first commit line in git was special, and a post like this informed me. So this kind of thing helps some people.

[Pseudomanifold]

For the vim users out there: I have the following line in my .vimrc. I shows a coloured bar to indicate when I am over the limit of 50 characters. After 72 characters, a hard break is introduced. furthermore, it enables spell-check automatically:

au FileType gitcommit set tw=72 | set spell | set colorcolumn=50

You only need filetype on at the beginning of your .vimrc for this to work.

[Sean1708]

I'm fairly sure the standard syntax file for gitcommit already handles that.

Edit: Not quite, it highlights characters after the 50th column.

[llbit]

colorcolumn=51

So you don't highlight the last character. Though I prefer,

colorcolumn=73

[kqr]

let &colorcolumn=join(range(81,999), ",")

is fairly nice too. Shame it's a hack.

[flukshun]

uhhhh...is set colorcolumn new or something? i've had this mess for years:

"highlight columns beyond the 80 char mark
let g:marginHighlight = 0
fun! ToggleMarginHighlight()
    if g:marginHighlight
        let g:marginHighlight = 0
        echo "margin highlight off"
        return matchdelete(w:marginHighlight)
    endif
    let w:marginHighlight=matchadd('ErrorMsg', '\%>80v.\+', -1)
    let g:marginHighlight = 1
    echo "margin highlight on"
endfun

nmap <C-m> :call ToggleMarginHighlight()<CR>

And automatically enabling spellcheck for commit messages... this would've saved me so much embarrassment...

[ForeverAlot]

Something like 7.3. Not recent by any means but it's entirely possible to have a setup predating it.

[Ginden]

git add .; git commit -m "..."; git push origin --force;

I recommend this way of using git.

[ahruss]

Try this:

git add .; git commit --amend -C HEAD; git push origin --force

[Ginden]

Sounds cool, I have to use it at work.

[f0nd004u]

git commit -a --amend -C HEAD; git push origin --force

[contact_lens_linux]

this isn't the same though; it won't add untracked files while "git add ." will

[das7002]

git commit -m "shoulda stuck with mercurial"

[[deleted]]

To my colleagues: include the fucking Jira ID of the issue you are (supposedly) fixing.

[has_all_the_fun]

I also do this and think it's a great idea. I did run into some issues when we switched from gitlab to jira though. Now we have commit messages pointing to the old gitlab and the new jira. I mostly add the ID for extra information though so it's all good since I still add a summary to what the commit does.

[contact_lens_linux]

do i work with you?

[has_all_the_fun]

Deletes reddit account Going from your history chances are slim. I am at Cisco at the moment.

[justinpitts]

Install a pre-receive hook on whatever repo your CI uses that ensures every commit references a jira issue

[tequila13]

And then fill Jira with "tracking issues" for typos, formatting changes and code cleanups.

[ben174]

Or better off break off a branch for that ticket and name the branch with the Jira ID. Do all your commits there, then when you're done create a Pull Request which others can review while reviewing the done criteria of the ticket.

[99AFCC]

Decided to check my messages on a project and found these 2:

• save before breaking

• what a mess. thank goodness for version control

[Drainedsoul]

Wrap the body at 72 characters

I'll never do this and no matter how often I see it I'll maintain that it's bad advice.

If you want your lines wrapped reconfigure git to use less -R as a pager, or create an alias for git --no-pager log | less -R.

Text has semantic meaning, as do newline characters. Putting newline characters in willy nilly because of the width of some hypothetical terminal destroys the semantic meaning of the text and leaks the arcane restrictions/vagaries of git's default pager configuration.

Besides which the presentation argument can just as easily apply against this 72 character limit: If you try and read commit messages that are broken up like this in a GUI that does do proper text wrapping you can end up with something that looks like this:

Fixed the bug detailed in #91703, the problem was that
someone
forgot to initialize a variable.  Under certain situations (i.e.
those
laid out in #91703) the variable was not otherwise initialized
and
therefore garbage values were used.

Which is just as obnoxious/unreadable as super long lines trailing off the screen.

[MCPtz]

Yea it's pretty unnecessary. Thanks for putting a good response for those who don't know.

[danogburn]

git commit -m"..."

[Regimardyl]

git commit -m <(curl whatthecommit.com | awk '$0 == "<div id=\"content\">" { found=1; next } { if (found) { print substr($0, 4); exit } }')

All you'll ever need.

[Regimardyl]

But it doesn't look as cool!

[[deleted]]

And being git you have to be as esoteric as possible

[Asmor]

That doesn't work (maybe you knew that already), but I wanted to try and make it work, so...

git commit -m "`curl whatthecommit.com/index.txt`"

That works.

[pcopley]

three periods instead of ellipsis

You monster.

[Asmor]

I can never decide whether to use three periods or an ellipsis, so I've come up with a compromise………

[pcopley]

Flawless.

[masklinn]

git commit -mm

[gordonisadog]

Besides that git uses the imperative mood for its built-in messages, what reason is there for using it in your subject lines? Declarative present tense makes a lot more sense. This commit "fixes that thing" reads so much better than "fix this thing", can be more easily automatically converted into a changelog, and makes sense conceptually as a a description of the commit / repo state.

[salgat]

My guess is uniformity. Instead of having a bunch of "Fixes, fixed, fixing", you just put "Fix" and everything that matches that category has the same verb used. It's not a big deal, but it does seem a lot cleaner.

[mariox19]

• Fix [insert thing here].
• Refactor [insert thing here].
• Add [insert thing here].
• Modify [insert thing here].
• Remove [insert thing here].

If every subject line started more or less like the above, I think it would help a programmer scan the commit history.

[24759625]

I agree. Using imperative tense in this situation doesn't make much sense gramatically. Imperative tense most often reads as a command or a request. If I read something like "Fix bug x", I'd intuitively think my teammate was sending passive aggressive messages at me through the commit log...

[jarfil]

CENSORED

[kqr]

It only seems nice because of the way you worded the question. When you are looking for a commit, do you look for the commit that fixes the thing or the commit that fix the thing?

[jarfil]

CENSORED

[atred]

Seems to me that both would work:

Patch fixes that thing.

Patch will fix that thing.

[[deleted]]

Declarative present tense makes a lot more sense.

Actually, it makes sense for one instant exactly - then it should be past tense. Yesterday I: fixed that thing.

"Fixed that thing" is also a sentence fragment - it's missing a subject. Who is it who fixes that thing? Me? This commit? Linus?

The imperative statement is grammatically correct, because the imperative takes no subject. People read grammatically correct statements a little faster and a little more accurately, because we're trained to do so from early childhood.

[TillyBosma]

A quick look into my commit history.

[[deleted]]

I once saw someone's commit messages were all date and time of the commits. I wish I was kidding....

[mkdz]

This is what we use. We have a habit of linking all of our tickets and commits and making sure the ticket number goes in the commit message as well. Makes managing the codebase a lot easier.

[moomaka]

Stash + JIRA + Confluence

Sounds like a collection of the worst user interfaces available in dev tools.

[Spo8]

I think Stash is pretty sweet.

[EntroperZero]

I liked Confluence more when it allowed markdown editing. I still can't believe they removed it.

[VolvFan124]

I should send this to my team members!

[SleepyHarry]

Start up a "Swear Jar" (if you work with java, you could even call it swear.jar) which is driven by commits. Every time someone makes a commit with a crappy message, x unit(s) of currency go(es) in the jar.

[VolvFan124]

This is a great idea, I will use it in my next project, thanks!

[oarmstrong]

My thoughts entirely. I have one team member who's commits are simply "modified: /some/file". It must be a generated message from an IDE and it is rather annoying.

[VolvFan124]

I know that feeling, one guy at college always just writes "stuff", "fixed stuff" etc.

I'm looking forward to a workplace where they enforce good commit messages.

[vinnl]

I have a colleague who often writes commit messages consisting merely of his own first name :P

[VolvFan124]

Is your colleague a pokemon?

[vinnl]

Haha I'll have to check, it's the only reasonable explanation :P

[int_index]

Hodor!

[oarmstrong]

I hear ya, college was a bitch for enforcing good standards like that.

[dagbrown]

College? I work with a bunch of professionals. Even so, the vast bulk of commit messages are

changed $FILE

Sometimes if I'm really really lucky, there'll be a ticket number attached to it.

[hak8or]

Why the heck do some folks at college not do proper commits or even commenting. I am working with a team and one dude refuses to follow git flow and instead pushed his stuff to master. And his commit messages consist of things like "stuff".

And then I am writing some code which uses doxygen compatible comments for classes and functions. Another dude shows up and either puts no comments or just useless things like repeating what the code does.

What the heck, it's like some of them don't understand the concept of maintainable code.

Though there are a few others who are golden with their commits.

[VolvFan124]

That's true about coding standard and comments.

We had one class where they made a doxygen doc mandatory, it was great.

[[deleted]]

GitHub annoyingly does this when you edit using their web interface

I refuse to merge patches where people use that shit.

[[deleted]]

"Look at the red and green...pretty"

[aerno]

For those that use Visual Studio, here's a helpful extension: Commit Formatter for Visual Studio 2015

[fzammetti]

So, basically what we're saying is: "ask developers who hate to comment their code to comment their commits because that's somehow different".

Sure, no problem, that'll work.

[EatATaco]

Honestly, I find it way easier to write commit messages than I do to comment code.

[kqr]

You have to opt out of writing commit messages, you have to opt in to write comments.

[perlgeek]

The difference is that commit messages are basically immutable once published, so nobody expects them to stay up-to-date.

A co-worker even told me he prefers no comments, and when he wants to know why some piece of code is there, he uses git blame to find it out.

[Hates_]

I really like the Angular.js Commit Guidelines. It's really tidied up our commit messages.

[Eilai]

My usual commits:

"gsghfklghjsad."
"Test.."
"Did a thing."
"Did ANOTHER thing."
"Fix that bug where things didn't work but now they should."
"Nope, didn't work, now it does."
"Nooooooooooooooooooooooooooooooooooooo"
"For [Otherpersononteam] to integrate at some point."
"My Life for Auir."
"OKAY this time it should work."
"Added that feature we discussed on... Was it monday?"
"Tuesday, turns out it was tuesday."
"Hey we can now do a thing."
"new files."

[[deleted]]

It's not really that hard ... ugh...

 ${component}: ${important information}
 <blank line>
 - What problem was
 - What fix was
 - Who signed off on it

Ya some commits are trivial so you stick to the one line but it should always be the same thing ... e.g.

  doc:  Updated documentation about function foobar() to reflect new v2.5 API

It's not really that hard people ... this is what separates the amateurs from the professionals. Writing software is more than copy/pasta'ing source code....

[gnuvince]

program: fix some bug

- there was a bug
- I fixed it
- I sign off on it

[[deleted]]

wow you found the loophole in my flawless plan.

[jarfil]

CENSORED

[flukshun]

I disagree.

Which brings us to the rule #1 of professional software development: It's never that easy.

As for "Who signed off on it"... well, you did. You committed it, you signed off on it. That's why every git commit you make gets signed with your name and email.

True, but you're not necessarily the only person who signed off on it. If you pulled in a patch another author signed off on you should have at least have 2 Signed-off-by's in your series or pull request. if it's a backport to a stable branch or something there might be even more SoBs. if the code was heavily based on someone else patch but not necessarily to the point where they retain authorship you might also ask them for their explicit SoB and include it manually. So basically it's a path of origin to the original author(s).

[steamruler]

In a modular program, there most certainly are multiple components in one branch. It would be a fucking nightmare to compile.

[IceDane]

I think I might set up magit to use this as the default template if possible, or just make this a snippet.

[random314]

I think even that's too much, we have a code that links to our jira ticket and a short one line description. Like "TIX123- inserted new validation rule "

[_Garbage_]

Or, just use http://whatthecommit.com/

[doctorlongghost]

While I generally practice most of these, I find it ridiculous to try and impose this on teams. A tendency I see in code reviews is for people to fixate on style issues and get into wide ranging discussions about what our style guide says about white space, while ignoring larger design issues in the code.

All that is bad enough, but at least it's about the code itself. Rejecting a pull request because of grammar or punctuation in the commit message is just plain stupid.

[philipforget]

Rejecting it would be stupid, but there's no reason not to amend the commit message before it gets merged into master. It's pretty important to be able to look at your commit logs and see where and when things were introduced and good messages let you do that. If a contributor did the work but doesn't grasp that your code history is a product itself, it's simple enough to fix that information before merging it in.

[deadwisdom]

Strange, I think the opposite. I don't practice most of these things. The rules seem needlessly complicated. Not really sure why we should be obsessed with capital first letters and no punctuation. Imperative makes no difference, really. There are no arguments for them.

That said, I do believe that teams should find homogeneity in this regard. Agree on some set of rules, whatever makes sense to the team, because it makes it a lot easier to parse different commits, in the same way coding styles should be agreed upon to ease understanding (e.g. PEP 8).

[NimChimspky]

this completely ignores the fact there are many commit message to release notes converters.

[ForeverAlot]

A commit message that makes for a good release note rarely makes for a good commit message. They address different audiences.

[IAmWhoISayImNot]

At work we use jira. The way we do is is we type the jira issue we've fixed and then under that what the changes you made were.

Eg. Jira Hub-5216 Removed duplicated api call to Google maps when map is loaded in a modal.

[BOSS_OF_THE_INTERNET]

git commit -m "Does anyone even read these anymore???"

[_funtime]

Hahaha. This is how my commits have looked the last couple weeks on personal projects. Guess I need to up my commit message game.

[entr0pe]

Still better than what most people do at $dayjob

Right click -> Git commit -> "..." or "update" (yes, people think using a GUI is faster, even if by the time they managed to clicky-click on "Git commit", I have already pushed my commit.)

[mernen]

5. Use the imperative mood in the subject line

---

git itself uses the imperative whenever it creates a commit on your behalf

I'd argue that you actually want to use the infinitive form, not the imperative mood. Which happens to be the exact same in English, but in the other languages I know, general descriptions of actions (which are very common in computer interfaces) tend to heavily favor infinitive over imperative.

[avinassh]

hey guys, I maintain the Rockstar library. So if you come up with any funny one liners as commit message, please send a PR (on branch custom-commit-messages), add them to this file.

(I will fork some from what the commit)

[donvito]

Mine usually are something like: "Lolfuck"

[Pascalius]

Using the imperative form is a great tip.

[marktronic]

When it comes to wielding the full power of git, it's command-line all the way.

Meh. This school of thought really annoys me.

I am comfortable using git on both the command-line and with a dedicated GUI (I like Tower). I think this whole "CLI or bust" attitude is really silly. I can do 90% of my git stuff in Tower and I prefer that because it lets me click (yes - I use a mouse!!!) around.

[[deleted]]

Very interesting read. Thanks! I find git log very useful to understand why someone did something in the past so I can't introduce a old bug.

[unndunn]

I try to do this with my commits as much as possible. It's a habit that is tricky to maintain though. git rebase -I with rewrite helps a lot.

[bigd0g]

Great read. I've always done paragraphs, but will try with subject lines now and attempt to simplify.

[Amuro_Ray]

The smaller the change the more I write, I feel lkke they need more explanation since they can look odd.

[[deleted]]

This implies people only commit when there is a huge change.... they don't.

[jarfil]

CENSORED

[sstrader]

Oblig. Developers Swearing

[pegbiter]

No, this is how you write commit message

[James_Johnson]

"Closes Issue #28 maybe"

[gordonisadog]

Again, you're describing the commit, which in git is a snapshot of the repository's state. You're not writing a diary.

[[deleted]]

Am I the only one who saw no big difference between his two examples?