Try Git | Hacker News Reader

Try Git

try.github.io

140 pointsEthan_Mick37 comments

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.

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.

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

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. :)

I tried unsuccessfully to find the repo and issue tracker for try.github.io at https://github.com/codeschool?query=git and 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 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.

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

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.

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.

> 2) We purposefully used the GUI file browser

Adding this artificial element furthers concisely introducing people to a new tool? If you are going to teach a CLI then stay in the command line.

Also, you didn't solve the problem as the GUI file browser doesn't show the status of the files either.

nano is less confusing than vim, though that is another bad habit to form. I used it for a very long time, but switching to vim has been amazing. I think that -m is probably best for teaching a beginner, though.

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

Why? I started that way and still do it today. Is it considered a bad practice?

Because it doesn't put you in the right mindset.

A commit message should be formatted like an email to your past self, or your future collaborators. It should have a very descriptive and concise title (the first line of the message) written in the present tense and after a line break you should (when necessary) write an email style explanation of the reasoning behind the commit.

If you fixed something, is there context that should be useful for someone discovering this commit in a vacuum. Are there any related commits? If you added something, why? There is so much useful information that can be encoded in a commit message and discovered when someone does a `git blame` for example.

Caleb Thompson wrote a nice concise post on this: http://robots.thoughtbot.com/5-useful-tips-for-a-better-comm...

I'll agree that being in interactive editor is a more conducive setting for this kind of message, but you can provide both a title and longer description via command line by specifying the -m option twice, e.g.

    git commit -m "fixed the widget factory" -m "It seems like we keep getting wooden shoes stuck in the machine, so I added a ShoeClearingDaemon process to check periodically and restart the machine if necessary."

3) Confused use of the term "repository"

- "1.2 The repository is a hidden directory where Git operates." OK

- "1.3 I created a file called octocat.txt in the octobox repository" WAT

- GUI labeled "My Octobox Repository" HMM

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.

I wrote something a few years ago that does a similar thing using a real command line. https://github.com/Gazler/githug

> a hassle to enter "git add [specific file]"

`git add .` worked as well and clicking the command autoenters it at the prompt.

Maybe it's just slow... `git status` should be quick in an empty repo.

It's all very slow for me right now - every command hits the server, which is disappointing.

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

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

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.

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.

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.

I suppose this poor fellow won't be able to use GitHub Pages. https://github.com/Try

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.

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.

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

Nice! This strongly reminds me of: http://pcottle.github.io/learnGitBranching

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

"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.

If anyone from Github is reading, I'd change

> Since we love octocat more than octodog, we'll turn his frown around by removing octodog.txt.

> Since we love octocat more than we love octodog, we'll turn his frown around by removing octodog.txt.

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

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.

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.

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/

https://news.ycombinator.com/item?id=7709173

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

It has problems with mac/chrome.

Reply on news.ycombinator.com