Learn Git in the Browser

Thanks for the great tutorial! It definitely helped my understanding when I went through it.

I just wanted to chime in here to thank you for this. I found it very helpful, even after I did the CodeSchool course.

okay, I just spent my lunch time going over the tutorial. It makes me happy (and very thankful) that people like you are taking the time to create such great resources. Kudos!

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.

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.

Use Mercurial.

There's 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 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.

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/ - 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)

Hmmm, I think you're right. That's less dangerous, especially when people don't really know what they're doing. I'll push an update.

That said . should be specified per manpages:

> If no <pathspec> is given, the current version of Git defaults to "."; in other words, update all files in the current directory and its subdirectories. This default will change in a future version of Git, hence the form without <pathspec> should not be used.

An update to the advice is going up that will show `git add -A .` instead of `git add .` and explain:

> You can also type `git add -A .` where the dot stands for the current directory, so everything in and beneath it is added. The `-A` ensures even file deletions are included.

Having git emit, by default, a diff that can't reliably be used by git to patch another repository seems ill advised.

Do you mean you get '+[m' instead of '+' in front of an added line? If so, this looks suspiciously like ecma formatting escapes (\e[XXXm).

Try if calling git diff --no-color, if this helps then something is broken on your setup. Another way i could see that happening is if you have color set to 'always' and then use some app that wraps git's command line output.

Because git-diff produces a full patch [1] that can be applied to a file. It's a lot more than just showing lines added/lines removed. The two hashes are useful because it shows what two objects are being compared. It's the same as saying "Change #12 vs Change #13" (not really, but sorta).

[1]: http://linux.die.net/man/1/patch

Absolute beginners.

Our advice box is something for people who want to learn more, it's not essential enough to be below the command before the output.

We released this on July 4th 2012. I can't remember if we tested it for tablets & phone but generally I recall the jQuery Console plugin not being too fond of either. It's only more recently that console/editors have become more responsive to different environment/viewports.

To summarize, this is not a load problem, it looks like a display bug. We'll look into it but I can't promise this will work on your iPad anytime soon, sorry.

GitHub sponsored it, and I like picking fun examples. Is that so offensive?

Glad you think so Mike. Did you have version control experience or Git experience prior to it?