
Two-Minute Guide to Git - garyrob
http://www.garyrobinson.net/2014/10/git-in-two-minutes-for-a-solo-developer.html
======
garyrob
My son is creating a software project for a independent study project in high
school. I've been nagging him for a while to use version control, and he
hasn't done it. I think it's a bit intimidating to be handed a 400-page book
on git when he has plenty of other work to do. And also, he doesn't really
know, from personal experience, why version control can save him a lot of
pain. So he just hasn't taken the time.

One problem is that even if he googles "git" to find a simple guide, it talks
about the server interactions which, frankly, aren't necessary for him for a
project like this, and make things a lot more complicated. He's not sharing
code with anyone. And he backs up his hard drive regularly, so he's not
worried about losing all his code due to a hardware failure.

As opposed to Subversion, git can be used usefully without a server (including
the possibility of a local server process), which actually makes git easier to
get started with than Subversion.

So I wrote him a very brief guide for that kind of very simple, one-person
use. Another benefit: when he needs to share code, and starts to feel the need
to do things like branching, he'll already know some basics of git and so it
won't be a big jump to start harnessing more of git's power.

I thought I'd post my guide it to HN in case anyone else finds it useful for
that type of situation.

~~~
SeanLuke
Your useful guide aside: why not have him use mercurial?

git has a very steep learning curve and an interface only a mother could love.
Mercurial on the other hand has a clean interface very similar to svn, and has
all the advantages of git that you list above. And can be straightforwardly
run over apache to boot. Also the command is one letter shorter than git.

~~~
garyrob
First, I know git, and not mercurial.

Second, I don't think there is a steep learning curve for the subset included
in my post.

Third, I think git has enough momentum that it makes sense for beginning
programmers to focus on it. I suspect Mercurial will get a lower and lower
percentage of the market place over time, because programmers will generally
need to learn git at some point, and once they've done so, there is less
reason for them to go against the tide on their next project by learning
Mercurial. (An "increasing returns" situation.) Maybe I'm wrong about this --
it's just the sense I have. But, see this chart, which I think tends to
validate it:
[http://www.google.com/trends/explore#q=git%2C%20svn%2C%20hg&...](http://www.google.com/trends/explore#q=git%2C%20svn%2C%20hg&cmpt=q)

~~~
chdir
Both are great, but for a beginner, I too feel that Mercurial is much easier
to get started. You don't have to spend any time 'understanding' how it works,
just 3-4 commands is all that it takes to use it.

> Mercurial will get a lower and lower percentage of the market place over
> time

Lots of big projects continue to use Hg, some even switching to it from Git
(e.g. FB)

[https://hg.python.org/](https://hg.python.org/)

[https://hg.mozilla.org/](https://hg.mozilla.org/)

[https://code.facebook.com/posts/218678814984400/scaling-
merc...](https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-
facebook/)

------
Stratoscope
This is a great little guide. Nicely done!

But my suggestion would be to use a nice Git GUI instead of the command line.
SmartGit is free for non-commercial use and is quite wonderful. It's both
easier to use than the command line (by a long shot) and it's actually more
powerful too. Many operations that take multiple command line steps are a
single command in SmartGit.

There is also SourceTree or the more limited Git GUIs for Mac and Windows from
GitHub, but SmartGit is my favorite.

Maybe I'll take your writeup and convert it to a similar guide for SmartGit!
:-)

~~~
garyrob
My philosophy is that when you use the command line, a) You learn the tool
better, and b) wherever you are where there's git, you can use it. No need to
install anything else.

I had that philosophy back when I used Subversion, and I think it served me
well. It really isn't that hard to use the command line. Especially if you use
the subset in my post. I also suspect that GUI tools will generally have the
power to deal with staging, branching, etc, and may thus be harder for a total
newbie to understand, and more intimidating, than the few commands I outlined
in the post.

That's my take on it anyway. YMMV, of course!

------
thunderbong
I find Fossil[1] to be best DVCS for individuals and small teams. It's like a
complete github on your computer. Some salient features -

a. It has a Wiki

b. It has bug tracking

c. It has it's own server

d. It's got a nice and simple web interface. Especially when it visualizes the
different branches[2]

e. It's a single file executable across all different operating systems.

f. The Autosync feature[3], which is on by default is, in my opinion, makes
version management dead simple. (no pushing and pulling!). This feature by
itself makes starting with DVCS really easy.

[1][http://fossil-scm.org/index.html/doc/tip/www/index.wiki](http://fossil-
scm.org/index.html/doc/tip/www/index.wiki)

[2][http://fossil-scm.org/index.html/timeline?y=ci](http://fossil-
scm.org/index.html/timeline?y=ci)

[3][http://fossil-
scm.org/index.html/doc/tip/www/concepts.wiki#w...](http://fossil-
scm.org/index.html/doc/tip/www/concepts.wiki#workflow)

------
delecti
I had to learn git not too long ago, and found "Git from the bottom up" [1] to
be immensely helpful. Until about halfway through reading it I was totally
lost, but then everything started to click into place. I had a lot of trouble
using git without that decent understanding of the whole system.

This seems like a great guide for people who only need a quick crash course in
the specifics of actually _using_ git, but for anyone who still feels lost
without that deeper grasp, I definitely recommend "Git from the bottom up".

[1]
[http://ftp.newartisans.com/pub/git.from.bottom.up.pdf](http://ftp.newartisans.com/pub/git.from.bottom.up.pdf)

------
rileyjshaw
I like the idea but the title's a bit misleading. For comparison, this article
is over twice as long as the Git in 5 Minutes guide that you reference. I'm
not trying to be snarky, I was just very surprised when I saw the article's
length.

People searching for Git in X minutes might prefer a shorter preamble and a
more expository form, like this: [http://rogerdudler.github.io/git-
guide/](http://rogerdudler.github.io/git-guide/)

/2¢

------
thebordella
I appreciate this guide, so thank you, Gary.

My own special snowflake story: I am an experienced solo developer interested
in getting up to speed with modern version control. I like that Git is popular
and I prefer to learn well-supported tools. But every time I approach learning
Git for my own needs, I get stymied and confused.

\- I don't work in teams with other developers. I have no need to share code
with anybody.

\- I am not concerned about data loss, per se, because the systems I build
include their own custom automated backup solutions.

\- I don't develop in a VM on my local machine; I develop on a remote dev
machine which is an exact system replica of the remote live machine (minus the
software under development).

So what do I want from Git -- or something like it?

I want a good way to manage pushing features from dev to live with granular
control. I may be working on 3 features plus a batch of bugfixes on the dev
machine. When 1 feature and some of the bugfixes are ready to go I want to be
able to push them live without pushing incomplete features live; and of
course, I want this all to be as frictionless as possible because I don't want
to waste time monkeying around with my dev tools when I should be working on
dev itself.

Gary's guide doesn't completely get me here, but it is a nice, accessible
start. So many Git resources I have read immediately launch into how Git works
under the hood. Guess what? I don't care! Would you teach someone how to drive
a car by first explaining how combustion engines work?

Maybe Git isn't the best tool for me after all, but with Gary's guide at least
I know what commands to run without filling my head with an engineer's
treatise of its internal engineering.

------
andrewstuart2
I'd add the .gitignore file to the guide, with a link to a site like
[http://gitignore.io](http://gitignore.io).

I think it's both easy and important to learn early that you don't want to
commit binaries and push them around with git.

~~~
garyrob
I agree with you -- and it's actually already mentioned, in the little section
at the end, "One more thing – optional – may add another minute"

~~~
andrewstuart2
Well shoot, I could have at least done a search of the page before commenting.
Serves me right for skipping the optional section. :-)

------
amaks
I really like the Hacker's Guide to Git:

[https://wildlyinaccurate.com/a-hackers-guide-to-
git](https://wildlyinaccurate.com/a-hackers-guide-to-git)

------
tl
Nice summary. My only observation is that, in practice gitk --all and gitk --
<filename> have completely replaced their git log equivalents for me (and are
more universally available than $RANDOM_GIT_GUI).

------
ExpiredLink
Two seconds guide from Git:
[https://subversion.apache.org/](https://subversion.apache.org/)

