« Ferguson and keeping high-IQ folks out of the U.S. police force | Main | LIGO's Discovery of Gravitational Waves »

October 21, 2014



Hi Gary,

I just wanted to say that I think this is possibly the clearest, most concise introduction to git that I've seen. No mucking around discussing DAGs and and branching and repos and stuff, just how to get the massive benefit of version control with a few easy commands.

Well done, and thanks!


I've never done "git commit file -m ..."

I have only ever done "git add file" (or "git add -A"), review status, then "git commit -m ..."

I think that part of your tutorial is a little unclear, since the file name is not necessary after the add is already done.


This is exactly what I needed to start with git.

Thank you!


In your writeup please include the git!s purpose and and why you'd want to use it. In addition add na continuing example in each section.

All this would make everything much more understandable.

Dr. Dan

Gary Robinson

@mitch: What I'm going for in this tutorial is to not require the developer to understand staging. I'm framing "git add" as the way to make git aware of a file. After that, he doesn't do 'git add' again for the file. He just does 'git commit -m "message" when he wants to commit that file'. Or he can do 'git commit -a -m "message"' and commit only the changed files.

I don't think there's anything wrong with staging, obviously; it's just something I think it unnecessary for getting started with git if you're trying to do so in the simplest possible manner. I do mention it in the text as something to learn about later.

Gary Robinson

@Dr. Dan: The text does say why the developer should want to use the subset of git that is presented here. It doesn't explain why he'd want to use larger subsets of git (including staging, branching, etc.) because it doesn't teach them.

Someone who is a rank beginner isn't going to have an intuitive feel for why things like branching and staging might be useful, even if I gave an introduction to them (which would have to be short enough to not violate the 2-minute goal of the tutorial). So, I'm leaving them out. In time, the developer may start working with other people, who will probably already be using git, and he can learn about them at that time. At least he'll already be comfortable with this subset of git, which will give him a leg up at that time.


think you!

The comments to this entry are closed.