►
Description
Presented by John Austin, Founder / Technical Lead, A Stranger Gravity, Funomena
"Git is *the* source control system of the modern era. Yet, the vast majority of AAA game studios still use Perforce, SVN, and other more traditional systems. It’s not for a lack of desire, rather, game developers have a unique set of constraints and workflows that make Git unsuitable for the task.
This talk will illustrate how game workflows are unique, why Git doesn’t currently support these workflows (even with LFS), and introduce a new tool, Git Global Graph, that strives to build a path for even the largest AAA developer to use Git. We’ll explore constraints on Game Development workflows and introduce the Git Global Graph project, a tool designed to solve the above challenges without compromising on the fundamental structures and benefits of Git."
About GitMerge
Git Merge is the pre-eminent Git-focused conference: a full-day offering technical content and user case studies, plus a day of workshops for Git users of all levels. Git Merge is dedicated to amplifying new voices in the Git community and to showcasing the most thought-provoking projects from contributors, maintainers and community managers around the world. Find out more at git-merge.com
A
So
the
game
development
workflow
is
a
little
bit
different
than
a
normal
software
project
and
there's
a
couple
of
reasons
for
that.
As
a
start,
game
development
happens
almost
entirely
on
Windows.
There
are
game
developers
that
work
on
Linux
and
Mac,
but
mostly
it's
to
support
those
platforms.
The
vast
majority
happens
some
windows
and
it's
really
because
Microsoft
supports
you,
know,
DirectX
and
like
this
is
a
history
of
that
all
the
software
is
on
Windows.
You
really
can't
get
off
of
that.
A
This
used
to
be
more
of
an
issue,
but
a
lot
of
the
work
that's
been
done
forget
for
Windows
has
really
made
this
pretty
much
solved,
at
least
in
my
opinion.
It's
at
this
point.
It's
pretty
much
just
as
easy.
It's
a
little
bit
weirder,
because
on
Windows
you
don't
really
expect
people
to
jump
into
a
terminal,
that's
a
little
bit
of
a
harder
ask,
but
for
the
most
part
the
software
just
works
but
is
still
kind
of
a
different
platform.
A
The
one
of
the
big
differences
with
games
is
that
the
the
size
of
a
git
repo
or
like
a
repository
for
a
game
development
is
just
like
mind-bogglingly
huge,
so
even
for
a
small
game,
that's
maybe
like
10
to
15
developers.
It's
in
start
just
into
the
hundreds
of
gigabytes
into
the
terabytes
just
for
the
head
revision,
and
if
you
get
some
triple-a
game
development,
it's
like
tens
of
terabytes,
it's
just
it's
just
huge.
A
A
So
when
you
have
files
that
are
gigabytes
each
every
time,
you
change
it
even
the
littlest
bit,
it
just
starts
copying
it
and
filling
up
the
repository.
So
this
is
definitely
an
issue.
It's
far
more
solved
than
some
of
the
others
get
LFS
has
done
a
huge
amount
to
make
this
almost
a
non-problem.
We
still
have
some
issues,
but
you
know
offloading
this
to
a
CDN
or
something
like
that.
There's
a
great
solution
and
I
think
this
is
well
on
its
way
to
being
solved.
A
The
second
issue,
which
I
think
is
talked
a
little
bit
less,
is
about
binary
conflicts.
So
a
binary
conflict
occurs
when
you
have
two
users
who
are
editing
the
same
file
in
parallel,
that's
a
binary
file
and
then
you
go
to
merge
and
at
the
end
of
the
day
you
have
to
pick
either
the
left
file
or
the
right
file.
Git
doesn't.
If
you
can't
merge
the
file,
then
all
you
can
do
is
toss
away.
A
One
of
the
developers
work,
but
you
know
in
games
in
a
game
development
context
where
90%
of
the
files
are
binary.
You
can't
just
be
throwing
away
people's
work
left
and
right
right
if
everyone's
working
on
the
same
files,
then
you're
going
to
get
minor
conflicts
all
over
the
place.
So
I
think
this
is
actually
the
more
interesting
problem
to
talk
about,
and
even
if
we
have
the
perfect
CDN
performance,
you
know
system,
forget
we'd
still
have
lots
of
workflow
issues
here,
just
because
all
of
these
files
will
constantly
conflict
with
each
other.
A
So
we
need
something
to
manage
that
so
I
want
to
go
through
a
couple
of
the
systems.
That
kind
of
when
I
talk
about
this
people
proposed
just
to
kind
of
say
why
they
don't
necessarily
work.
The
first
off
is
kind
of
kind
of
simple:
we
could
just
communicate
better
yeah.
Maybe
we
could
create
a
spreadsheet
or
something
like
that
that
marked
down
who's
touching
what
file
and
to
make
sure
that
you
know
we're
not.
You
know
touching
one
at
the
same
time
as
someone
else,
but
the
end
of
the
day.
A
This
is
like
not
really
a
solution,
it
doesn't
scale
at
all
and
it's
really
it's
why
we
build
source
control
in
the
first
place
like
I,
don't
want
to
sit
and
make
manual
changes
to
the
spreadsheet
and
try
to
track
that
and
it's
just
a
total
mess.
So
it's
not
like
communication
is
definitely
a
big
part
of
it,
but
it
doesn't
really
solve
the
problem
right
and
in
a
convenient
way.
A
The
other
you
know
some
my
solution
is:
it
does
provide
a
lot
of
great
support
for
adding
custom,
merge
tools
and
text
representations.
So
you
know,
theoretically,
we
could
create
merge
tools
for
all
these
binary
font
formats
or
we
could
cast
them
down
into
text
and
use
our
normal
diff
merge
workflows.
But
you
know
this
doesn't
really
work
in
practice.
A
You
know
second,
two
through
four
of
that
audio
file,
usually
you're,
doing
something
like
replacing
the
voice-over
clip
that
you
just
or
tweaking
the
equalization
levels
and
generally
you're
modifying
just
the
whole
file
itself.
It's
same
with
painting.
Nobody,
nobody
gives
no
artist
goes
in
and
modifies
just
a
corner
of
a
painting,
but
just
doesn't
really
happen.
So,
even
if
you
do
have
the
perfect
merge
tool,
the
the
access
patterns
of
these
files
are
still
binary
right.
If
you,
if
every
time
you
modified
your
code,
you
are
touching
every
single
line
in
the
file.
A
You
yeah,
you
take
conflicts
everywhere.
So
this,
even
if
we
had
a
great
tool
for
this,
it
doesn't
really
solve
the
problem
and
then
sort
of
a
more
philosophical
level
like
this
is
really
not
a
concept
of
a
merge
for
a
lot
of
artistic
and
subjective
assets.
So
I
think
this
is
a
great
example.
If
you
take
that
first
image
on
the
left
as
the
base
revision
and
you
imagine,
two
people
have
modified
it.
So
the
first
one's
made
kind
of
is
more
realistic
image.
Maybe
the
second
one's
made
this
more
blocky
and
abstract
image.
A
If
you
imagine
trying
to
merge
those
changes,
it
doesn't
just
doesn't
really
make
sense
right,
like
even
if
you
had
the
best
neural
network
based,
merge
tool
that
wouldn't
be
what
the
art
director
intended
right.
So
the
art
in
the
game
is,
is
it's
very,
it's
a
very
subjective,
medium,
and
so
it's
very
important
that
you
keep
that
consistent
line
of
understanding
of
the
artists
as
they're,
making
an
asset
so
in
a
lot
of
ways,
just
merging
in
the
first
place,
doesn't
make
sense
with
with
many
of
these
assets.
A
So
if
we
can't
merge
them
just
kind
of
as
a
rule,
we're
kind
of
in
a
weird
state
because,
like
we
said
earlier,
it
kind
of
assumes
that
all
files
can
be
merged.
That's
like
kind
of
the
fundamental
point
of
get,
is
the
branching
and
merging
right
like
whatever.
What
do
we
do
if
we
can't
merge
so,
but
maybe
what
we
can
do
is
we
can
try
to
prevent
these
binary
conflicts
just
before
they
happen
in
the
first
place,
so,
rather
than
waiting
to
the
end
of
the
day,
and
so
we
get
hit
those
conflicts.
A
A
So,
if
we're
going
to
try
to
create
some
sort
of
early
warning
system,
you
know
kind
of
stop.
These
changes
use
parallel,
edits,
there's
a
bunch
of
places
we
can
kind
of
inject
ourselves.
So
you
know
a
change
happens
on
the
gate
level,
but
even
before
that
right
you
could
have
two
developers
that
open
up
Photoshop
and
modify
two
textures
in
memory
and
they've
already
created
a
binary
conflict
right
there,
like
it's
already
too
late,
and
so
there's
a
bunch
of
layers
that
we
could.
A
You
know
kind
of
try
to
catch
the
developer
before
they
create
a
conflict.
But
I
think
for
this
talk.
I
want
to
focus
on
just
the
git
part
of
the
of
the
process,
mostly
because
the
get
process
is
a
little
more.
It's
that's
where
all
the
complexity
is
happening,
and
once
we,
if
we
can
solve
that,
then
we
can
kind
of
add
layers
on
top
of
that
to
kind
of
integrate
more
into
like
the
disk
or
file
layer.
A
A
So
at
phenomena
you
know
our
games
are
fairly
small,
like
we're
an
independent
studio,
we're
not
creating
hundreds
of
terabytes
of
files
left
and
right
so
for
us
to
get
LFS
actually
would
work
pretty
well,
but
without
some
system
to
manage
these
conflicts,
we're
just
we're
stuck
on
perforce
because
perforce
has
file
locking
and
what
file
locking
does
if
you're
not
familiar,
is
it
basically
it
takes
that
spreadsheet.
We
talked
about
earlier,
where
we're
keeping
track
of
you
know
who
owns
what
file,
but
it's
automating
it.
A
You
get
back
to
the
point
where,
maybe
you
can?
Oh,
you
can't
even
branch
left
and
right
like
you
want
to,
and
so
at
that
point,
why
are
you
even
using
it
right?
If
you
can't
use
your
git
workflows,
then
there's
not
a
lot
of
use.
You
might
as
well
be
on
perforce
so
file.
Lock
is
not
a
great
solution,
even
though
that's
kind
of
the
normal,
the
normal
way,
it's
done.
So,
let's
in
the
goal
of
coming
for
the
better
solution,
we
could
start
with
a
simple
example.
A
So,
rather
than
thinking
about
lots
of
developers
and
lots
of
moving
changes,
let's
think
about
a
binary
conflict
in
a
local
repository
with
a
single
developer
in
a
single
master
branch,
so
maybe
you're
working
on
master,
and
you
want
to
kind
of
do
a
little
work
on
the
feature
branch.
So
you
make
a
branch
and
you
modify
your
binary
file,
you're
changing
an
image
or
something
like
that.
A
Well
then,
you
kind
of
in
the
middle
of
that
and
you
pop
back
on
master,
because
you
know
maybe
your
priorities
changed
or
you
need
to
fix
a
bug
and
in
the
process
you
also
modify
that
same
file.
So
now
you've
conflicted
with
yourself.
So
if
you
go
try
to
merge
this
file,
you're
gonna
hit
a
conflict
again,
and
so
this
can
happen.
Even
if
you
don't
have
multiple
developers
right,
you
can
still
hit
these
binary
conflicts.
A
A
So
in
terms
of
coming
up
with
a
system
to
kind
of
stop
this,
it's
useful
to
kind
of
think
about
how
binary
files
flow
through
your
commit
graph.
So
a
binary
file,
if
it
can't
branch
right,
because
if
you
branch,
you're,
gonna,
create
parallel
edits
and
parallel
edits
leads
to
binary
conflicts,
then
you
say
I
can't
branch
and
then
it
also
can't
merge
because,
like
we
said
it's
just
not
really
feasible
to
merge
a
lot
of
the
binary
files.
A
So
if
everything
we
do
and
get
you
know
keeps
this
property
keeps
like
the
Pettis
path
property,
then
we're
good,
because
we're
not
going
to
create
binary
conflicts
right
if
everything
is
a
path,
there's
no
conflicts
to
be
had.
So
what
we
want
to
do
is
try
to
figure
out
a
way
to
maintain
this
and
check
this
property
every
time
we
modify
the
commit
graph
so,
rather
than
trying
to
actually
scan
through
the
entire
repository
every
time
you
make
a
change.
That's
a
little
bit
unfeasible.
A
We
can
come
up
with
like
a
simple
rule,
that
sort
of
verifies
this,
so
maybe
every
time
you
make
a
commit,
we
just
say
that
every
commit
to
a
file
has
to
descend
from
all
other
commits
that
have
modified
that
file.
So
this
is
kind
of
a
simple
rule
and
it's
you
know
simple
and
for
variety
of
reasons,
but
what
it
does
do
is
it
enforces
this
path?
A
Property,
one
of
the
nice
things
about
this
rule
as
well,
is
that
it
also
supports
kind
of
a
Messier
history,
so
you
can
imagine
even
a
simpler
rule,
but
what
we
also
want
to
support
is
like
let's
say
you
do,
create
a
binary
conflict
somewhere
down
in
your
history.
We
still
want
like,
and
then
maybe
you
manually
merge
that
you
know
pick
left
or
right
or
something
like
that,
and
so
you
actually
break
your
path
constraint
down
there
right
you
kind
of
branch
and
come
back
together.
A
We
still
want
to
rule
that
supports
having
that
in
your
connect
graph,
but
we
want
a
role
that
enforces
the
path
constraint
from
there.
So
this
rule
is
a
little
more
general
to
kind
of
support.
Those
kind
of
Messier
cases,
but
for
the
most
part,
if
we
keep
this
rule,
then
we
shouldn't
have
conflicts.
So,
let's
see
how
that
applies
to
our
earlier
situation,
so
we're
on
master,
we
brand
Joff
and
do
some
work
on
our
binary
file.
A
But
this
time,
when
we
pop
back
onto
master,
we
get
an
error
because
we've
tried
to
add
a
commit
that
doesn't
descend
from
all
the
previous
commits
on
that
file.
So
it
says:
hey
you
didn't
descend
from
this
commit
over
here
and
at
this
point
we
have
a
couple
of
options
so,
rather
than
making
this
commit,
which
we
can't
do,
we
can
so
we
can
like
one.
We
could
just
throw
away
the
feature
branch.
We
could
just
be
like
that
not
important
we're
gonna.
A
A
We
can
also
finish
their
work
on
the
feature,
branch
and
merge
that
back
into
master
first,
because
once
we
do
that
now
we're
descending
from
that
work,
and
so
in
this
way,
the
rather
than
having
the
the
lock
and
unlock
of
file
locking,
which
is
like
a
separate
state
on
top,
we
kind
of
encode
that
into
the
graph
itself,
so
your
lock
operation
kind
of
becomes
a
commit,
and
then
your
unlock
becomes
kind
of
like
a
merge.
It's
not
exactly
one
to
one,
but
it
sort
of
integrates
it
like
that.
A
The
nice
thing
about
this
is
that
you
can
branch.
However,
you
want
like
this
doesn't
depend
on
having
a
single
master
single,
centralized
anything
really.
For
the
most
part,
you
can
create
two
separate
branches
and
do
all
the
work
you
want
to
do
there
as
long
as
you
know
that
you
don't
aren't
going
to
merge
back
and
then
you
make
sure
that
everything
stays
as
a
path.
A
And
look
kind
of,
like
I
was
already
mentioning,
like
there's
no
state
to
manage
here,
because
it's
all
embedded
in
the
commit
graph
on
top
of
that
locking
and
git
has
kind
of
always
been
a
pain
because
adding
a
manual
lock
and
unlock
command
ever
before
you
touch
every
file,
it's
just
a
total
pain,
especially
on
Windows,
where
most
people
use
like
GUI
clients
right.
So
if
your
GUI
client
doesn't
support
that
extra
command
in
there
you're
kind
of
stuck
the
nice
thing
about
this
is
that
this
is
all
implicit
in
the
gate
graph.
A
A
So
if
you've
been
carefully
watching
you're,
probably
thinking,
but
how
do
we
validate
that?
If
all
the
work
is
on
separate
repositories?
So,
in
our
earlier
situation,
we
constrained
ourselves
to
having
a
local
repository,
mostly
for
simplicity,
but
in
reality
all
this
work
happens.
You
know
locally
right,
you
might
have
a
developer.
A
So
we
kind
of
need
a
system
to
give
you
information
about
the
rest
of.
What's
going
on
in
the
developers
repositories,
one
of
the
nice
things
about
the
way
that
get
graphs
work
is
that
they
can
easily
combine
that
can
be
easily
unions.
So,
if
we
imagine
some
like
ethereal
like
global
graph,
that,
like
is
the
constant
unioning
of
all
of
the
developers,
local
repositories,
that's
kind
of
what
we
want.
A
So
it's
kind
of
this
weird
system
that
every
time,
basically
the
way
it
works
is
every
time
you
change
a
local
repository,
that's
registered
in
the
global
graph.
It
synchronizes
everything
in
that
local
repository
up
into
the
graph,
and
then
you
can
query
it
like
a
normal
gait
repository,
except
that
it
happens
to
reflect
all
of
the
local
state
as
well
open
source.
It's
written
in
rust,
because
rust
is
fun.
A
Rust
is
also
cross-platform,
which
is
at
least
for
windows,
but
yeah
I
thought
this
was
kind
of
an
interesting
system.
I
can
go
into
a
little
more
details
right
now.
It's
implemented
fairly
naively,
it's
just
basically,
every
time
the
the
repository
changes
it
force
pushes
up
all
the
commits
and
all
the
branches
and
just
makes
sure
to
namespace
them.
So
you
don't
kind
of
conflict
with
branch
naming,
but
and
then
it
provides
like
a
HTTP
API
for
like
querying
it,
although
you
could
also
just
use
it
like
a
normal
repository.
A
A
I
also
think
it
could
be
useful
just
in
general,
if
you
had
some
use
case
where
you
wanted
to
have
more
insight
into
what
the
rest
of
the
developers
are
doing
so
I
thought
it'd
be
interesting
present
and
if
you
have
thoughts
on
you
know
what
could
be
used
for
I.
Don't
know,
definitely
come
talk
to
me
afterwards.
A
Another
nice
thing
is
that
it
can
use
a
standard,
get
authentication,
it's
a
it
would
be
total
pain.
If
you
had
to
like
set
up
some
like
we've,
talked
about
file
locking
now
you
have
like
a
concept
of
an
owner
right
like
we
want
to
be
able
to
use
like
the
way
that
get
works
on
the
authentication
side.
So
we
don't
have
to
change
all
of
our
infrastructure
around
that.
A
It
gives
every
local
repository
a
just
a
unique
UUID,
like
it's
just
a
kind
of
a
rated
hash
of
just
for
that
repository,
so
it
can
be
referenced.
So
that
way
you
can
say,
okay,
I
know
it's
on
this
repository,
which
I
know
is
on
this
computer
and
I
can
go
look
at
that
branch
and
yeah
either
you
know
push
that
work
up
to
master
or
at
origin
so
that
you
can
then
use
it
or
you
know,
delete
that
branch
and
say
I'm
done
with
it.
I
don't
want
to
use
it.
So
this
is
again.
A
This
is
basically
this
is
a
fairly
simple
layer
on
top
of
global
graph.
The
goal
is,
to
you
know,
separate
them,
rather
than
having
a
big
complex
system
like
file,
locking,
but
that's
kind
of
for
the
most
part.
The
the
interesting
parts
there's
definitely
a
lot
of
further
work
here,
I've
kind
of
simplified,
a
lot
of
the
the
binary
conflict,
stuff
and
and
for
the
most
part
this
this
is
this
works,
but
there
are
a
lot
of
situations
where
maybe
you
do
want
to
have
purposefully
diverging
branches
right
you
might
want
to
like?
A
Have
a
release
branch
that
is
for
maybe
like
a
console
version
of
your
game
and
all
the
images
they
are
going
to
be
different,
but
we
don't
want
that
to
constantly
be
stopping
the
work
on
the
mainline
game
right.
So
there
are
situations
where
you
do
want
parallel
edits
and
so
there's
the
systems
we
can
kind
of
like
layer
on
top
to
sort
of
have
better
layers
of
safety
and
as
well
we're
talking
about
earlier.
Like
you
know
this,
this
really
only
works
at
the
the
git
level.
A
So
for
the
most
part,
this
is
great,
but
we
really
want
something
that
integrates
earlier.
So
the
nice
thing
about
the
way
this
works
there
once
because,
once
you
solve
the
git
problem,
local
changes
are
still
pins
to
a
commit,
so
the
file
system,
layer
and
all
that
stuff
doesn't
really
have
to
worry
too
much
about
the
graph
itself.
It
can
just
kind
of
work
at
more
of
a
local
layer,
but
there's
lots
of
work
there
to
be
done
too,
but
yeah
I,
don't
know,
that's
that's
about
it.