
Try Git - Ethan_Mick
https://try.github.io/levels/1/challenges/1
======
shurcooL
Personal story. I remember there was a time where "learning how to use git"
was something I really wanted to do for a _long_ time but never committed to
it. Running into this online tutorial, as limited as it may be, was the day I
said "that's it, I'm gonna learn how to use git." I was successful. It was
just enough of a push that I needed at the time.

~~~
olivierlacan
Thanks so much for sharing this. I wrote Try Git with a lot of help from my
co-workers at Code School and Matthew McCullough from GitHub. Knowing it
impacted just one person the way it impacted you makes me incredibly happy.

~~~
shurcooL
Happy to share. Thank you for making it!

I'm pretty sure I've mentioned this to John Britton at one of GitHub meetups.
He played some part in making that from the GitHub side, as he does education
stuff with them.

That was about 3 years ago. Since then I've got a nice software engineering
job in San Francisco, and I've been trying to make as many open source
contributions in my free time as I can:

[https://github.com/shurcooL](https://github.com/shurcooL)

1,737 total in year of contributions (not counting private) hehe.

Learning to use git was an eventual step of the journey, but your work
certainly played a part in enabling all that, so thank you. :)

------
lloydde
I tried unsuccessfully to find the repo and issue tracker for try.github.io at
[https://github.com/codeschool?query=git](https://github.com/codeschool?query=git)
and [https://github.com/github?query=git](https://github.com/github?query=git)
.

1) I don't think providing the message (-m) on the command line is a good
habit for beginners.

2)
[https://try.github.io/levels/1/challenges/7](https://try.github.io/levels/1/challenges/7)
is a wild card operation followed by a `commit -m`. Prior to the commit there
should be another `status` or interactive commit (no -m), see (1) above.

~~~
olivierlacan
The current version of Try Git isn't open-sourced. You can contact us (Code
School) directly to report any issues:
[http://www.codeschool.com/support](http://www.codeschool.com/support)

1) That's true. Although sending beginners into a less/vi commit interface
that is even more bewildering than the basic shell is not a good way to
concisely introduce people to a new tool. The hardest part of teaching is what
you chose not to teach. 2) We purposefully used the GUI file browser (My
Octocat Repository) at the bottom to avoid having to systematically do `git
status` in order to check the state of the repo.

~~~
ibrahima
Hmm, yeah, I always felt that was weird as a default since most beginners
probably don't know vi/vim. Now I have to wonder why the default doesn't just
take input on stdin for the commit message. Well, I guess you lose the ability
to edit previous lines so maybe that's it. I guess nano as a default would
probably be reasonable.

------
vog
I like it that the command line is a bit "realistic" but allowing to get the
last command via arrow-up.

Unfortunately, there is no tab autocompletion, which makes it really a hassle
to enter "git add [specific file]" and similar commands.

I also like the idea of simulating the timing, such that the commands don't
always return immediately.

However, I'm a bit surprised about the exact timing values. For example, "git
init" took quite some time while "git status" was really quick. In reality, it
is the other way around.

~~~
tsm
The truth is both are blazing fast, but at least on my machine git status is a
hair faster:

    
    
        $ mkdir baz
        $ cd baz
        $ time git init
        Initialized empty Git repository in ~/src/tmp/baz/.git/
        
        real	0m0.015s
        user	0m0.002s
        sys	0m0.008s
        $ time git status
        # On branch master
        #
        # Initial commit
        #
        nothing to commit (create/copy files and use "git add" to track)
        
        real	0m0.012s
        user	0m0.002s
        sys	0m0.003s

~~~
joelg236
Interestingly, for me git init took 0.045s, while status took 0.005s. I wonder
what factors into this.

~~~
TimWolla
For an existing repository: Size of the repository, as well as the number of
files in the folder. A single git status on a 1.7GB git repository takes about
9 seconds with a warm disk cache on my workstation.

------
zaidf
Thing about git is that it is relatively easy to get started and harder to
learn the more "advanced" stuff. This isn't always true with other
technologies because once you get started, you can figure out the advance
stuff incrementally. Not true for git in my experience because even if you
know the basics of having a branch, committing, pushing it can take a while to
really understand how merges, branches, conflicts work.

~~~
solutionyogi
It depends.

If you don't know the git data model (DAG) and learn it by using commands, you
have to explicitly learn the 'advanced' stuff.

If you learn the git data model and fully understand how everything is simply
a DAG, there is nothing advanced about it. However, grokking the git data
model may take sometime.

------
tomjakubowski
I suppose this poor fellow won't be able to use GitHub Pages.
[https://github.com/Try](https://github.com/Try)

~~~
JoshTheGeek
I've wondered for a while how they deal with situations like that. For
instance, when they implemented stars, there was likely a user named stars,
but then they reserved /stars for their new feature, presumably removing that
user. I just wonder if they emailed the user and said, Hi, we need your
username for a new feature. Thanks, GitHub.

------
daok
Interesting but quite limited. In most case you will need to get information
about conflict, complex merging scenario, squashing, rebasing, etc. This is a
nice intro, but would be more complete with more real life scenario.

For those that do not want to type, you can click the command and it will
writes it into the console for you.

~~~
weaksauce
This was built by code school and sponsored by github... if you want more
advanced git tutorials, code school offers them for some money.

------
nmc
Nice! This strongly reminds me of:
[http://pcottle.github.io/learnGitBranching](http://pcottle.github.io/learnGitBranching)

------
_kst_
Interestingly, when I did a "git commit" with a different commit message than
the one they provided, a following "git log" showed their canned message, not
the one I used. (Not surprisingly, they're not really giving you shell
access.)

------
gsands
"So now that octodog is part of the family, octocat is all depressed. Since we
love octocat more than octodog, we'll turn his frown around by removing
octodog.txt."

Interesting analogies they use in the tutorial.

~~~
olivierlacan
I confess: pro-cat propaganda was sneakily inserted in Try Git.

------
s-macke
When I see such a tutorial I am always thinking of those online Linux
emulators. You can write tutorials for such terminal programs and use those
emulators for real examples.

------
datamatt
As nice as this tutorial is, I don't think git is ever really going to have
widespread appeal outside of (semi-)professional SWEs who are forced to use it
due to community size and ubiquity. The commands are simply too badly thought
out and the staging, pushing, pulling, merging process is too complex. E.g.
want to switch branches? git checkout. Wtf why not "git switch-branch" or
something. Want to send your code to the master? Is it git push? git pull?
Well, its sort of both but hey.

~~~
minot
Please have your people try SourceTree[1]. It has a beautiful interface on the
mac (Windows version is a little behind). It is backed by Atlassian, the
makers of JIRA and Confluence so you know it won't just go away tomorrow. If
your people are scared of the terminal for some reason, SourceTree is a good
place to get them started using Git.

[1] [http://www.sourcetreeapp.com/](http://www.sourcetreeapp.com/)

------
dang
[https://news.ycombinator.com/item?id=7709173](https://news.ycombinator.com/item?id=7709173)

------
magd
The app doesn't work. I typed "git init" and it did nothing.

~~~
magd
It has problems with mac/chrome.

