4 ms·

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 th

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 15y ago
I wouldn't mind some of the big users of git summarizing the "best practices" they arrived at in a nice presentation.
- dmoney 15y ago
  For large projects, there is git-flow: https://www.google.com/search?q=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 15y ago
    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 http://scottchacon.com/2011/08/31/github-flow.html
- SethRobertson 15y ago
  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 https://gist.github.com/1540906
gizzlon 15y ago
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 15y ago
  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.

gcp 15y ago

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

dmoney 15y ago
For large projects, there is git-flow: https://www.google.com/search?q=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 15y ago
  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 http://scottchacon.com/2011/08/31/github-flow.html
SethRobertson 15y ago
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 https://gist.github.com/1540906

gizzlon 15y ago

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 15y ago
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.