62 ms·

Thanks for the tutorial. I appreciate that Git is complex and powerful, but I didn't need a tutorial for Subversion. Git is baffling. The error messages are cry

Thanks for the tutorial. I appreciate that Git is complex and powerful, but I didn't need a tutorial for Subversion. Git is baffling. The error messages are cryptic and unhelpful. It deters the casual user. Can I suggest a list of the absolute, bare-bones minimum set of commands for a project where there will be no merging, just uploading by one person, and downloading by others?

erikb 12y ago
I think if you spend more then 5 hours a week coding you should definitely get in depth knowledge. Git is different from classical version control system, which makes it hard to learn (e.g., why first commit and then push?) But when you get the hang of it most of it actually makes sense and you start to become more productive with git then you have ever been before. The trick is not to stop learning before you get about 80% of what's out there in your head. People who spend less then 5 hours a week coding probably don't need git and I think it's stupid that people replace SVN everywhere with git. Git's power is the power user and the shell. I can only suggest to use GUI tools in that case. They don't allow you to do anything but its harder to break things as well. The problem here is not git though. At least not in my mind. The problem is that many people who don't know git very well try to apply it to use cases which are not git's strength. In any case your concerns are valid. If I disagree at all it's with the path to solution.
noselasd 12y ago
Personally I would like git tutorials to include a lot more of common mistakes, and what to do when things go wrong. Getting up to speed with the basics of git for basic version control, branching/merging is fairly straight forward. It's when things don't go as planned it's easy to feel trapped in a corner. e.g. did a git pull that causes a merge, how to undo that step and do a git pull --rebase instead. How to dig yourself out of doing a git merge in the wrong branch. How to revert the 4th last commit only etc.
as_someone 12y ago
Use Mercurial. There's http://hginit.com http://hginit.com. Given your comment about "I didn't need a tuturial for Subversion", though, maybe you'll find that inadequate, too. As someone who tried using SVN before ever touching hg or git or its forebears, I found SVN baffling. To me, the DVCSes make sense. HgInit's "Subversion Re-education" page says: > Mercurial separates the act of committing new code from the act of inflicting it on everybody else. The fact that this isn't the case in SVN is mystifying to me. I still struggle with git. In fact, I don't use it, largely because I still don't know how to use it. Note how I said that "the DVCSes make sense". I say that, because I can read "Understanding Git Conceptually" <http://www.sbf5.com/~cduan/technical/git/>--which http://www.sbf5.com/~cduan/technical/git/>--which a number of HN commenters have posted before--and I get it. The problem is not that I don't understand the concepts backing git. It's that I don't understand how these concepts map onto git's infuriatingly obtuse UI. So use Mercurial. Because, a) it's better (read: nicer to use), and b) when you use Mercurial, it comes with the benefit that you're helping inoculate the dev world against a DVCS monoculture. If it helps, know this: I write as someone whose use case is largely the one you outline. I mostly find myself working alone, on a side project of mine where I'm the only committer. # Crystallize your changes in a revision marked with your # commit comment: hg commit That's it, pretty much. Occasionally you'll need to do an hg addremove to make sure Mercurial isn't ignoring any new files you've introduced (hg add and hg remove if you want to do things manually), and an hg mv whenever you need to move things around. Everything ramps up pretty sensibly and steadily from there, so that you're really only spending the mindspace to pay for the features you're really using. For example, if you have a public-facing repo: hg push # read as "publish", if it helps. Do this, occasionally preceded by an hg out (when you find that you want to see what you'll be pushing), and you're good to go.
- as_someone 12y ago
  > http://www.sbf5.com/~cduan/technical/git/>--which http://www.sbf5.com/~cduan/technical/git/>--which ... aaaaand HN is busted, and won't update the post when I try to edit that to fix the link. That's http://www.sbf5.com/~cduan/technical/git/ http://www.sbf5.com/~cduan/technical/git/ for convenience.
nicolethenerd 12y ago
It's not exactly what you're asking for, but I wrote a blog post that details the steps for creating a repo and hooking it up to github - http://nycda.com/blog/how-to-create-a-git-repo/ http://nycda.com/blog/how-to-create-a-git-repo/ - I cover two methods - creating a repo locally first and connecting it to github, and creating a repo on github first and cloning it so you have it locally (personally, I always do the latter - I think it's simpler, but for completeness' sake I included both)

erikb 12y ago

I think if you spend more then 5 hours a week coding you should definitely get in depth knowledge. Git is different from classical version control system, which makes it hard to learn (e.g., why first commit and then push?) But when you get the hang of it most of it actually makes sense and you start to become more productive with git then you have ever been before. The trick is not to stop learning before you get about 80% of what's out there in your head. People who spend less then 5 hours a week coding probably don't need git and I think it's stupid that people replace SVN everywhere with git. Git's power is the power user and the shell. I can only suggest to use GUI tools in that case. They don't allow you to do anything but its harder to break things as well. The problem here is not git though. At least not in my mind. The problem is that many people who don't know git very well try to apply it to use cases which are not git's strength. In any case your concerns are valid. If I disagree at all it's with the path to solution.

noselasd 12y ago

Personally I would like git tutorials to include a lot more of common mistakes, and what to do when things go wrong. Getting up to speed with the basics of git for basic version control, branching/merging is fairly straight forward. It's when things don't go as planned it's easy to feel trapped in a corner. e.g. did a git pull that causes a merge, how to undo that step and do a git pull --rebase instead. How to dig yourself out of doing a git merge in the wrong branch. How to revert the 4th last commit only etc.

as_someone 12y ago

Use Mercurial. There's http://hginit.com http://hginit.com. Given your comment about "I didn't need a tuturial for Subversion", though, maybe you'll find that inadequate, too. As someone who tried using SVN before ever touching hg or git or its forebears, I found SVN baffling. To me, the DVCSes make sense. HgInit's "Subversion Re-education" page says: > Mercurial separates the act of committing new code from the act of inflicting it on everybody else. The fact that this isn't the case in SVN is mystifying to me. I still struggle with git. In fact, I don't use it, largely because I still don't know how to use it. Note how I said that "the DVCSes make sense". I say that, because I can read "Understanding Git Conceptually" <http://www.sbf5.com/~cduan/technical/git/>--which http://www.sbf5.com/~cduan/technical/git/>--which a number of HN commenters have posted before--and I get it. The problem is not that I don't understand the concepts backing git. It's that I don't understand how these concepts map onto git's infuriatingly obtuse UI. So use Mercurial. Because, a) it's better (read: nicer to use), and b) when you use Mercurial, it comes with the benefit that you're helping inoculate the dev world against a DVCS monoculture. If it helps, know this: I write as someone whose use case is largely the one you outline. I mostly find myself working alone, on a side project of mine where I'm the only committer. # Crystallize your changes in a revision marked with your # commit comment: hg commit That's it, pretty much. Occasionally you'll need to do an hg addremove to make sure Mercurial isn't ignoring any new files you've introduced (hg add and hg remove if you want to do things manually), and an hg mv whenever you need to move things around. Everything ramps up pretty sensibly and steadily from there, so that you're really only spending the mindspace to pay for the features you're really using. For example, if you have a public-facing repo: hg push # read as "publish", if it helps. Do this, occasionally preceded by an hg out (when you find that you want to see what you'll be pushing), and you're good to go.

as_someone 12y ago
> http://www.sbf5.com/~cduan/technical/git/>--which http://www.sbf5.com/~cduan/technical/git/>--which ... aaaaand HN is busted, and won't update the post when I try to edit that to fix the link. That's http://www.sbf5.com/~cduan/technical/git/ http://www.sbf5.com/~cduan/technical/git/ for convenience.

nicolethenerd 12y ago

It's not exactly what you're asking for, but I wrote a blog post that details the steps for creating a repo and hooking it up to github - http://nycda.com/blog/how-to-create-a-git-repo/ http://nycda.com/blog/how-to-create-a-git-repo/ - I cover two methods - creating a repo locally first and connecting it to github, and creating a repo on github first and cloning it so you have it locally (personally, I always do the latter - I think it's simpler, but for completeness' sake I included both)