DEV Community

Cover image for git commit -m "_____"
Michael Lee 🍕
Michael Lee 🍕

Posted on

git commit -m "_____"

Alt Text

A: 🎉
B: test
C: initial commit

Or suggest your own answer.

Top comments (37)

Collapse
 
cathodion profile image
Dustin King

git commit -m "I think I figured it out"

git commit -m "I didn't figured it out"

Collapse
 
stargator profile image
Stargator

I would have also accepted:

git commit -m "This time I figured it out"

Collapse
 
leojpod profile image
leojpod
# From https://github.com/ngerakines/commitment/issues/69#issuecomment-91053061
git config --global alias.yolo '!git add -A && git commit -m "$(curl --silent --fail https://whatthecommit.com/index.txt)"'
Collapse
 
michael profile image
Michael Lee 🍕

What does this do?

Collapse
 
leojpod profile image
leojpod

commit whatever changes you have and use one of the random messages from whatthecommit.com/

Collapse
 
stargator profile image
Stargator

git commit -m "Genesis 1:1"

git commit -m "Let there be Light"

git commit -m "Let there be _____" (insert your own)

git commit -m "This is going to take more than 6 days"

Collapse
 
nicolasdanelon profile image
Nicolás Danelón

love you already

Collapse
 
praneetnadkar profile image
Praneet Nadkar

git commit -m "Fixed it"

git commit -m "Fixed it for real this time"

git commit -m "Damn. Fixed"

git commit -m "Fix it for real"

git commit -m "Finally"

git commit -m "Build fails"

git commit -m "F**kin regex!"

Collapse
 
michael profile image
Michael Lee 🍕

🤣

Collapse
 
bootcode profile image
Robin Palotai • Edited

git commit -t emptyfile

Then I write a proper commit message in the editor. Mostly.

Put a commit msg template in your repo instead emptyfile if you like that better. Add a bash alias.

Edit: ah, I missed the joke?

Collapse
 
michael profile image
Michael Lee 🍕

Oh wow I did not know that the -t option even existed. Do you know of any resources @bootcode that is similar to what your template workflow looks like?

Collapse
 
bootcode profile image
Robin Palotai

Happy it helps. No specific commenting workflow. Interestingly there are hits
out there about git comments, but they mostly cover formatting. That's nice
(and do read definitely), but the focus should be on content first, formatting
second. I can live with the title ending in a dot, sorry :)

What is more interesting is the content of the message. If we are limited to a single line (as with -m), too much interesting detail gets lost.

The commit message should give context for the unfamiliar reader. Imagine someone searching for the cause of a bug, going through all changes made in a given interval. A good commit message can reveal if there's something relevant in there or not.

The message should include:

  • First line with brief description of change.
  • Purpose of the change.
  • Broader context of the change.
  • Follow-up work to expect.
  • How the reviewer can try the change
    • command for batch stuff
    • demo url or screenshot for UI changes
  • How the change was tested (if not apparent from CI)

For example:

Add initial support for undotted section numbers.

This change lets us roll out support for FooBarQuux documents in English.
Normally section numbers in FooBar documents are followed by dots. But in
FooBarQuux, there's a special convention to make section numbers undotted.

Note: the undotted numbers increase monotonically and don't get reset by
intertwining higher-level headings. While not forbidden, Table Of Contents
consumers might not expect this situation. So rollout should be gradual to
catch any errors.

This is part of the broader effort tracked in bug/55443 about migrating away
from plain FooBar documents.

Follow-up change will add support for three more languages, also increase test
coverage. Once German is supported, bug/12345 will be unblocked.

I also added a tool for quick experimentation on the test corpus. Example
usage:

    bazel build //foo/bar:quux
    ./bazel-bin/foo/bar/quux --input_dir=/bog --language=en --summary_only

TESTED=checked corpus with tool, ran integration tests

The commit message also acts as a test of the rationale. It happened to me multiple times that I took 2 hours writing a change, then while phrasing the rationale part of the commit message it dawned on me Ouch. Actually this is not the right approach for that purpose.

As for a general git usage model, I use the nvie model with content.

If you would like to hear more of such info, don't forget to follow me here directly, or subscribe to updates about my book Programming Without Anxiety.

Collapse
 
abhishekcghosh profile image
Abhishek Ghosh

git commit -m "wip"

Collapse
 
sarunint profile image
Sarun Intaralawan

chore: initial commit

Conventional Commits

Collapse
 
amc2010 profile image
Rob

Initial commit, because sometimes I run out of opening lines

Collapse
 
hozefaj profile image
Hozefa

Have whatever messages you want. While merging the PR, you can squash the commits and actually even change the message itself in github.

Collapse
 
trjones1 profile image
Tramel Jones

(68 files added)

Looks at project - 1 Folder....

What Have I done

Collapse
 
ahmet profile image
Ahmet Çadırcı

All messages from this project: "revised"

revised

Collapse
 
tchaflich profile image
Thomas C. Haflich

git commit -m "actually fixed everything"

of course, this is from when you had a commit earlier where you "fixed everything"

Collapse
 
zymawy profile image
Ironside

git commit -m "Added Feature"

Collapse
 
audioboxer217 profile image
Scott Eppler

I like:

git commit -m 'Make it work

for now.'

On a serious note, I always start each new repo with

git commit --allow-empty -m 'root commit'

before I do anything at all.

Collapse
 
christiandrotor profile image
Noel Drotor

Git commit -m "to nothing"

I have commitment issues lol