Learn Git in the Browser

https://try.github.io/

by markcrazyhorse • 12 years ago

86 44 12 years ago

try.github.io

llomlup• 12 years ago

Nice tool. I keep suggesting it to people wanting to learn git.

_deh• 12 years ago

This is good as well: http://www.win-vector.com/blog/2012/07/minimal-version-contr...

geerlingguy2• 12 years ago

On an iPad, I just get a blank white screen... Does the site use flash, or is there a problem right now?

olivierlacan11• 12 years ago

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.

geerlingguy2• 12 years ago

No problem; I finally had time to open it up on my laptop, and it works fine in Chrome and Safari. I understand not doing any major updates for mobile/tablet users, but if would be nice to at least be able to see something :)

jafaku2• 12 years ago

What the heck is an octobox? Do you really want a git tutorial to use github-specific terms like that?

olivierlacan11• 12 years ago

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

j2kun4• 12 years ago

It would be nice to explain what it means. Try googling "octobox" :)

tpsc• 12 years ago

Looks good. Another option: https://www.git-tower.com/learn/ebook

millzlane• 12 years ago

I'm no designer but I would move the 'Advice' section to the top of the page below the command. I didn't notice the lower right hand side of the screen kept changing.

I feel like I was just doing what I was told rather than learning. Is this more for individuals with SCM experience or beginners?

olivierlacan11• 12 years ago

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.

lukasm• 12 years ago

Shouldn't git add -A be used as default instead of git add . ?

olivierlacan11• 12 years ago

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.

olivierlacan11• 12 years ago

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.

mikeharmer• 12 years ago

Found this a really useful introduction to Git, thanks!

olivierlacan11• 12 years ago

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

amwelles• 12 years ago

We used this tutorial at a Girl Develop It workshop last year. It worked really well! I also learned jQuery via Code School on my own time the year before that. Keep up the good work!

GnarfGnarf• 12 years ago

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• 12 years 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• 12 years 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_someone3• 12 years ago

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.

as_someone3• 12 years ago

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/ for convenience.

nicolethenerd• 12 years 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/ - 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)

j2kun4• 12 years ago

I've always found the git CLI really odd. For example, when doing a git diff, how would anyone use the following information that gets printed out?

new file mode 100644

index 0000000..cfbc74a

And you have all of these symbols that show up in the diff like "+[m" before a new line (why not just +?). I imagine there are good reasons for all of this, but I also feel like some of this should be hidden behind a --verbose flag or something.

eggnet• 12 years ago

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

phaker• 12 years ago

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.

as_someone3• 12 years ago

j2kun means the stuff that shows up from TFA when using git diff:

  diff --git a/octocat.txt b/octocat.txt
  index 7d8d808..e725ef6 100644
  --- a/octocat.txt
  +++ b/octocat.txt
  @@ -1 +1 @@
  -A Tale of Two Octocats
  +[mA Tale of Two Octocats and an Octodog

prezjordan• 12 years ago

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

j2kun4• 12 years ago

So the use case is primarily to produce something machine readable rather than human readable (it's not that unreadable, but still). I can see that. Is there a human-readable flag?

xxbondsxx2• 12 years ago

Shameless self promotion:

http://pcottle.github.io/learnGitBranching/?demo

I found the try.github.io tutorial very underwhelming -- it emulates enough of git to just fall into the uncanny valley. I also prefer visual learning -- hence I made the above!

steamer25• 12 years ago

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

xxbondsxx2• 12 years ago

You're welcome! as well as mendelk and ahurmazda below -- glad you all found it useful (and my self-promotion wasnt too annoying) :D

mendelk• 12 years ago

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

ahurmazda• 12 years ago

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!

dnlserrano• 12 years ago

Cool for learning Git. However, not that great for the first time somebody uses a version control system.

Does anybody have a good tutorial for "Code Version Control for Dummies (while using Git)"?

xfalcox• 12 years ago

Just sent this to a new co worker who just got into her first programming job. It's a great resource that helped me when I was starting.

Learn Git in the Browser

Related Stories