►
From YouTube: Dissecting Git's Guts, Emily Xie - Git Merge 2016
Description
In this talk, Emily will explore and use Git’s plumbing commands to dissect what is going on behind the scenes at a low level when we use Git. Along the way, we’ll solidify our conceptual understanding of Git, exploring questions such as: How does Git store our information? What is at the heart of a branch? What is actually happening when you do a Git checkout? Or a reset?
Emily Xie is a software engineer on the Devtools team at Wayfair. Outside of work, she teaches women how to code and helps organize the Boston branch of Girl Develop It. Emily currently lives in Cambridge, MA, and enjoys photography, cooking, yoga, and razing villages in Age of Empires II.
About Git Merge:
Git Merge is the pre-eminent Git-focused conference: a full-day offering technical content, user case studies and training workshops for Git users of all levels.
Visit: http://git-merge.com/
A
Great,
so
how
is
everyone
today
awesome,
so
my
name
is
Emily
and
for
this
talk,
dissecting
gets
guts,
I'll
be
doing
a
deep
dive
into
how
git
works
under
the
hood,
but
before
I
begin
I
wanted
to
get
a
show
of
hands.
How
many
of
you
here
use
git
on
a
daily
basis
right
most,
if
not
all
of
you
so
I,
really
like
teaching
this
topic,
because
programmers
use
this
tool
all
the
time,
but
most
have
a
rather
superficial
understanding
of
how
it
actually
works.
A
So
I
think
you've
seen
this
comic
once
before
tonight,
but
xkcd
makes
a
pretty
funny
joke
of
this.
Of
how,
for
most
people
get
is
complete
sorcery
and
because
of
that
they
are
kind
of
left
in
the
dark
once
they
screw
something
up
right,
so
how
many
of
you
have
had
something
go
terribly
wrong
and
get
yeah
I
believe
there's
a
term
for
that
git
happens.
A
Fortunately,
knowing
what
goes
on
under
the
surface
empowers
you
as
it
leads
to
a
better
intuition
and
thus
a
better
ability
to
navigate
the
system
once
something
goes
horribly
awry
or
just
even
in
everyday
usage
of
the
program.
So
that's
what
I
hope
you
walk
away
with
from
this
talk
tonight:
more
comfort
in
using
git
and
a
better
conceptual
understanding
of
the
system.
For
example,
what
is
at
the
heart
of
a
branch
or
what
is
happening
when
you
are
doing
a
git
checkout
or
what
is
a
detached
head
state
and
the
way
I'll
approach?
A
This
talk
is
with
the
assumption
that
you
are
familiar
with
git
porcelain
commands.
This
is
the
term
for
all
of
the
high-level
commands
that
you
as
an
end
user
interface
with
on
a
daily
basis,
so
push
get,
pull,
get
log,
get
merge
and
so
on
and
so
forth.
And
while
we're
on
the
topic
of
terminology
on
the
flip
side,
you
have
something
called
get
plumbing
and
we're
not
talking
about
toilets
here.
A
Plumbing
is
the
term
for
all
of
the
low
level
commands
that
allow
you
to
manipulate,
inspect
and
compare
the
basic
structures
of
get
and
we'll
use
these
plumbing
commands
as
a
tool
to
sort
of
poke
around
in
dissect.
How
git
is
fundamentally
structured,
and
this
is
how
we're
gonna
do
it?
First,
we'll
talk
through
the
concept
of
the
dot
git
folder,
which
is
where
the
get
magic
happens.
A
And
I'm
gonna
go
create
a
folder
and
I'm
gonna
go
into
it
and
I
want
to
run
a
number
of
git
commands
on
it
like
git
log,
but
even
though
I
have
git
installed
on
my
machine,
I
can't
do
it
yet
and
if
I
try
I
get
a
fatal
error,
that's
because
before
you
can
perform
project
specific
operations
on
a
folder,
you
actually
have
to
initialize
git
and
the
way
you
do
that
is
through
a
porcelain
command.
Does
anybody
know
what
that
command
is
get
in
it?
A
Yes,
so
this
puts
into
place
the
scaffolding
that
get
needs
to
operate
on
that
project
great.
So
now
it
tells
me
there's
a
git
folder
that's
been
created,
but
if
you
run
an
LS
on
it
you
don't
really
see
it,
but
actually,
let's
do
an
LS
la
which
shows
the
hidden,
folders
and
files
in
a
directory
standing
for
list
format
to
make
it
look
pretty
and
a
to
show
all
of
the
files.
A
And
there
you
go
now,
you
can
see
it
the
very
bottom
one
there
it
is
so
the
dot
git
folder
is
what
makes
a
directory
a
git
repository.
It's
where
everything
that
gets
stores
where
project
lives
and
because
of
this,
if
you
ever
wanted
to
backup
or
duplicate
a
git
project,
you
can
simply
just
copy
over
this
hidden.
Folder
and
you'd
have
all
of
the
history
intact.
A
A
Cool
so
the
parts
were
concerned
about
for
this
talk
are
the
objects
folder
Refs
folder,
the
head
file,
as
well
as
an
index
file
that
has
yet
to
materialize.
So
these
four
things
constitute
the
heart
of
gets
structure.
The
rest
of
it
is
either
just
personalized
configurations
or
user-defined
scripts
that
are
beyond
the
scope
of
this
talk,
who
has
gone
into
the
dot
git
folder
by
the
way
awesome
a
roomful
of
intrepid
explorers.
Well
then,
let's
go
spelunking
and
let's
examine
this
folder
to
see
what
it's
all
about,
we'll
start
diving
into
the
objects
directory.
A
You
might
wonder
where
does
get
keep
all
of
the
different
versions
of
my
files,
all
the
content-
and
the
answer
is
right
here
in
this
objects
folder.
This
is
just
a
folder
which
functions
as
gets
database
and
the
term
that
you
can
use
to
describe
how
this
database
works
is
content-addressable
file
system,
which
is
essentially
just
a
method
of
storing
information,
so
that
it
may
be
retrieved
based
on
content.
A
So
let's
do
this:
let's
put
an
object
in
the
get
database.
I'm
gonna
go
ahead
and
write
a
file
hello
world,
because
why
not
fill
this
up
with
hello,
world
I'm
gonna
save
this
and
now
we're
gonna
use
a
plumbing
command
called
get
hash
object
that
allows
us
to
copy
over
this
file
into
our
objects
database.
The
W
here
indicates
to
get
that
you
want
to
write
it
and
we
pass
in
the
name
of
the
file
that
we
want
to
store.
A
And
great,
so
now
we
get
back
this
hash.
This
weird-looking
string
of
gibberish
comprised
of
40
hex
characters
and,
in
your
time,
using
git
I'm
sure
you've
run
into
these
who's.
Seen
these
yeah
we've
all
seen
them
get.
Log
is
probably
the
example
that
you're
thinking
of
so
this
hash
is
generated
by
the
sha-1
algorithm,
which
is
built
into
that
hash
object.
Plumbing
command
we
just
used
and
the
hash
it
produces,
is
for
the
most
part,
uniquely
generated
based
on
the
contents
of
a
file
to
drive
home.
A
My
point:
I'm
gonna
run
the
raw
sha-1
function
on
this
content
on
my
command
line,
to
see
for
ourselves
and
repeat
pens
and
metadata
file
type
in
size
to
match
the
fact
that
get
hash
object
automatically.
Does
this
for
you
right
before
running
sha-1
and
that's
just
to
escape
the
bang
character
and
here's
your
command
and
voila
for
any
given
set
of
content.
You
will
always
rely.
Ibly
generate
the
same
hash
key,
and
you
can
do
this
really
any
number
of
times
and
you're
always
going
to
get
the
same
hash
back
for
this
content.
A
However,
if
you
alter
the
content
in
any
form,
I'm
gonna
go
in
and
I'm
gonna
change.
This
I'm
gonna
add
like
an
s2
hello,
world,
you'll
notice
that
you'll
get
something
drastically
different
back,
so
getting
a
hash
that
uniquely
matches
with
a
set
of
content
kind
of
in
the
way
that
a
fingerprint
is
a
unique
identifier
for
a
person.
This
contact
is.
This
concept
is
super
important
as
it's
at
the
heart
of
what
makes
it
a
content
addressable
filesystem
anyway.
A
This
hash
can
now
be
used
to
retrieve
the
content
that
we
have
saved
in
the
objects
folder
and
by
the
way.
This
is
where
we
have
saved
it.
I'm
just
gonna
show
you
and
it's
organized
such
that
the
first
two
hash
characters
creates
a
subdirectory
under
the
objects
folder
and
the
remaining
38
functions
as
the
file
name,
and
we
can
retrieve
the
contents
by
using
the
plumbing
command,
get
cat
file
which
allows
you
to
inspect
any
get
object.
A
A
You'll
see
that
what
you
get
back
is
entirely
gibberish,
so
the
files
that
get
saved
into
its
database
aren't
just
stored
as
raw
copies
of
what
you
have.
That
makes
no
sense
if
you
think
about
the
fact
that
git
has
to
operate
on
potentially
massive
code
bases,
I.
Think,
for
example,
of
my
previous
company,
which
had
repos
with
hundreds
of
thousands
of
lines
of
code
and
just
thousands
of
files.
It
would
not
be
scalable
rather,
the
contents
are
compressed
into
these
smaller
objects
and
Z.
A
I'm
just
gonna
add
another
line
and
add
the
world
is
beautiful,
because
it
certainly
is
I'm
gonna
save
that,
and
now,
if
I
run
the
hash
object
command
on
it.
Passing
the
W
flag
once
again
to
write
it
passing
the
name
of
the
file
you'll
see
that
what
we
get
back
is
a
different
hash,
as
you
can
expect.
A
So
it's
the
newest
version
of
our
file
in
its
entirety.
I
taught
a
workshop
version
of
this
talk
at
my
previous
company
and
in
that
time,
I
found
that
consistently
developers
tended
to
think
that
version.
2
of
a
file
in
the
objects
database
would
be
a
DIF
off
of
version.
1
I
think
some
other
version.
Control
systems
like
subversion,
stores,
diffs
but
git,
is
a
different
animal
for
each
version.
It
stores
an
entirely
different
copy
of
your
file.
A
A
So
if
you
try
to
store
a
file,
that
is
exactly
the
same
line
for
line
character
for
character
in
to
your
objects
directory,
it
will
detect
that
it
already
exists
and
it
won't
duplicate
it,
but
will
spit
back
at
you
the
same
hash
as
you
see
here-
and
this
is
true
if
you
saved
a
dozen
files
with
a
different
name
into
your
database,
and
that
is
part
of
its
beauty.
It's
pretty
space
efficient
in
the
way
that
it's
designed
so
anyway.
This
type
of
object
that
we've
been
talking
about
has
a
very
specific
name.
A
A
So
that's
the
name
of
this
object
that
we've
been
creating
and
looking
at
it
inspecting
and
blobs
are
important
because
they
are
the
primary
object
store
containing
all
of
your
file
content.
But
you
might
have
noticed
that
when
we
looked
at
these
blobs
they
are
literally
only
your
file
content.
So
how
do
we
know
what
file
name
this
blob
goes
with
or
how
does
get
represent
saving
multiple
copies
of
a
file
under
this
under
different
names?
A
And,
more
importantly,
if
what
if
we
want
to
group
a
bunch
of
files
together
to
create
a
snapshot,
because
that's
what
git
is
right,
it's
not
just
a
snapshot
of
one
file,
but
your
entire
folder
at
any
given
point.
So
there's
another
type
of
object
for
this.
That
gives
us
this
layer
of
information
that
we're
looking
for
and
it's
called
free
objects.
So,
whereas
blobs
correspond
to
your
file
contents,
well,
you
can
think
of
tree
objects
as
a
complete
snapshot
of
your
project
directory.
A
So
we're
gonna
make
a
tree
to
demonstrate,
but
first
we
need
an
index
file
because
that's
what
get
make
Treece
from
so
you
might
ask
what
is
an
index
file?
Well,
actually,
you
know
what
it
is,
because
there's
a
user-friendly
metaphorical
term
for
it
that
you
see
all
the
time
and
it's
called
staging
area
so
to
move
forth.
Let's
first
stage
some
files
AKA
putting
stuff
into
our
index
by
using
the
plumbing
command
update
index.
A
So
the
add
flag
specifies
that
we're
adding
to
the
index
and
we
pass
in
the
name
of
the
file
that
we
want
to
stage
and
actually
I'm
gonna
go
ahead
and
add
yet
another
file
into
our
index.
I'm
gonna
create
one
fubar,
I'm
gonna,
open
it
up.
I'm
gonna
write
some
gibberish
very
meaningful
and
I'm
going
to
save
it
and
this
time
I
don't
actually
have
to
manually
call
hash
object
beforehand,
because
update
index
has
that
functionality
built
into
it.
A
A
A
There
you
go
you'll
see
that
we
have
indeed
added
stuff
into
our
staging.
So
by
now
we've
saved
files
into
the
gets
get
database
and
we've
updated
our
staging
and
you've
probably
already
guessed
which
porcelain
command
we've
effectively
mimicked
by
using
low-level
plumbing.
What
is
it
get
add?
That's
right
so
now
that
we
have
an
index
for
the
tree
object
to
base
itself
off
of
let's
go
ahead
and
finally
write
that
tree.
A
A
So
now
it's
official
we
now
have
a
snapshot
of
our
current
working
directory
stored
in
our
gate,
objects
folder.
But
it
seems
like
we're
still
missing
a
little
bit
of
metadata
here.
You
don't
have
any
information
about
who
saved
these
snapshots,
what
time
they
were
saved
or
why
they
were
saved
so
enter
the
concept
of
the
commit
object
which
takes
care
of
all
that
so
anyway,
let's
go
and
create
a
commit
object
will
use
the
plumbing
command,
commit
treat
for
this
well
pass
in
the
sha
hash
of
the
tree.
Object.
A
A
We'll
see
that
what
you
get
back
looks
like
our
typical
commit.
This
is
pretty
familiar
right.
So,
very
importantly,
at
the
very
top
we
have
the
hash
of
the
tree
that
this
object
points
to.
We
have
the
author.
That's
me,
we
have
the
committer,
that's
also
me,
and
then
we
have
the
timestamps
and
then
the
all-important
commit
message
by
the
way.
That
is
a
terrible,
commit
message.
I
hope,
your
commit
messages
are
a
lot
more
descriptive
than
this.
A
So
as
of
now
by
writing
a
tree
and
creating
a
commit
object,
we've
effectively
mimicked
a
porcelain,
'get
commit
so
let's
put
another
commit
on
top
of
this
one,
because
I
want
to
demonstrate
how
git
relates
commits
to
one
another.
So
let's
say
that
I've
Korea
I'm
editing
this
foo
bar
file
for
this
commit
I'm
gonna,
go
ahead
and
add
some
more
lines
of
gibberish
here.
A
So
here
I'm
gonna,
so
here's
the
hash
of
the
commit
of
sort
of
the
tree
that
I
want
to
make
a
commit
out
of,
and
here
I'm
going
to
chain
the
commits
with
this
PFLAG
piece
standing
for
parent
telling
it
to
link
this
commit
to
a
parent
commit
the
one
that
came
before
it
so
as
to
indicate
this
sense
of
hierarchy
and
we
get
back
a
hash
as
we
expect.
So,
let's
take
a
look
at
this.
Commit
object--.
A
A
There
you
go
then
you'll
see
house
by
simply
chaining.
These
commits
we're
starting
to
build
up
a
history,
so
there
you
have
it.
You've
performed
a
low
level,
get
ad
and
get
commit,
and
if
you
are
following
along,
you
probably
noticed
the
tree
like
way
that
get
is
structured
at
the
very
lowest
level.
A
Thus,
it
is
a
dag
which
is
a
directed
graph
that
contains
no
cycles
directed
acyclic
graph,
and
these
hashes
are
generated
based
on
the
Kanta
files
contents,
which
in
turn,
as
you
saw,
contains
the
hash
of
any
preceding
nodes.
This
creates
a
chain
of
dependencies
in
which
the
hash
of
each
subsequent
object
depends
on
the
one
before
it.
In
this
way,
it
is
also
structured
as
a
Merkel
tree
and
as
it's
both
a
dag
and
a
Merkel
tree,
some
like
to
call
it
by
the
hybrid
name
of
Merkel
dag.
A
Regardless
of
what
you
call
it,
you
can
start
to
see
what
sort
of
advantages
this
structure
might
hold
for
one
because
of
the
hashing,
in
that
the
key
is
uniquely
generated
based
on
the
contents.
You
can
verify
that
the
data
you
put
in
will
always
be
the
data
that
you
get
back
out.
It's
a
way
to
maintain
data
integrity.
If
there's
any
corruption,
it
will
absolutely
notice
it.
A
At
the
same
time,
it
allows
for
any
sort
of
deduplication
of
any
common
children
which
I
demonstrated
at
the
blob
level
and
for
another
it
makes
for
a
highly
flexible,
lightning-fast
piece
of
software.
Given
that
we
can
content
address
any
of
the
nodes
in
the
data
structure,
you
have
all
the
content
and
it's
just
a
matter
of
pointing
to
it
via
the
hashes,
which
brings
us
to
our
next
point,
which
is
references
so
now.
A
We
know
how
git
stores
our
information
in
three
primary
object,
types,
blobs,
trees
and
commits,
and
it's
kind
of
all,
actually
just
floating
around
in
the
objects
directory
they're
not
organized
by
like
whether
it's
a
blob
or
a
you
know
tree
or
a
commit.
But
when
we
work
with
git,
how
do
we
keep
track
of
what
commits
we
work
off
of?
Well,
usually
we're
working
with
branches.
So
there's
our
answer,
but
what
exactly
is
a
branch
and
how
does
getting
know
what
objects
go
with
a
given
branch?
So
the
answer
is,
it's
pretty
simple.
A
Branches
in
git
are
merely
aliases
or
pointers
to
the
commit
objects,
and
these
pointers
reside
in
your
refs
heads,
folder,
refs,
meaning
references
and
heads,
meaning
the
top-level
commit
for
a
given
alias.
So
this
directory
should
contain
a
running
list
of
all
branches
that
are
in
this
repository.
We
listed
it
but
there's
nothing
there
so
far.
A
That's
because
we
don't
have
any
branches
yet,
but
let's
change
that
we
can
use
the
plumbing
command,
get
update
ref
to
do
so,
and
we
pass
in
the
name
of
the
branch
that
we
want
to
make
master
and
the
commit
that
we
want
to
point
it
to
which
was
the
last
commit
we
just
made.
And
now,
if
you
list
your
refs
heads,
folder
you'll
see
that
you
now
have
a
master
branch
in
there
and
if
you
open
this
guy
up.
A
A
We
just
created
a
reference
to
the
commit
and
that's
all
there
really
is
to
a
branch
really
now
oftentimes
when
you're
working
in
gets
you're
branching
off
of
master.
So
let's
try
that
let's
branch
off
of
master
and
see
what
happens,
we
made
a
feature
branch
and
now,
if
we
list
the
refs
heads
folder
again
we'll
see
that
we've
now
created
another
reference
in
the
heads
folder
and
if
you
open
up
this
new
branch
to
see
the
hash
we'll
just
cat
it,
it's
not
an
object.
A
A
So
that's
all
that
happens
when
you
freshly
branch
off
of
master,
but
let's
say
that
we've
edited
some
files
and
then
added
a
commit
on
top,
because
this
is
what
we
normally
do
when
we're
working
on
a
new
feature:
branch
right,
I'm
going
to
create
I'm
gonna
edit,
the
hello
world
file,
save
it
and
we're
gonna
use
some
porcelain
commands
to
speed
ourselves
up
here.
I'm
just
gonna,
do
a
git
add.
A
It
looks
something
like
this:
we
changed
a
file
and
we
staged
it
and
then
we
committed
it,
which
then
creates
a
commit,
object
and
links
it
to
the
prior
commit
and,
at
the
same
time,
moves
the
branch
reference
so
that
it
now
points
at
this
new
commit
object
and
if
you
wanted
to
check
out
master
and
get
your
master
revision
back.
What
would
happen
is
that
git
would
read
the
master
branch
file
which
would
contain
the
commits
hatch
and
from
their
fault.
A
How
do
we
know
what
branch
to
move
that
commit
to,
and
the
answer
is
in
the
head
file,
which
resides
on
the
top
level
of
the
dot
git
folder,
and
this
is
just
a
text
file
that
points
to
the
path
of
your
branch,
as
you
can
see
right
there,
so
git
log,
git
branch,
along
with
a
bunch
of
other
commands
that
you
run
when
you
want
info
on
your
current
branch-
reads
off
of
this
file.
So
if
you
bring
head
the
head
file
into
the
picture,
the
diagram
then
starts
to
look
like
this.
A
I
ran
out
of
space
there
and
when
you
do
a
check
out
to
another
branch
under
the
hood.
What's
happening
is
that
this
head
file
is
getting
edited
so
that
it
points
to
another
branch
and,
by
the
way,
you've
probably
also
seen
the
term
detached
head
state
floating
around.
What
a
funny
term
right.
It's
a
very
memorable
phrase
if
you're
wondering
what
that
is,
it's
when
you
do
a
git
checkout
to
a
commit
that
no
branch
points
to
so
it
just
looked
like
that.
That
is
a
detached
head.
A
So
anyway,
the
overarching
point
that
I
really
want
to
drill
in
here
is
that
branches
are
not
some
sort
of
fleshed
out
entity.
Rather
they
are
literally
just
a
text
file
with
a
pointer
to
a
commit
hash
in
it,
and
we
do
this
because
we
need
a
human,
readable
and
meaningful
way
to
reference.
The
commit
object
that
we
want
to
work
off
of,
because
those
40
character
hashes
are
seriously
hard
to
remember
right,
but
will
certainly
remember
something
like
master
or
feature
which
is,
by
the
way,
a
terrible
name
for
a
branch.
A
So
one
last
topic
get
PAC
files,
so
I
mentioned
earlier
that
git
saves
a
copy
of
each
version
of
your
file
right.
So
that
is
the
case.
Then
you
might
start
it.
They
start
thinking
to
yourself
jeez
that
would
become
pretty
clunky
pretty
fast
right.
I'm
gonna
show
you
it's
gonna
show
the
contents
of
our
objects,
folder.
A
And
there
you
have
it.
This
is
the
smallest
repo
ever,
but
it
already
has
this
many
objects.
How
does
this
scale
so?
What
I've
been
showing
you
so
far
is
called
loose
objects.
The
thing
is
that
gets
sometimes
automatically
packs
up
these
loose
objects
into
a
binary
file
called
a
pack
file
in
order
to
save
space
and
be
more
efficient,
and
it
does
this
by
using
Delta's.
A
So
we
can
manually
reenact
this
process
by
using
the
get
GC
command
and
the
GC
here
stands
for
garbage
collect
and
with
garbage
collect,
get
performs
a
rather
complicated
algorithm
to
determine
which
of
these
objects
are
similar,
and
then
it
picks
a
base
to
then
make
the
Delta,
which
is
the
differences
between
these
objects
and
stores
that
instead,
which
saves
quite
a
bit
of
room
so
before
I,
run
this
command
to
start
packing
things
up.
Let's
run
actually
a
get
count.
A
A
A
The
first
item,
Pro,
gets
by
Scott,
Chacon
and
Ben
Straub
is
an
amazing,
open
source
book
and
you've
probably
actually
seen
it
around
online.
When
you
google,
for
some
get
help.
Personally,
it
is
my
get
Bible
and
if
you've
learned
a
lot
from
this
talk,
you'll
learn
even
more
from
reading
this
source,
because
I've
structured
much
of
my
talk
and
content
around
it
and
drew
from
it's
really
brilliant
sort
of
explore
explanatory
approaches
so
I'd
like
to
give
content
to
this
so
I'd
like
to
give
credit
to
this
book
as
well.