

Got 15 minutes and want to learn Git? - motowilliams
http://try.github.com/
An in-browser github tutorial powered by codeschool
======
dpcan
NOTE: This is not a rant, I'm just trying to give you a peek into my mind as I
tried out this tutorial. I'm doing my best to describe my confusion.

I have no clue how to use Git, and I've been trying to wrap my head around it
for a while. Unfortunately, this is yet another tutorial that is very
frustrating even though it's designed to target noobs like myself.

So, I added octocat.txt to my staging area. Success! ... Wait. Why do I care?
What did I do? Staging what, for what? Huh?

I committed some random text. Or something. And I typed "-m". So does "git
commit -m 'something random'" actually do something? What did I commit to?
Arrrggg. Why did I -m !?

Then there's this one: git commi­t -m 'Add all the octoc­at txt files­'

So it understands plain English? Was that the random text? Is that just some
sample text as part of the Tutorial or does that actually work on Git? Oh man,
I'm now more confused than when I started.

...

Anyway, for some reason, everyone who tries to describe Git already has such a
strong understanding of it and it's oddities, that they are, for some reason,
unable to lay it out properly for a noob IMO. I cannot figure out how anyone
figures out Git, I assume there was some serious hand holding, because I'm
just not grasping it and I usually "get" this stuff rather quickly. Maybe
that's the problem, Git isn't something you can just pick up quickly, maybe I
need to buy a huge Git how-to book like the old days.

Sincerely, Frustrated in Programming Land.

~~~
rajat
I sympathize. What is really necessary are not tutorials on how to use Git--it
isn't that hard, after all, for most of us--but more of a description of
actual workflow. Not HOW you issue Git commands; but how to use Git.

It would be interesting to read articles about how a single programmer uses
Git, how a small programming team, how a distributed team uses Git. Similar
articles about how a team producing art, or text (not programmers) use Git.

There's plenty of Git command tutorials already; let's hear about how you
actually use Git.

~~~
kalid
I completely agree. If it helps, I wrote up some visual tutorials about
version control in general that many have found helpful:

[http://betterexplained.com/articles/intro-to-distributed-
ver...](http://betterexplained.com/articles/intro-to-distributed-version-
control-illustrated/)

The idea is to build a mental model about _what is possible_ vs. memorizing a
bunch of specific commands. Once I wrapped my head around the concepts, the
commands fell into place.

~~~
gizzlon
Looks good!

On my screen the text is light gray on white. Is that intentional?

~~~
kalid
Whoops! Thanks for the comment, the text should be a readable black on white
(like this: [https://skitch.com/kalidazad/er7an/intro-to-distributed-
vers...](https://skitch.com/kalidazad/er7an/intro-to-distributed-version-
control-illustrated-betterexplained)).

Which browser were you using? (I just tried FF, Chrome, Safari) Thanks!

~~~
gizzlon
<https://skitch.com/gizzlon/efrsh/screen>

~~~
kalid
Thanks, really appreciate it!

------
forrestthewoods
Can we please stop pretending that Git is simple and easy to learn? If that
were true then there wouldn't be "Learn how to use Git in <X> minutes!" posts
every other day.

The fact of the matter is that Git is incredibly powerful but also complex and
hard to learn. This isn't a bash on Git at all. It's ok! Sometimes complicated
things are just that, complicated.

I believe we'll have better guides and tutorials if people stop treating Git
like it's easier or more simple than it actually is.

~~~
amix
I haven't read any books or longer tutorials on Git. I find it easy to use and
if I run into trouble I just Google after help (which happens a few times a
week). Throughout the day I mostly use 9 Git commands. Here are the top 9
commands I use:

    
    
        git checkout X
        git checkout -b new-branch
        git commit
        git add; git mv; git rm; 
        git pull --rebase
        git rebase origin/master
        git push origin X
    

I have used this for a long time without running into huge amounts of trouble
(and if I need to revert back to a specific or do anything special I can
always consult Google). The bottom line is: For simple cases Git is really
simple to use and to learn. You don't need to become a Git master to use Git.

The problem is that people introduce the powerful features of Git that only a
few percentage of people will ever use.

~~~
forrestthewoods
Everything you just said is exactly why Git is not simple and can not be
learned in 15 minutes. Just by operating from the command line you've already
left the realm of "simple" in my opinion. Having to learn 9 commands is not
simple. Having to hit Google for help multiple times per week is not simple.

I strongly, strongly disagree with your assertion that "for simple cases Git
is really simple to use and to learn". I've watched many programmers, artists,
and designers who have used source control struggle with Git from day 1. I'm
sorry, it's just not simple and if it were this topic wouldn't come up over
and over and over.

Again, I say none of this as a slight to Git. Complicated things are
complicated. That's ok, but pretending they aren't isn't helpful.

~~~
philwelch
> Just by operating from the command line you've already left the realm of
> "simple" in my opinion.

Git is a tool for programmers. There's no excuse for a programmer to be
uncomfortable with the command line.

~~~
gurkendoktor
I am a productive programmer and I am absolute uncomfortable with the command
line. I can't count the times I have written

    
    
        svn commit -m "Finally fixed bug #123!"
    

...only to get some weird bizarro error because I should have used '' or
escaped the !. This is usually when I am deeply focused on some programming
language or bug #123.

Tower.app is the only reason I've ever touched git, and the line-by-line
staging and committing is nothing I would ever bother to do with a CLI.

~~~
philwelch
Well, suit yourself. It's just a tremendously useful skill to have. Makes it a
bit less of a hassle to ssh into the odd server to check the logs, or dump a
database, or use tools that don't have a GUI.

I mean, fundamentally, you're typing things to a computer and then the
computer does what you typed. Why should that notion be uncomfortable to a
_programmer_ of all people?

~~~
gurkendoktor
Oh, I _can_ use the terminal, I can also theoretically write PHP, and every
vim user can theoretically use Eclipse. But that doesn't mean that any of us
would be comfortable with it - we'd all be anxious and focused on the tool
(instead of the problem at hand) not to break stuff left and right.

~~~
hkolek
What kind of argument is that? How can you ever learn anything new with this
attitude? If you never leave your comfort zone you will never make any
progress. Just do it.

~~~
gurkendoktor
I have listed things that I _have_ tried out for months. I happen to really
hate these particular three. Now I study other things that I find more worthy
of human lifetime, some of them just as useful to a programmer.

Why can you not accept that someone could possibly hate working with a shell
or git's CLI even after trying them out? I don't get it.

------
msg
It would be nice to get everything on one page. As it is, in my laptop I am
scrolling up and down a lot to see the instructions, the terminal, and the
local filesystem, which are laid out as three rows in one long column.

I did the tutorial mostly without looking at the filesystem so I could stop
scrolling. But I know I missed a few helpful "extra" hints because they were
below the fold next to the filesystem.

On the plus side, it piqued my interest. I've been meaning to get around to
this.

------
p2e
As someone new to git, I was dissapointed to see that:

    
    
        git add "*.txt"
    

added all of the .txt files from the current directory AND all of the .txt
files contained within a subdirectory. I would have expected the same files to
get added as those that would have shown up using:

    
    
        ls *.txt
    

For other new users: I've been told that this is an error in the tutorial. The
tutorial forced the use of quotes but apparently they are not required and git
_would_ have added only the files that show up with the ls command as
indicated above.

EDIT: I'm wrong. Using quotation marks DOES make git fetch .txt files within
subdirectories. As pointed out by cellularmitosis, git seems to do it's own
"interesting" glob expansion.

~~~
kristopolous
Nice Find! I added it to my git-themed twitter account here:
<https://twitter.com/#!/gitHater>

Let me explain what's happening.

What you are looking at is actually part-git, part unix-shell-y.

You did ls * .txt

Let's try something way crazy, type echo * .txt

What do you see? All of your txt files right? But that's just echo, not ls.

Ahh. Here's the clinch. When you do " * ", that's called either shell
"expansion" or "globbing" depending on your shell. Basically, the shell says
"ok, before I run your command, I'm going to look at it and see if I need to
do anything on my end"

This is why you can do

    
    
       $ n=0
       $ echo $n
    

The shell hijacks your input, replacing "$n" with "0", then feeds it into echo

In your example, the shell has hijacked the star in "ls * .txt", replaced it
with all of your txt files, say (a.txt, b.txt) and then ran ls.

That means that ls ACTUALLY got

    
    
       ls a.txt b.txt
    

And THAT's why it works with echo.

\---------

So git add "* .txt" works differently, what gives?

Well, when you put things in double or single quotes you are telling the shell
"hey, don't do your usual stuff here". The single quotes are more extreme. If
we go back to our n=0 example we can try two more things:

    
    
       $ n=0
       $ echo $n
       $ echo "$n"
       $ echo '$n'
    

As you can see, the ' says "relax shell, I have this".

So when you do

    
    
        git add "* .txt" 
    

you are actually passing the "* .txt" to git.

In most reasonable, sensible programs, the program will look for a file named
"asterisk dot t x t" in this case.

But alas, our friends at git have decided to be tricky. The ' * ' syntax for
git is similar to gitignore-like syntax
([http://www.kernel.org/pub/software/scm/git/docs/v1.7.10/giti...](http://www.kernel.org/pub/software/scm/git/docs/v1.7.10/gitignore.html))

"Awesome", you exclaim! Not so fast. It's not the same.

So git add '!1' doesn't work. git add 'one/ * * ' doesn't work, only git add '
* ' seems to work.

Why is it so hard? Good question! I haven't any idea. But we can commiserate
together ... you know, over twitter.

Have a good one!

------
juriga
This tutorial is very pretty and does a great job of emulating the local Git
experience using just a single interactive webpage. However, Github seems to
be trying to introduce Git to a wider audience - namely non-developers.

From the blog post[1]:

"If you know of a developer, designer, or other knowledge worker that would
benefit from using Git but that hasn't made the leap just yet, send them over
to try.github.com when they have a spare 15 minutes."

As a developer, it would be nice to know how well this tutorial really works
for non-developers. To me, it seems that the tutorial introduces way too many
concepts and details in a very short time for a non-developer to understand.

For example, there are a lot of people that work daily with a computer but
freeze completely when faced with the task of using a command-line interface.
Yes, clicking on the command does write it in the console but you still have
to know to press the return key to actually execute the command.

I'm not saying people shouldn't learn Git, I'm just wondering what the target
audience and purpose of this tutorial is.

[1] <https://github.com/blog/1183-try-git-in-your-browser>

~~~
Stratego
It's hard to know how well it works for non-developers until we've had
hundreds of non-developers going through the course. Which should hopefully be
happening now.

I can't speak for GitHub (I'm from the Code School team that built this), but
we were very cautious not to introduce too many concepts in that course (you
can see below someone saying it's too basic, yes, that's the point), simply
the absolute basics we thought people would need to know to understand Git. We
also did our best to not introduce Unix concepts, which open another can of
worms.

The point is that a very large amount of people working on and around the web
today are terrified of the command line. There are plenty of tools that
attempt to abstract away the Git command line interface, and our goal with Try
Git was not to do that. To give people the real Git experience and try to ease
them into it.

I'm sure we can improve it over time to ensure that fewer people "freeze" in
front of a command line. You're right that we may need to be more explicit as
to what people should do after entering a command, but we need to stay as
consistent as possible with the actual command line.

Please feel free to give more feedback, I'll be going through everything
that's posted here.

— Olivier Lacan

~~~
juriga
Hi Olivier, great to know you're actively improving the tutorial!

Now that I checked the tutorial again, there seems to be a "Press enter to
submit commands" help text before the command prompt. If you just added that,
great, since that would have been my first suggestion anyway :)

As a developer using Git daily I can only guess what the most problematic
parts of this tutorial are for beginners. I hope you get a lot of good
feedback and data from all the people visiting the site!

------
duopixel
I really appreciate the new learning tools to become more adept at programming
and the command line. However, I often find myself mindlessly re-typing the
commands being thrown at me without really understanding what's going on, or
why I'm being asked to do it.

I liked the approach of Ruby Monks where they give you a task and let you
guess the syntax. If you got stuck you _then_ look at the solution.

I don't mean to make less of try git, or any other interactive tutorial. We
live in a wonderful time where we are able to learn powerful tools without
even installing them, so I almost feel bad about making this criticism. But I
think current tools could be improved by removing some of the _wizardy_
feeling and allowing users to play around and trying to figure out stuff on
their own.

~~~
Stratego
This is a great point. But before you can make people work at understanding
something, you have to make them realize that they have a stake in trying to
learn.

I don't think everyone (and certainly not myself) was able to understand the
value of Git at first glance and decide to invest time and effort into
learning about its inner workings.

Normal Code School courses and Ruby Monk challenges are made for people who
already have somewhat of a vested interested in learning. Something that
pushes them to challenge themselves beyond a simple demo/interactive tutorial.
People like that are (sadly) a limited subset, we're trying to broaden that.

------
robbiemitchell
Something that often gets glossed over in explaining version control to a non-
developer is, "WTF is happening with my files?"

The concept of a single folder containing multiple versions of your stuff is a
big deal; the fact that you can't simply navigate to a branch as if it's a
different folder--that you can't "see" all your files at once--is a non-
trivial thing to punch through.

------
UnoriginalGuy
This doesn't help you learn Git. It helps you learn the commands for Git if
you're already familiar with version control.

I can kind of sort of use Git already but frankly I don't understand what half
of the commands do nor do I understand the point of them.

Technically the only commands I would assume you need are:

\- Get repository \- Merge repository (with comment) \- Get history/comments

But Git has dozens of different things it can do that expand on the above and
learning it all is time consuming and there is no one single place to do so
(and no the documentation isn't a good place because it isn't a intuitive way
to learn).

The biggest hurdle of using Git is that Git has its own vocabulary for things;
and there is nothing "common sense" about that vocabulary. Even people who
attempt to explain it assume you know another version control so use
vocabulary from that.

------
tsurantino
Does this straight up just not work for anyone? I am typing in commands and am
getting no feedback. Just getting a new $ line.

~~~
tdonaghe
I'm having the same problem. Other people are complaining about this in their
support forums.

Doesn't speak too highly of Code School in general.

~~~
fiveseven
@tdonaghe - we have fixed all the lag issues (in less than 15m no less). So
not sure 20 minutes of sub-optimal experience justifies your comment. Hope you
stick around to learn more! :)

~~~
tdonaghe
I take back my complaint. :)

I just finished the course.

Great job guys!

------
arms
Runs a bit slow, but impressive nonetheless. I appreciate the simple but
effective interface.

I love when sites do something like this in order to give potential users a
quick taste of a language or technology. I already learned Git using the Pro
Git book, but this would have come in handy as an introductory lesson.

This also reminds me the of the awesome tryruby.org

------
EricDeb
As someone who has never used git I found this tutorial relatively acceptable.
I was disappointed there was not a level 2!

------
lambtron
As someone without a trained programming background and never once used any
version control (last time I programmed was for the ti-83 in middle school),
Git at first was tough to pick up.

It wasn't until I went through Michael Hartl's Rails tutorial that I actually
learned Github, master/branches, etc., and understood what are commits and
pushes.

------
grannyg00se
A lot of these Git tutorials seem to walk you through a series of commands as
if knowing the commands is knowing Git.

I think they should focus on scenarios instead. Short stories like: "Bob's
code is working well but he wants to try something that might be completely
misguided. He knows better than to mess with his working code....." Then at
the end of the story a command is introduced. Also, some kind of indication of
what Git is actually doing when you issue that command. When you tell Git to
branch, what actually happens to the file system? When you say git status,
what is it actually looking at?

And please, don't start a tutorial on Git without introducing the three area
paradigm (working, staging/index, commit)

Here's a talk by Scott Chacon of GitHub.
<http://www.youtube.com/watch?v=ZDR433b0HJY>

It's over an hour long and very detailed.

------
basicallydan
Git _isn't_ easy to learn. Not at all. You can't spend 15 minutes looking at a
Git tutorial or playing a game which teaches you Git, close the page and
exclaim "Excellent! I know Git now!" - you can however put it on your CV, and
blag it in that new job you're applying for where you need to understand git.

Like most things in software development, learning by doing is the best option
because most people don't have photographic memories, and having a reference
is usually essential.

Luckily, we all have one huge reference available to us, for free (more or
less), with a thriving community who are more than happy to help: The
Internet.

This tool is, nonetheless, a good starting point.

------
taylorfausak
Very slick, but also very slow. Occasionally I have to run a command twice for
it to register. Also, it's strange that git's output isn't colorized,
considering the "Success!" messages are.

~~~
obtu
All the commands are implemented on the remote end (hence the latency), and
some of them look like they are a limited node.js reimplementation (git is
mostly the real deal, though the command list is whitelisted). I would be
interested in a version that runs locally in JS/Linux.

------
conradfr
My use of Git is basically to have a dev branch where I commit randomly, like
some sort of ftp/backup, and a master branch that I merge from dev if I have a
release ready.

The other day I tried to merge only some files from a new "experimental"
branch and failed hard. I then realized I had it all wrong about how to
successfully commit and manage branches.

And felt so lame :) The sad part is that I am the only one trying to use a CVS
at work.

TL;DR : I still need to learn Git, so thank you everyone trying to "teach" it.

------
gburt
This is basically a glorified animation. On the commit stages, try adding a
different message than theirs. When you get to the log stage, it shows their
messages. :-(

------
Beltiras
Nice idea but far too basic. I need a Masterclass Git page.

~~~
RutZap
I guess it was intended to be basic. The idea behind it is that you take 15
minutes and do some basic things and if you like it then you can then learn
more about it... I think it's a great starting point. It gives noobs like me a
good interactive, hands-on start.

~~~
lucasgameiro
I think this kind of stuff always has focus on basic usage. Git has inumerous
features and inumerous ways to do some of then. It's so much to put in this
format. If you like it and need some more go and read <http://git-
scm.com/book> ... I've learned a lot in this online book.

------
tissarah
I really love the idea of sponsored courses/tutorials. This type of thing
makes me more likely to use Git and GitHub more, and evangelize more.

I have a tough time wanting to pay for a course at a place like code school
when I know if I go through the docs/tutorials I'll get it. It's not that I
don't think the experience is better, or even (for a certain definition) worth
the money. I feel like it is an unnecessary indulgence.

~~~
Stratego
This is beginner-level content, which makes a lot of sense as a free resource.
We're working on a Code School "Git Real" course for the end of July that will
go much further than this and be at an intermediate level, just like most of
the courses we offer through a subscription or individual purchase.

I suggest you check out the first level of that course when it comes out. I
doubt you'll think it's an unnecessary indulgence. In the meantime our Node
course is good example: <http://node.codeschool.com>

------
florestan
I seem to have great problems with this tutorial. And not that it actually
does not help me with why and how I should use it in different scenarios (wich
it doesn't), but my entire computer crashed for the first time. Got a major
error, lots of blinking on the screen and the had to reboot several times.
When I tried open it again, chrome crashed every single time. Not impressed.

------
krollew
Nice, but I think it's far too few. Stuff that this tutorial could be handled
with tar as well. I'm not sure if it would encourage to use git somebody who
doesn't know much about version control. Somebody who know, probably don't
need it because commands like "git log", "git add" and "git commit" are quite
obvious for someone who used SVN or other version control system.

------
skrebbel
I get an entirely blank page. JavaScript errors.

Win 7, Opera 12.

~~~
Toshio
Pssst, Linux+Chromium.

~~~
taylorfausak
Right, because a good way to fix errors on a web page is to change your
operating system and browser.

I am curious which JavaScript errors you're seeing, though, skrebbel. I don't
see anything amiss in the developer console on Safari 5.1.7.

~~~
usea
As another Opera 12 + Win7 user, there are 2 errors. A ReferenceError
(undefined variable pluginlist when trying to add "Java") and a TypeError
(CourseApp.Views.ChallengeMenu is not a constructor).

------
usea
The tutorial guides you through using some git commands, but it doesn't let
you deviate. It encouraged me to make up commit messages, but when I look at
the log it apparently ignored my messages and used some other ones. If it's
not going to represent the actual experience using git, why bother? It serves
only to confuse.

~~~
p2e
I agree. I kept trying to "ls" and observe what was going on between each
command or examine the directory structure of /.git and so on. Only later did
I realize that there was a filesystem explorer-like window below.

Also, having them automatically adding files to the directory was kind of
confusing. Sometimes I would type a command and something new would appear in
the file system as a result of that command. Other times, I would type a
command and something new would appear in the filesystem that I suppose was
expected to be used for a subsequent step. It would have been nice if these
things would have happened in isolation from each other. That way I could run
the command, see what happened, and then perhaps click "next" to move onto a
different scenario with a new set of files I could add to the repository.

------
gaoshan
Basic Git is easy. This intro is basic. Just be aware that it can get much
more complicated and the answers to how to do it may or may not be readily
available via Google.

This guide is like starting the "Couch to 5K" fitness program but knowing
that, if you stick with it, eventually you will have to compete in a marathon.

------
dbalatero
One bit of feedback: it's hard to notice that the Advice box has changed every
time you advance a level. Can that be made more obvious? (here's what I'm
talking about: <http://cl.ly/251P3i2t1k1p3C3U0D0u>)

------
Inetgate
That page is broken. The try.github.com will redirect to
<http://try.github.com/levels/1/challenges/1> but I got "We're sorry, but
something went wrong. (500 Internal Server Error)"

------
kentbrew
This was working nicely until about step 20, where everything sort of hung.
I've deleted cookies, removed the repository, and tried to restart but I am
now hung on step 1. (By "hung," I mean: I've issued the command but nothing
ever comes back.)

------
tdonaghe
The tutorial seems broken for me.

I'm at the point where you do a git checkout clean_up and then nothing at all
happens. You just get the prompt back. If I try git status same thing.

I've reloaded the page multiple times, but same problem.

Maybe Code School needs to work out a few more bugs?

------
pardner
Nice tutorial.

However, it requires giving an app 'try-git' access to your private and public
repositories... so afterwards, probably a good idea to edit your profile,
click Applications, then remove the try_git app.

~~~
chmike
I stoped when it asked to create a repo on github. This is not required to
lean git. Well tried ;)

------
azarias
Pff...this command line doesn't even know 'ls' :)

------
jbarham
Git: the cargo cult SCM. Too much unnecessary voodoo. Given the choice I'd
take Mercurial any day.

------
mikescar
git: 'clone' is not a git command. See 'git --help'.

What? I don't know if this is allowed later and everything is sandboxed.

------
ojjop
Does not work with Opera.

------
hhimanshu
running too slow

------
yashchandra
I just did this and it was cool. But, if you are a complete beginner to
version control in general, it may not be simple to follow. It tries to
explain a few things such as creating a branch, checking out etc. but for a
complete beginner, this tutorial will be a little bit difficult. Kudos for web
based interactive learning though!!

------
shasty
no i dont have 15 minutes

