
Understanding Git for real by exploring the .git directory - adamnemecek
https://medium.com/@pierreda/understanding-git-for-real-by-exploring-the-git-directory-1e079c15b807#.pxkhiceli
======
mr_luc
I worked with someone whose approach was very interesting: he committed the
.git directory of a newly initialized repo to a separate, newly initialized
repo. And then watched what changed when he added a file, changed things,
branched, etc, in the committed .git directory.

It's always seemed worthwhile to me to dig into git's model more, but if
you're already comfortable and productive with stuff like detached
head/rebasing/basic workflows, it's hard to justify when you're already trying
to find time to learn new languages, frameworks and devops tools ...

~~~
n0us
for about six months my git workflow was this:

git add -A

git commit -am "fixed some stuff"

but I've finally found some time to start digging into how to really use it.

The issue I have with it is that if you step outside the basics it's so easy
to get yourself into a thorn bush and the way that git is explained most
places is really not intuitive at all.

~~~
icelancer
Ah yes, the "subversion" method of using git.

...

I also do this. :|

~~~
vlunkr
Also the method that gets logging, debuggers and temp files committed by
accident.

~~~
ajross
Or authentication tokens. How many ssh keys or database passwords have been
lost like this?

------
jrbancel
The most enlightening introduction to git internal model (graph of commits)
and how the main commands alter it I have read so far:
[https://jwiegley.github.io/git-from-the-bottom-
up/](https://jwiegley.github.io/git-from-the-bottom-up/)

I think it is slightly more relevant to understand the model than the .git/
structure since the .git/ folder is just an implementation detail.

~~~
chmaynard
Could someone please post a link to a PDF version of this article?

~~~
blacksmith_tb
For offline use? But git is a dvcs... ahem, anyhow, wkhtmltopdf[1] is a
reasonable choice for converting arbitary urls to pdfs, and can be installed
via apt, homebrew cask etc.

[1] [http://wkhtmltopdf.org/](http://wkhtmltopdf.org/)

------
chx
Obligatory link to Charles Duan's most excellent git tutorial:

> you can only really use Git if you understand how Git works. Merely
> memorizing which commands you should run at what times will work in the
> short run, but it’s only a matter of time before you get stuck or, worse,
> break something.

[http://www.sbf5.com/~cduan/technical/git/](http://www.sbf5.com/~cduan/technical/git/)

Somehow I do not see this mentioned often despite it is, in my opinion, hands
down the best tutorial for git. Not too short, not too long, not too
simplifying, not too complicated. Just right.

~~~
chmaynard
Is this article available as a PDF document?

------
rolfvandekrol
The article claims to be aimed a beginners: "There are a lot of posts out
there about learning the basic commands of git, this is not one of them. What
I’m going to try here is a different approach."

The article rings a lot of bells because I actually do understand how Git
works. I'm not so sure it is understandable by someone who is new to git.

The second sentence of the actual tutorial part: "When you create a git repo,
using git init". I'm sorry, what is a repository? Some sentences later: "Here
is what’s your .git will look like before your first commit:". What is a
commit exactly?

I once read another tutorial, which I can't find now. It reads as a story of a
group of people exchanging files and in order to avoid administrative mess,
eventually end up inventing the core of git, because it solves their problems.
I think that tutorial is much better for explaining the concepts of git to
beginners.

Edit: I think this is the tutorial i mentioned: [http://tom.preston-
werner.com/2009/05/19/the-git-parable.htm...](http://tom.preston-
werner.com/2009/05/19/the-git-parable.html)

~~~
ithinkso
One can be new to git but familiar with i.e. SVN or with VCS theory in
general. Sometimes I really do hate it when I'm trying to learn how to use a
new tool and every beginner's tutorial starts with explaining how computers
work or with some story that is somewhat relevant.

------
sghodas
I saw this posted a couple years ago, but it was a great guide to starting out
with git:
[http://pcottle.github.io/learnGitBranching/](http://pcottle.github.io/learnGitBranching/)

~~~
swsieber
I just have to say, I've gone through that guide and it was great. It really
helped me understand the refs (branching) model.

It was a couple of years ago, so it may be even better now.

Thanks for posting it. I always had a really hard time trying to track down
the link.

------
octref
I feel this one is more well-written and complete:

[https://codewords.recurse.com/issues/two/git-from-the-
inside...](https://codewords.recurse.com/issues/two/git-from-the-inside-out)

~~~
asattarmd
That and The Git Parable ([http://tom.preston-werner.com/2009/05/19/the-git-
parable.htm...](http://tom.preston-werner.com/2009/05/19/the-git-
parable.html)) gave me a wonderful understanding of Git.

------
empath75
I've been using git at work for a couple of years and I haven't spent very
much time thinking about the internals at all. It just seems to work pretty
much, though sometimes I get into a weird state and just delete and
redownload.

~~~
sethrin
That's the thing, there is almost no reason to ever have to delete and
redownload. Moreover, the reason that git is dominant is (network effects,
and) because it is solving the right problem with the right internal
abstractions. It has even managed to become popular in spite of its user
interface.

~~~
recursive
There _is_ a reason to re-clone. It fixes every weird git state. And you don't
even need to learn a bunch of theory to do it.

~~~
sethrin
We are all ignorant in most respects; there is an opportunity cost in knowing
anything. If you use git daily, I submit that it does not make sense to be
ignorant of how it works. Yes, you will take no physical harm from misusing
this tool, but you're setting yourself up for failure. Reading about how git
works will prevent you from making the mistakes that lead to an unworkable
state, and allow you to resolve any unexpected situations or errant
keystrokes. To make something of an analogy, git has the most powerful and
flexible form of "undo" that has been conceived to date, and you are
discarding this because you can always re-download an old copy and redo your
work. If it is something that you use only rarely, there is nothing wrong with
choosing to study other things. If you are employed as a software developer
then I would consider you to have very little excuse for ignorance.

~~~
recursive
I have never had to resort to this technique. However, there's a lot in git I
don't understand. I've spent multiple days learning git, and at some point,
the diminishing returns of further investment don't justify themselves. If I
broke my repo in such a way that caused me to consider re-cloning to "get out
of jail", I probably would only do it if I didn't lose a significant amount of
work. (e.g. copy in-progress files to a safe location before recloning)

You say I have very little excuse for my ignorance, but I would also say that
I have very little excuse to spend any more time learning a tool with as many
dark corners as git.

------
forrestthewoods
How many "Understanding Git" posts have hit #1 on Hacker News? More than a
few. How many have hit top 10? Surely dozens.

Can we, please, take this as an indicator that Git is too fucking complicated?
After the first thousand "Git made easy" blog posts it should have been
apparent.

Le sigh.

~~~
crispyambulance
Indeed, the miracle here is how git got so popular.

It has _NOTHING_ to do with meeting needs or doing things spectacularly better
than other tools. There was version control before git and it worked just
fine. I just think some "cool kids" started using it, it developed a certain
Caché that made it desirable and that was it: here we are with the most
popular version control system in the world with an absolutely shitty,
inscrutable interface.

For the vast majority of git "users", this doesn't matter. They use git as
little more than filestorage.

~~~
Biganon
Cachet _

------
shubhamjain
The most inscrutable part of Git is rebasing and how it works. It took me
really long to form a mental model where I can visualise how it does its job.

I agree with the author that understanding how Git works is the only way to
get comfortable with it. For eg, Rebasing is hard but you will have your
"Aha!" moment when you realise that it is nothing but a combination of _hard
reset_ and _cherry-pick_

~~~
cyphar
I don't understand why most people find the concept of rebasing so alien.
Maybe it's because I've never used another VCS, but it's all just very
rudimentary graph theory.

------
sriram_iyengar
Nice article. [https://codewords.recurse.com/issues/three/unpacking-git-
pac...](https://codewords.recurse.com/issues/three/unpacking-git-packfiles) is
another article that i found very useful to understand packing and unpacking.
(I found this when I was building a standalone html viewer for .git directory)

------
mosquito242
I'm finding this comment thread to be a great example of the idea that
everyone has different and particular learning styles. 6 comments, 4 different
git tutorials (not counting the original post.)

------
Kaotique
The CLI is a complete mystery and that makes it hard to explain to people.
Most of the commands and arguments differ so much that it makes little sense.
Delete a branch, commit or tag in a similar way; the commands to do this are
totally different.

How Git works can be easily drawn out on paper to explain it to someone. The
branches, commits and merges is simple to draw.

When we lose sense of our state we always take a piece of paper and draw it
out. Most of the time you can just figure it out what's up.

~~~
matt4077
Yeah, I used to race through svn workflows without a second thought. With svn,
I still don't understand how to (just one example) throw away all the local
changes. (No, not git reset --hard. At least that didn't work when I last
tried).

It came to the point where I thought about spending a week just learning git
to defend my berd creds.

Instead, I just use a gui for anything beyond add/comit/push. I still don't
like not to understand one of my daily tools, but I have real work to do.

~~~
barrkel
I found I had to build a whole parallel patch management system to rationally
deal with svn. Applying the same patch in multiple branches was a royal PITA
in svn; in git, it's trivial.

git status will tell you how to throw away local changes, btw. Depending on
the kinds of changes (e.g. edit/delete added, staged or not) need different
commands.

------
imakesnowflakes
The best way to understand Git is to learn Mercurial. It teaches you the
things that matters with none of the useless implementation bullshit.

If you start with git, you won't have a clue where the interface ends and the
implementation details starts. Which is why, I think, people find git hard.

I still hope that the whole development world will come to their senses and
start using Mercurial more and more...

------
a2-47
[http://pcottle.github.io/learnGitBranching/](http://pcottle.github.io/learnGitBranching/)

This one really helped me in the beginning. Visualisation in general helps
when learning git (branching, rebasing etc). Ungit is my goto when I want to
just see how it (repo) looks like.

------
mchahn
I have read enough of all these tutorials that I understand how git and the
git commands work. I could pass a test. But still I have a hard time feeling
comfortable enough to spit out commands as needed. I've created a lot of
aliases to do common things but that is not the same thing.

------
NicoJuicy
My entire git workflow is based on these tutorials (don't seem to need much
else): [https://git-scm.com/book/en/v2/Git-Branching-Basic-
Branching...](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-
and-Merging) and [http://nvie.com/posts/a-successful-git-branching-
model/](http://nvie.com/posts/a-successful-git-branching-model/)

Anyone knows what would be most usefull outside the scope of the tutorials
above?

------
bhrgunatha
Everyone has their favourite explanation of how git works. Mine is:

Knowledge is Power: Getting out of trouble by understanding Git by Steve Smith
[1]

[1]
[https://www.youtube.com/watch?v=sevc6668cQ0](https://www.youtube.com/watch?v=sevc6668cQ0)

------
twampss
For anyone looking for a video/demo on this, here's a great presentation by
Tim Berglund -
[https://www.youtube.com/watch?v=MYP56QJpDr4](https://www.youtube.com/watch?v=MYP56QJpDr4)

------
alblue
I wrote a series back in 2011 that looked at a bite-sized chunk each week,
including how the git repository works, and although the series is long over
there is a summar/index page here:

[http://alblue.bandlem.com/2011/12/git-tip-of-week-
finale.htm...](http://alblue.bandlem.com/2011/12/git-tip-of-week-finale.html)

As a meta note; it can be really difficult to keep up a continual blog series.
It helped that I advertised it in advance and then wrote around two in advance
so that writers block or holidays didn't impact the schedule.

------
peterfoldi
And this is my favourite tutorial so far:
[https://www.youtube.com/watch?v=ZDR433b0HJY](https://www.youtube.com/watch?v=ZDR433b0HJY)
I think it explains everything in 80 minutes.

~~~
peterfoldi
Too late to edit. I meant this one:
[https://www.youtube.com/watch?v=xbLVvrb2-fY](https://www.youtube.com/watch?v=xbLVvrb2-fY)

------
wldlyinaccurate
If this kind of approach to learning Git interests you, I took a similar
approach with A Hacker's Guide To Git
([https://wildlyinaccurate.com/a-hackers-guide-to-
git/](https://wildlyinaccurate.com/a-hackers-guide-to-git/)). It is much
longer and goes into a bit more detail than the OP but (hopefully) is arranged
in a way that you can read it a few sections at a time.

------
animeshjain
There was a very cool resource (video, ebook) on how git works on a website
called peepcode. I just realised they're no longer operational. It was by
Scott Chacon I think. Can't find it anywhere else now. Would have made a good
addition to the resources listed here.

~~~
fao_
It seems that the old website is availible via archive.org[0], however it was
part of a payment system at the time, so archive.org does not store a copy.

However, after some digging it turns out that Pluralsight put it under a
Creative Commons license, so the git guide I think that you're talking about
seems to be availible on Github[1].

[0]:
[http://web.archive.org/web/20121015074953/https://peepcode.c...](http://web.archive.org/web/20121015074953/https://peepcode.com/products/git-
internals-pdf)

[1]: [https://github.com/pluralsight/git-internals-
pdf](https://github.com/pluralsight/git-internals-pdf)

------
Todd
A little late, but this really opened my eyes:

[https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...](https://git-
scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain)

------
dawkins

        info/exclude
        you can put the files you don’t want git to deal with in your .gitignore file. 
    

Since .gitignore is committed itself this is very useful.

------
zyxley
I look at this, and then I look at people wondering why non-coders don't use
version control, and I laugh and laugh.

~~~
detaro
I don't think this article is a very good argument why non-coders don't use
it. They don't care about the internals. Git's CLI, well, that's a good reason
why they don't. (but you can get quite a lot of the benefits with a few basic
commands via a GUI tool, and you totally can explain that to many non-coding
users)

