

Git your act together - jkreeftmeijer
http://jeffkreeftmeijer.com/2010/git-your-act-together/

======
snitko
I don't really get people using _git commit -m_. I never do that. I always use
just _git commit_ and write my commit messages in vim that opens up in the
same terminal.

First of all, it allows you to easily write extended commit messages (just
leave the second line blank and start writing the extended message on the
third line). A good idea would be to leave _(#more)_ anchor at the end of the
first line, so that others would know there's actually some more info they
might want to read.

Then you can always see the files currently being committed while you're in
the editor, that's convenient. Last but not least - it helps me take my commit
messages seriously.

~~~
astine
Occasionally I'm using a terminal which can't open an editor for one reason or
another. In those situations I use -m.

~~~
koenigdavidmj
If you need more than one line, you can say

    
    
        git commit -F -
    

to specify that the commit message should be read from standard input.

------
hammerdr
Commit messages are important. You should convey what you did.

Commit messages are important. You should make them fun to read.

------
mattmichielsen
I actually enjoy witty and clever commit messages. Just the other day one of
my coworkers really enjoyed a commit message where I wrote "upgrayedd" instead
of "upgrade".

~~~
benatkin
My guess is that the idea to put that in the commit just came to you. So you
didn't necessarily go against his advice:

> Don’t try to be clever, witty or funny.

I've worked with someone who _did_ sit around thinking what to put in a
commit, and believe me, he didn't commit as often as he should have.

~~~
mattmichielsen
No, it was pretty spontaneous, as the particular individual who typically
works with me on that project and I were having a conversation about Idiocracy
just hours prior to that.

------
djcapelis
Woah I didn't know about git commit --amend, that's really cool!

~~~
a-priori
Also for more severe rewriting of the history check out "git rebase -i <base
commit>". You'll be shown a list of commits between the base commit and the
HEAD in your editor. From here you can rearrange and delete commits, and mark
them for editing and squashing.

I use this all the time for cleaning up topic branches before I push them out.

------
telemachos
I don't always commit as often as I should, but ever since reading Ryan
Tomayko's "The thing about git"[1], I use _git add --patch/-p_ to solve the
problem of overlarge or mixed commits. It allows you to snip out pieces of the
changed files to add, rather than adding the entire file at once. (Perhaps
everyone already knows this, but I used git for months without knowing it. So
maybe I'll save someone else.)

[1] <http://tomayko.com/writings/the-thing-about-git>

~~~
wonsungi
I agree Tomayko's method is very helpful, but I came to the conclusion it's
better to just commit as often as possible.

\- Multiple changes that affect the same line(s) are very difficult to pick
apart.

\- It is easier to write a meaningful commit message while the change is fresh
in your head; otherwise a lot of time is spent reviewing your changes.

------
crazydiamond
Nice explanation of "git rebase" for combining small commits into one large
one.

edit: about funny commit messages :-D

> Newsflash: You’re not funny, you’re being an idiot. :)

------
samstokes
_Seriously. Just commit one thing at a time. Don’t wait until you go home,
don’t fix three really simple bugs before committing, commit every single
change separately._

This is important. Nothing fills me with dread like a commit message that says
"fixed NullPointerException in renderer (also a few whitespace changes)".

------
tomstuart
Argh. Don't put a period at the end of a commit message; it's like an email
subject line.

~~~
uxp
Email subject lines are by convention a short explanation of the message.
Commit messages, regardless of the SCM, should be the same. The difference
with git, and what I inferred from this article, is that commit messages
should be verbose. It should be a way for someone to figure out that "bug
#33423 has been fixed. Opening files now executes in the proper thread." for a
very short message that gets the point across.

If one doesn't have bug tracking software to go to and read about why the
commit was done, then it should be much more verbose: "Opening files on a
select box executed in the wrong thread. Looks like it erred during startup,
where we can't yet fork the process. This patch mitigates the selection box
during startup by checking to see if we can fork into our proper thread or
not. If we can't, we wait until it becomes available."

There is no reason a commit message cannot be a novel unto itself. And
something like that will require a period at the end. If you're trying to
limit yourself to a single sentence, or something that can be fit into a
tweet, you're only hurting yourself.

~~~
tomstuart
See [http://tbaggery.com/2008/04/19/a-note-about-git-commit-
messa...](http://tbaggery.com/2008/04/19/a-note-about-git-commit-
messages.html), <http://gist.github.com/539516> etc.

------
bcl
Sounds like a good article. Too bad he had to wrap it in a stupid blog theme
that is as narrow as my iPhone display.

Once you discover git rebase -i you will never go back!

------
chrismealy
So that's what rebase is for! Thanks.

~~~
steveklabnik
Rebase is a tool to rewrite history. This is just one small part of the things
you can do when messing around with your history.

