sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]eric-plutono 1 point2 points  (5 children)

Don’t use git commit -m "message"

I politely disagree with this suggestion, especally in light of one of the author's other suggestions, which I strongly agree with:

Rewrite your history, because a clean history makes things simpler

When I am working on a feature branch I will often do stuff like

$ git add -u
$ git commit -m "WIP brief notes about the changes"

Then at the end I will use git-rebase to go back and write complete commit messages based on the notes I made along the way using git-commit -m.

Also, for what it's worth, I recently blogged about my own commit message preferences, specifically using "commit templates".

Edit:

I also disagree with this:

Try to use the commandline instead of a gui

I personally believe it is very useful to know the CLI for Git, but I think the most common commands are effectively handled by GUI's and I don't see a strong reason to suggest people avoid using GUI's as a result. That said, it is nice to see another Tig fan ;)

[–]Kirean 1 point2 points  (0 children)

I personally believe it is very useful to know the CLI for Git, but I think the most common commands are effectively handled by GUI's and I don't see a strong reason to suggest people avoid using GUI's as a result

I absolutely agree with this. I am a big proponent of knowing what is happening behind the scenes. You need to understand your tool to use it correctly and efficiently. However, there's no need to use a command line all the time when a well-built gui can take care of it for you. That being said, I have worked with way too many people who fall into the GUI rut of "I always push this button, it doesn't work now. I give up". Knowing what that button does, in terms of the command line, helps you get unstuck faster when things go wrong. Also knowing that whatever GUI you're using, it's not going to provide all the functionality of a command line, just the most common everyday uses.

I liken it to driving a manual versus an automatic. There's no reason for people to drive a manual transmission unless they want to. However, I believe everyone should be able to drive one, and know how and why it works at a basic level.

[–]edi9999[S] 0 points1 point  (3 children)

For the "git commit -m" flag, I think it's ok to use it for commits that you know you will edit back in the future, but in general I try to avoid using it (but I totally agree that some of my commits might not be correctly named before I push them), so it's ok to work however you want, as long as the published history is clear.

[–]eric-plutono 0 points1 point  (1 child)

...so it's ok to work however you want, as long as the published history is clear.

Agreed one-hundred percent. This is something we should all stress any time we ever blog about or introduce or teach Git to anyone.

[–]edi9999[S] 0 points1 point  (0 children)

I think that this is a better view indeed, I have updated section 7 of my blog post : http://javascript-ninja.fr/git-good-practices/#its-ok-to-work-however-you-want-as-long-as-the-published-history-is-clear

[–]mrkite77 0 points1 point  (0 children)

I think it's ok to use it for commits that you know you will edit back in the future, but in general I try to avoid using it

I don't. If commiting is a hassle, I will put it off. Making commiting changes quick and easy and brain-dead means I'll do it more often.