Comment by juriga | Hacker News Reader

Comment by juriga | Hacker News Reader

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

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

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!

Many great points Jyri. This course certainly is not meant to be a completely detailed introduction. At Code School we're in the middle of working on something that should be more of a step by step introduction.

However, I think there's something to be said for showing people how they can be immediately productive with a tool before really understanding everything that's going on underneath. With just a few commands someone can start using git successfully, and that's all we were trying to communicate with this tutorial.

Coming from someone who has very little command line experience, my experience with Git thus far has mainly been trial and error. Reading 10 Getting Started With Git blog posts is great, but there's always a part of me that knows some of the information I'm getting could be wrong or outdated. For me, this was a fast confirmation that the commands I've been using are correct and the workflow I've developed is 'valid'.

I have fairly extensive experience working with designers, and git is simply too complicated. The additional features offer them very little value, and the value they do offer is far outweighed by the complexity of the system and the propensity for difficult to resolve failure.

I rather agree. It seems difficult enough to teach people Alien Brain, SVN and Perforce, and they all have a much simpler model.

And is git much use to people who mainly work with large binary files? Well, I'm not sure (translation: "no") - but perhaps if they don't expect very much from their source control system, they won't be disappointed when git fails to deliver on its promises as well as it does for text.

Reply on news.ycombinator.com