
A Hacker’s Guide to Git - sidcool
http://wildlyinaccurate.com/a-hackers-guide-to-git
======
lloeki
Every tutorial I read falls in two camps:

1\. try to be helpful and simplify commands to the extreme, possibly resulting
in an subverted (in both the actual and software sense) and damaging
explanation (e.g git add)

2\. describe in succinct, painful accuracy git internals (the OCD hacker way)
when no git newcomer actually cares about tree objects first hand.

Both equally fail at making people _get_ git.

Having explained git an inordinate number of times to various people, I
started writing here all I ever needed to introduce people to git _in a few
minutes†_ , but it takes longer to write than to explain hands-on and face to
face. I'll complete this and make a gist out of it.

† For varying definitions of "few" and possibly "minutes", but honestly much
less than people make it sound about git being a horrendous, unlearnable,
complex system with a broken UI. It's simple, it's brilliant, you just have to
set the bar right in between 1. and 2. when teaching it.

~~~
Crito
Your "second camp" of tutorial works exceedingly well at getting other hackers
to understand how git works. Git "clicked" when I learned the internals,
teaching me about various porcelain commands and their flags without teaching
me what git _actually is_ did nothing for me.

The reason why so many people are keen on teaching git by teaching how it
works is because that is how _they_ learned git.

~~~
SoftwareMaven
This is true, if you actually care. Many people don't want to have to know the
inner guts of how every tool they use works and just want to get their work
done. It's unfortunate that git seems to (almost) require it (most likely
because of its inconsistent UI (which has gotten better)).

~~~
Crito
The way I see it, the CLI stuff is a distraction, when you "want to learn
git", what you _really_ want to do is understand how a DAG can be used for
version control. Git is the idea. The standard/stock CLI is just one of many
imperfect realizations of the idea that is git. Getting the handle of that
particular realization of git is an unfortunate distraction that is needlessly
weird in some cases.

Think of it like the difference between learning how an engine works, and
learning how [some particular engine, in some particular car] works. The first
is pretty simple and illuminating. The second has lots of annoying details and
imperfections. If you want to work with cars, you learn the former first.

------
EinLama
I'd recommend another guide. "Pro Git" by Scott Chacon is excellent and
welcomes patches, source for the book and its translations are on GitHub
[http://www.git-scm.com/book](http://www.git-scm.com/book)

~~~
collyw
I appreciate that git is powerful, but should we really need to read a book
just to get the best from a source control system? It seems overly complex to
me at times (any time I do anything outside of my usual workflow).

Version control only makes up a part of the whole development process, and
plenty of coders out there manage without any at all.

~~~
egil
Git was originally created to manage the Linux kernel. It is indeed complex,
but it has to be at that scale. Git might not be the best option for every
project, but I find it quite easy to use at the trivial scale as well. (How do
you beat 'git init' ? No repository setup or anything.)

~~~
ams6110
I'm not so convinced. Other OSes manage with more "primitive" tools. OpenBSD
still use CVS.

~~~
dspillett
As did Linux before Git, but Linus and the core team around him were finding
the process getting too cumbersome and bottlenecked. Linus "scratched the
itch" and produced git both specifically to fill that set of needs and with
the intention of it being generally useful for other projects they were
concerned with.

OpenBSD's kernel development is presumably run differently (IIRC there is a
much smaller number of people trying to directly feed into it for a start,
which was a key problem with Linux at least at the time Git was birthed) so
processes and tools that fit their needs will look different. Either they
haven't had enough trouble with the older tools/processes that the effort of
an infrastructure change is worth sinking time into, or they have other
concerns with the alternatives (security, as someone has mentioned above, and
code maturity concerns may be involved, though the latter much less now as it
has been pretty solid for some time), or maybe they intend to move but just
haven't decided on an alternative yet.

~~~
woadwarrior01
Linux was using BitKeeper, a commercial DVCS. The raison d'etre for git was
because the company behind BitKeeper revoked the license for the Linux guys to
use it.
[http://en.wikipedia.org/wiki/BitKeeper](http://en.wikipedia.org/wiki/BitKeeper)

~~~
dspillett
Ah, I forgot that step.

They moved to a DVCS to solve some of the workflow issues, _then_ Linus
created git in large part because of the licensing issues.

Another detail missed in my previous post: If I remember rightly there were a
couple of F/OSS DVCS's in development at the time, but he chose to write his
own as some of them were not yet near stable and the others didn't quite work
the way he wanted. I dimly recall some criticism for choosing a commercial
product prior to git, and that decision was for much the same reasons git was
created instead of using one of the other available options.

------
wmt
"Once you start talking about branching, merging, rebasing, multiple remotes,
remote-tracking branches, detached HEAD states… Git becomes less of an easily-
understood tool and more of a feared deity. Anybody who talks about no-fast-
forward merges is regarded with quiet superstition, and even veteran hackers
would rather stay away from rebasing “just to be safe”."

"That’s why trying to understand Git in this way is wrong. Git doesn’t work
like Subversion at all. Which is pretty confusing, right?"

These kind of assumptions of the reader can be quite off-putting. If you don't
relate to assertions like this in the introduction, you start to wonder if the
rest of the article is based on these assumptions.

I user SVN happily for years before moving to Git a number of years back, and
the conceptual migration felt really smooth. It was just like SVN, but with
some nice new native branching tools and features, like in SVN you were forced
to merge trunk changes to feature branches, whereas in Git you also have the
option to "move" i.e. rebase the branch onto a newer commit.

The rest of the article was very good!

~~~
aidenn0
You are the very first person I have run into in any forum to say that moving
from SVN to Git had a smooth conceptual migration (at least among people who
have ever done anything more complicated than "git commit -a" which I assume
you have if you've been using git for a number of years).

It is hard to come up with two systems that implement source control and are
more different.

------
username42
I like very much this introduction to git. Most of the other tutorials
considers git as a magic black box. Here, it explains what is performed
internally by most of the commands, without going into tiny useless details.
This is probably not a good tutorial for build management processes and not
enough to rewrite git, but it fits perfectly well my "hacker" mind. Thank you
very much.

------
jammycakes
What disappoints me most about this, as well as almost every other Git
tutorial that I've seen, is that it uses the command line almost exclusively.
Even those tutorials that I've seen that do refer to GUI options pay lip
service to them at best.

This is a shame because I personally found GUI front ends for Git and
Mercurial critical to understanding how they work in the first place, and in
fact some tasks (such as advanced branch manipulation or hunk selection as
with git add -p) are considerably harder with the command line than with GUI
tools, simply because the command line doesn't give you a full enough picture
of what you're doing.

~~~
mistermann
Sorry for a bit of a Hijack.....anyone care to comment on what is generally
considered the best git GUI tool for Windows/Visual Studio?

~~~
thomaslangston
Sourcetree has been my favorite, followed by the default GUI installed from
the git-scm.com. I've not been a fan of the VS extension because of
performance (a want NCrunch and Resharper to have all my free cycles).

------
fauria
I would add "git - the simple guide. just a simple guide for getting started
with git. no deep shit ;)": [http://rogerdudler.github.io/git-
guide/](http://rogerdudler.github.io/git-guide/)

~~~
criswell
I wish I knew about this months ago. So clear.

------
kevinpaladin
I would recommend this guide here too :
[http://www.sbf5.com/~cduan/technical/git/](http://www.sbf5.com/~cduan/technical/git/)

------
mateuszf
Introduction with very similar approach: search for "Git from bottom up".

------
stephengillie
Where I work we just moved off Git to TFS. Our coders had a lot of trouble
understanding Git, actually our whole company has had trouble with Git. We
decided to leave it when we realized any individual coder could wipe out our
local repository with a wrong command.

We moved into TFS, and while we're working to get our DLLs to not be
circularly referencing, we have an actually verifiable copy of our source
code. Maybe it's because we use MS technologies (IIS, .NET, MSSQL) but we were
on TFS in a matter of weeks while Git still confused us after a month of use.

Many of my coworkers feel it's a "piece of Git" (if you get my expletive).
Several also think it's a waste of time. I don't disagree with them. I
supported Git because I saw it on here. This solution doesn't our solve
problems in our situation.

~~~
eddiedunn
> We decided to leave it when we realized any individual coder could wipe out
> our local repository with a wrong command.

What?

1) You can configure your repo so only select users may use destructive
commands on certain branches.

2) It's a _distributed_ content versioning system. Even if someone wiped out
the main, "central", repository, all users will have a full local copy, a
backup in effect.

Git has a horrible UI in many ways, but your apparent dislike of it smells
more of incompetence and a naive buy-in of the full Microsoft ecosystem than
anything else.

BTW, I didn't know what TFS was before checking on Wikipedia, but -- somewhat
ironcially given your gripe -- TFS seems to have decent support for Git[1].

[1]:
[https://en.wikipedia.org/wiki/Team_Foundation_Server#Git](https://en.wikipedia.org/wiki/Team_Foundation_Server#Git)

[EDIT]: formatting

~~~
stephengillie
1\. Some of this does look like ignorance on the part of my coworker who set
up both. But why isn't that a default setting? Why give that permission to all
users?

2\. This is true only if other users keep local copies of the main repository,
keep it updated, and don't mix it in with their code. You're making a lot of
assumptions.

~~~
eddiedunn
1\. When I set up Git on my Linux server only the user that initiated the repo
had access to it. It was too locked down, seeing as external users didn't even
have read/cloning permission. (A minimal amount of googling solved all my
problems, though.) Your problem sounds to me as another PEBCAC on the part of
your coworker.

2\. I'm not making all the assumptions you claim. First of all, as soon as you
clone a repo you have a local copy. You need this clone in order to be able to
even work with the code, so it would be quite weird if employees deleted their
clone after editing, committing, and pushing their changes. I'm not even sure
what you mean with "mix it in with their code". It's a VCS -- if you don't
like a change reverting it is trivial.

All in all, I understand why users might have problems with Git. It has a
steep learning curve. I think it has a horrible command line UI. It might not
have worked well for your company, even if you had a competent admin set up
the repos. However, I would prefer if you could argue your point based on the
actual merits and faults of Git, rather than based on ignorance.

------
avinash240
My biggest issue with git is it's CLI design. It's absolutely inconsistent. I
don't believe the internals are an issue. If you really want to make git
better, destroy the CLI and build a new one. Instead there are a million of
these tutorials(the fact that there are a million tutorials should already
hint at something being wrong), talking about internals.

------
huhtenberg
Does anyone else find this to be quite hard to read? Just visually. Especially
length of the lines and thinness of the font.

~~~
J_Darnley
No. You mean it uses all (well nearly all) the width of the screen? I am
pleased to see that for once rather than stuffing it into some narrow column,
the width of which I would have complained about 10 years ago.

~~~
huhtenberg
How big is your screen?

~~~
dspillett
No so big that resizing a window when content is too wide for comfort stops
working...

Less facetiously: I wish more pages would give me the choice rather than
forcing the content into a fixed-width format unnecessarily, or if they don't
mind the extra coding (especially if their design is well thought out enough
to make it easy) have a fixed width setting by default with the option to turn
it off (I've seen this done by giving the user the option flipping stylesheets
via a control at the top of a page) like some support different font size and
colour/contrast options.

------
yuribit
After learning Git, it is important to follow a branching model, I really
appreciate the one proposed here [http://nvie.com/posts/a-successful-git-
branching-model](http://nvie.com/posts/a-successful-git-branching-model)

~~~
GUNHED_158
This is my favorite one too.

------
tieTYT
I've got the right level of understanding of Git to grok this article. I
really liked how you talked about cherry picking before you talked about
rebaseing. I'd like to request you include a section on why/when you need the
rebase --onto argument.

~~~
wldlyinaccurate
I think the cherry-picking example borders on being too long and complex, but
I'm hoping it still gives that "aha" moment when you realise that you've just
done a rebase the hard way.

Great suggestion about --onto, thanks! That is a tough one to explain in a
concise way, but I'll give it my best shot.

------
seren
Quick question for people using git daily : do you push the features branches
to a central repo or you simpy merge with --no-ff on a common dev branch ?

(There is no necessarily a right answer, but I'd like to know what is more
usual)

~~~
SoftwareMaven
Feature branches are pushed to remote, where code reviews can take place. Once
the code is reviewed and approved, the submitter rebases it onto master. We
run a batched continuous integration, so once it's on master, it is expected
it could be pushed into production at any time (batched because somebody has
to do the push manually, usually after merging the code).

~~~
seren
Interesting because you'll get the cleanest history possible, however have you
ever had an issue when the rebasing post code review would have had unintended
effect (and not caught by a reviewer) ?

------
lwilliamsjr
Check out General Assembly's Git instructional, its pretty good:
[http://www.youtube.com/watch?v=DVDLoe_2MBc](http://www.youtube.com/watch?v=DVDLoe_2MBc)

------
kasperset
I found this video helpful as a beginner:
[http://vimeo.com/46010208](http://vimeo.com/46010208)

------
alarra9
Really good-looking illustrations. How did you make them?

------
anton_gogolev
How many more tutorials on Git do we need? It's like article authors find it a
"rite of passage" of sorts to explain Content-Addressable Storage, references
and all kinds of whacky command-line keys.

~~~
scotch_drinker
"We" don't need any Git tutorials. We could read the documentation But perhaps
people don't write solely because of the audience's need. Writing a tutorial
is the fastest way to ensure you more fully understand the subject. It is in
fact a rite of passage in any topic when you can explain it to an audience
with less understanding. Tutorials don't just serve the audience.

------
juggty_dev
Worth for pro..

------
Dowwie
I don't know about you but when I see signs that read, "Do not Enter" I tend
to take that into consideration. With that given, a site called "Wildly
Inaccurate" may be just that.

------
NDizzle
Try not to take this as snark, but aren't hackers early adopters that do
things on their own?

What's the point of a hackers guide to a thing that has been a thing for
years?!

~~~
peterwwillis
I was writing something almost identical to this recently, for the general
public but also for my co-workers who don't seem to understand the internals
of Git at all. I'm sick of being "the Git guy" so this should help a lot.

