►
Description
Presented by Johan Abildskov, Trainer & Consultant, Praqma
"Perhaps even more controversial than rebase vs. merge is Mono vs Many-repos. During my consultancy career I've helped companies go in either directions, with good reasons for both transitions. This talk will remove the gut-feeling part of deciding your repository structure, and instead dive into the available tools and considerations for deciding what is the right repository structure for your organisation based on science and technology."
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
Okay,
thank
you.
So,
let's
move
on
I
did
not
write
the
book
of
DevOps,
but
I
did
write
the
song
at
DevOps
taste
Copenhagen.
So
if
you
want
some
very
crunchy
singing
then
go
find
that
on
YouTube
I
teach
get
I've
taught
get
to
hundreds
of
developers
of
all
skill
levels
and
I
maintain
the
get
catus,
which
is
an
open-source
set
of
exercises
that
you
can
just
use
and
please
help
us
improve.
A
So
my
story
about
found
repositories
that
we're
going
to
talk
about
is
that
I
have
a
day
on
site
at
a
client
and
the
officers
were
not
this
nice.
But
this
is
me
sitting
at
a
computer
and
then
a
manager
dreadfully
comes
in
and
he
says,
building
our
software
is
too
complex
and
I
was
like
well,
it's
only
Jenkins,
some
Gradle
at
the
factory
and
a
few
hundred
git
repositories.
A
This
is
this
is
easy
and
I
understand.
This
is
simple
and
and
I
was
like.
I
became
angry
monolithic,
repository
suck
I,
don't
care,
don't
put
your
source
code
in
one
repository
and
and
and
I
literally
I
got
angry
and
that
were
a
finger.
I
was
being
a
bad
consultant
right.
I
was
not
helping
anyone.
This
was.
It
had
become
personal
to
me
that
I
had
some
arbitrary
hate
uninformed
about
monolithic
repository
structures,
so
I
thought
we
we
have
to
think
about
this.
We
have
to
learn.
A
We
have
to
figure
out
what's
the
right
way
for
us
to
do
stuff,
so
obviously
I
go
to
the
internet
and
then
I
recently
I
read
this
from
a
dumb
joke.
Oh
please
do
monolithic,
repossessor
structures
which
of
course
hat
please
don't
as
a
follow-up,
so
that
did
not
make
me
any
smarter,
but
that's
generally,
the
tone
and
the
gate
community
at
large
just
doesn't
care
many
things
and
give.
How
should
I
do
this
and
get
well?
A
A
A
So
I
would
like
to
look
a
bit
into.
How
do
we
reason
about
anything?
Really
we
like
to
do
science,
so
there
are
some
statements,
that's
drug,
and
we
want
to
investigate
whether
that
lowers
the
cholesterol
of
people
and
that
should
lead
to
fewer
heart
attacks.
Right,
that's
our
hypotheses
and
we
can
test
that
they
do
double-blind
studies
and
figure
out.
Well,
this
works.
So
perhaps
you
should
trust
your
doctor
in
terms
of
software.
This
is
probably
the
best
research
in
suffer
delivery
performance
we
have
currently.
A
A
So
these
this
is
your
homework
and
then,
if
you
want
to
go
more
into
the
details
of
the
science
of
how
they
figure
out
all
these
things,
then
you
can
read
the
awesome
accelerate
book.
But
basically
this
book
is
about.
We
want
to
meet
organizational
goals,
also
known
as
make
money.
In
most
cases,
we
have
a
theory
that
software
delivery
performance,
as
measured
in
these
five
metrics
metrics
deployment
frequency
lead
time
time
to
restore
change,
failure,
rate
and
availability.
A
A
A
That
is
the
current
state
of
the
science
of
these
things.
This
is
not
double-blinded
studies,
it's
not
like
you
pick
a
company
and
they
don't
get
to
do
TDD,
but
it's
it's
the
best
bet
at
least
in
these
days,
but
but
what
I
want
to
talk
a
bit
about
is
what,
if
the
way
that
we
think
about
repository
structure
negatively
impacts
our
ability
to
deliver
software
efficiently.
A
And
how
do
we
figure
that
out
when
people
are
just
yelling
on
Twitter,
so
I'll
just
look
a
bit
in
some
at
least
some
repository
and
see
patterns
to
say
some
places
that
we
feel
pain
and
it
could
be
the
no
tooling
mono
repo,
the
monolithic
repository
that
grew
too
big,
because
it
was
a
success.
It
was
easy
to
work
with.
In
this
case
we
get
launcher
integration
times,
because
you
have
made
perhaps
a
change
in
a
small
area
of
the
code,
and
you
need
to
test
all
the
code.
A
Because
what,
if
something
broke,
we
can
see
some
performance
I,
unfortunately
had
to
to
get
met.
An
add
up,
so
I
missed
most
of
the
talk
by
the
Google
guys,
but
I
for
sure
will
check
it
when
it's
really
released,
but
they
they
have.
Such
insane
capabilities
of
scaling,
those
capabilities
are
not
present
in
the
average
company
we
can
get
lockstep,
keep
pushing
your
push
push
redirected
because
it
was
not
a
fast-forward
merge,
but
on
the
other
hand,
this
is
the
extreme
simple,
its
simplicity.
A
So
when
we
have
the
integration
team,
which
is
the
biggest
anti-pattern
Emer,
you
have
full-time
employees.
That
does
nothing
but
except
pull
requests.
If
you
have
such
advanced
tooling-
and
you
know
there
will
be
some
boss-
someone
shows
up
in
a
suit
and
say
well.
This
needs
to
be
fast
forwarded.
We
have
priority
boarding
for
this
feature,
so
you
break
all
the
security
gates
you
have,
and
then
we
have
the
distributed
monolith,
which
is
probably
the
most
common
scenario,
because
that's
where
things
become
very
difficult,
because
it's
about
software
architecture
and
that's
difficult.
A
A
That's
that's
how
you
decompose
a
monolith
excellent,
but
then
we
end
up
in
a
situation
like
this,
which
is
completely
made
up,
suffer
situation
and
someone
shows
up
in
a
suit
and
says
I
want
the
web
app
to
be
able
to
do
something,
and
then
you
need
to
make
a
commit
in
the
web
app.
But
you
also
touch
the
gooey
repository
and
you
need
to
charge
the
math
because
of
some
way
you
calculate
some
serious
CSS
properties.
A
A
So
the
boring
conclusion
is
I'm
not
going
to
tell
you
that
you
should
do
either
monolithic
repositories
or
the
other
that
we
don't
have
a
good
name
for,
but
hopefully
we
will
talk
a
bit
about
how
you
can
figure
something
out.
So
Google
also
published
a
study
at
the
beginning
of
last
year
on
their
monolithic
repository
where
they
surveyed
a
lot
of
developers
trying
to
figure
out.
Is
it
a
sane
way
to
work,
and
this
study
is
publicly
available,
so
you
can
go?
Read
it
I'll,
just
sum
it
very
briefly.
A
Up
generally,
people
are
very
happy
about
working
with
software
in
the
in
the
Google
way
a
they
generally
see
that
it
has
an
impact
on
velocity.
The
study
does
not
say
whether
it's
a
positive
or
negative
impact,
but
I'm
assuming
positive,
and
they
also
see
a
huge.
This
is
a
satisfaction
with
working
them
with
the
monolithic
codebase
compared
to
previous
multi
repository
based
code
bases.
So
that's
a
huge
improvement
and
they
actually
also
did
some
stat
tracking
by
pulling
out
data
where
people
were
touching
code.
A
A
The
fact
that
you
have
complete
visibility
on
the
code
base
not
only
that
you
can
use
it,
but
also
that
you
can
see
it
on
browsers,
see
how
API
is
are
used,
but
primarily
they
see
that
the
developer
tooling
around
working
this
way
is
excellent.
So
those
are
the
three
key
wins
from
working
in
the
Google
monolithic
way.
According
to
this
survey,.
A
Then
another
of
the
fun
companies
Netflix
also
publish
a
lot
of
information
and
they
actually
do
a
multi
repository
set
up,
but
kind
of
is
trying
to
go
to
poley
or
it's
difficult
to
figure
out
what
their
plans
are,
but
they
posted
this
excellent
blog
post
and
basically,
the
conclusion
is
dependency.
Management
is
hard,
which
is
true
in
many
cases
when
we
do
monolithic
repositories,
it's
because
we
forget
to
explicitly
manage
our
dependencies
dependency
management
is
hard.
Do
you
want
code
churn,
or
do
you
want
overhead
and
managing
complex
situations?
A
Uber
has
have
a
very
great
success
in
starting
in
a
monolithic
repository,
then,
as
they
scaled
to
thousands
of
developers
or
grew,
have
scaled
into
multiple
repositories,
using
off-the-shelf
products,
commercially
available
products
and
and
then
they're
talking
about
moving
to
what's
more
monolithic
repository,
because
now
they
are
at
a
scale
where
they
can
invest
heavily
in
developer.
Tooling
they're
also
called
this
the
Madrid
condo
approach.
A
A
A
A
In
the
lean-to,
your
Takata
environment,
we
have
the
go
to
compact,
go
and
see
so
we
want
to
go
investigate
so
now,
we'll
look
at
some
concrete
cases
and
I'm
going
to
just
show
some
an
anonymized,
the
visualizations
of
some
work.
We
did
with
the
customer
and
it's
a
customer
that
we
moved
from
clearcase
to
get
with
tens
of
thousands
of
base
lines
into
hundreds
of
repositories
with
a
huge
amount
of
C
code
and
perhaps
a
place
where
they
have
too
many
repositories
or
different
or
bad
or
wrong
repositories,
because
it
generates
friction.
A
A
Because
git
is
awesome
and
if
you
want
to
learn
a
new
programming
language
and
the
goal
was
to
mainstream,
then
I
recommend
groovy,
which
is
an
excellent
scripting
language,
so
just
go
through
all
the
repositories,
also
using
the
repo
tool.
That's
also
a
nice
tool
for
working
with
multiple
repositories.
A
Then
we
just
pulled
out
tickets,
zero
tickets
from
commit
messages
because
everything
needs
to
be
traceable.
So
in
an
enterprise
world,
of
course,
you
reference
your
JIRA
ticket
in
the
commit
message
and-
and
the
interesting
part
is-
is
these
collisions?
So
we
see
something
going
to
what,
for
instance,
this
I
promise
you,
the
guitar,
is
not
that
project
key,
but
that
might
be
a
tooling
task.
This
guitar,
because
we
actually
see
that
task
in
all
of
the
repositories,
and
that
at
least
is
something
that
generates
overhead.
A
And
if
you
have
to
do
one
task
in
the
tooling
team,
you
have
to
charge
80
repositories,
that's
bad.
We
also
see
see
things
like
box
box
that
you
need
to
fix
in
multiple
repositories
and
also
features
that
needs
to
touch
multiple
repository
to
be
completed,
and
this
at
least,
is
something
that
does
not
look
like
a
very
loosely
coupled
architecture.
A
So
this
is
an
extremely
simple
way
of
getting
some
place
to
start
looking
across
repositories.
These
are
candidates
for
stuff
you
could
mesh
together.
Of
course
you
shouldn't
do
it
naively,
because
I
say
you
can
script
your
way
out
of
this
and
then
you
can
mash
them
together,
but
this
might
be
a
good
starting
point
points
of
the
discussion
also
around.
How
do
we
work
with
our
tooling,
so
they
created
a
new
platform.
They
had
figured
out
that
80
repulsors
that
were
too
many,
so
we
will
only
use
one
right.
A
A
So
now
we
add
a
bit
more
to
store
a
kit.
There's
an
excellent
book
called
your
code
as
a
crime
scene
by
Aaron
Thornhill
that
I
recommend
you.
You
read
allows
you
to
get
a
nice
perspective
on
your
codebase
and
how
it
evolved
over
time.
He
made
an
open-source
tool
called
mat,
a
mode
that
also
helps
with
some
of
this
analysis,
we're
still
using
git
and
groovy
because
awesome
tools
and
then
we've
added
d3.js
to
the
the
mix
together
visualization.
A
So
one
of
the
things
that
we
looked
at
was
in
this
monolithic
platform.
What
what
does
it
look
like
when
we
look
at
it
from
a
team
perspective?
So
we
want
to
be
people
focused,
so
it
fits
with
our
Conway's
law
and
remember
this
is
one
team.
This
is
one
team
working
on
one
repository
and
it
might
be
a
bit
hard
to
see
what's
going
on
here,
but
the
circles
are
generally,
the
larger
circles
are
folders
and
each
color.
That
is
a
developer.
A
A
We
can
see
that
we
have
someone
here.
That
does
a
lot
of
work
here
and
over
here.
These
are
not
proper
class
names,
they're
from
the
enterprise
class
name
generator
for
purposes
of
anonymity,
and
we
also
see
that,
even
though
we
have
two
separate
places,
this
screen
person
is
doing
a
bunch
of
work
here.
We
might
also
have
an
issue
if
we
lose
the
red
person
right.
The
red
person
is
touching
really
many
things,
so
we
might
have
a
bus
factor
issue
here,
and
so
let's
try
to
dive
down
a
bit
deeper.
A
So
this
is
just
half
of
the
figure
that
we
looked
at
before
and
we
see
something
like
we
have
a
sub
team
here.
We
also
kind
of
have
a
sub
team
with
the
this
bright
green
guy
and
the
pink
guy,
and
perhaps
something
in
here
in
advisor
mater
that
we
can
pull
out,
and
we
actually
also
see
a
lot
of
a
collaboration
between
the
the
red,
big
hooter,
sky
and
and
and
this
one
here.
So
there
are,
even
though
that
we
have
one
team.
In
theory,
we
have
one
team
working
on
one
product.
A
A
So
this
is
going
and
see
the
issue
that
we
found
ours
was
the
friction
that
was
too
low
to
change,
so
it
it
isn't
painful
enough.
Yet
for
them
with
this,
which
should
make
me
happy,
but
I'm
still
a
bit
of
a
hater
and
monolithic
repositories.
So
it
was
very
dissatisfying
that
we
couldn't
follow
through
with
this.
A
The
good
thing
about
these
five
metrics
is
that,
if
you're
trying
to
maximize
all
of
them
simultaneously
they're
very
very
hard
to
gain
they're
very
hard
to
do
local
optimizations
on
that
will
sup
optimize
the
entire
process,
and
some
of
my
colleagues
actually
did
not
accidentally
I
assume
they
did
it
very
much
on
purpose.
But
while
I
was
looking
at
this
for
another
customer,
they
looked
at.
How
can
we
in
a
pure
get
fashion,
get
these
metrics
out
of
your
repositories,
so
that
could
be
a
way
to
figure
out.
A
A
Then
I
also
tried
to
do
the
the
cool
visualization
on
the
get
that
gets
a
source
code
because
I
thought
well,
then
I
can
stand
here
and
say:
well,
you
should
split
the
git
repository
this
way
and
people
would
be
really
mad
at
me.
Unfortunately,
I
didn't
really
find
any
anything.
That
was
very
interesting,
so
it
seems
like
it's
a
sane
enough
way
to
do
it.
A
At
least
I
did
not
have
enough
to
main
knowledge
and
the
the
get
cold
pace,
but
I
just
want
to
say
that
Ava
he
rocks
because
over
the
last
year,
he's
the
one
who
has
removed
most
code
from
the
get
code
base.
So
if
we
could
give
ever
hunt
for
for
that,
it's
easy
to
add
code,
it's
very
hard
to
remove
code.
A
A
Our
conclusions
are
not
better
than
our
data,
and
this
seems
like
obvious,
but
people
just
forget
that
all
the
time
so
again
make
atomic
commits
Pauline
will
probably
love
to
discuss
that
with
you
and
make
sure
that
you
put
good
data
in
wherever
you're
working
so
make
good.
Commit
messages.
Make
sure
that
you
have
the
traceability
and
the
data
that
you
need
for
the
conclusions
that
you're
going
to
make
and
then
a
very
important
point.
It
is
extremely
easy
to
discuss.
Should
we
have
a
monolithic
repository
structure?
Should
we
have
Paulo
lithic?