[OmarIsmail]

I think the author does say something negative about git, just doesn't say it in a negative way. "When a git user runs into a problem, they look at the tools they have on hand and ask, “how can I combine these ideas to solve my problem?”"

The negative here is that A) git user has to know about all the tools, which takes a long time, and then solving the issue requires quite a bit of thought.

That's one of the problems about git is that as a result of the massive flexibility there doesn't seem to a "standard" way to do things, even basic things. Each org has to develop their own processes which is annoying and difficult for new people in the org.

[gcp]

I wouldn't mind some of the big users of git summarizing the "best practices" they arrived at in a nice presentation.

[SethRobertson]

Here is a document describing git best practices which has been liked by some of the most knowledgeable git users out there.

Commit Often, Perfect Later, Publish Once: Git Best Practices https://gist.github.com/1540906

[dmoney]

For large projects, there is git-flow: https://www.google.com/search?q=git-flow

I remember someone posting a recommended workflow for smaller projects, but I don't remember what it was called.

[lysium]

github uses a different flow. This article mentions the issues with git-flow and describes the flow used at github:

http://scottchacon.com/2011/08/31/github-flow.html

[gizzlon]

another negative sentence: "you can just point the branch pointer back at the previous commit with git reset --hard HEAD@{1}"

just? Wtf is HEAD@{1} ?

That might be simple, but as usual, only if you know a lot about git.

As a casual git user this annoys me; Even when doing basic stuff I often have to read a long blog-post about how git works internally. I can't remember having this problem when I was a casual Mercurial user.

[beaumartinez]

Run git reflog—HEAD@{1} is (at least as I understand it) "the state HEAD was at 1 commit ago"—including things such as rebasing and reverting.