►
From YouTube: Git & version control in the enterprise - Git Merge 2019
Description
A panel conversation with Atlassian, GitHub and GitLab, featuring:
- Erik van Zijst, Principal Engineer, Atlassian
- James Ramsay, Product Manager, GitLab
- Briana Swift,Trainer, GitHub
Facilitated by CB Bailey, Developer, Bloomberg
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
I'm
I'm
absolutely
delighted
to
be
able
to
facilitate
this
panel.
It's
on
get
and
version
control
in
the
enterprise.
I
go
ask
my
panel
to
introduce
themselves
and
maybe
also
tell
me
a
bit
about
how
they
were
first
introduced
to
get
and
what
their
reaction
was.
I'll
go
first,
so
I'm
CB
I've
already
been
introduced.
A
My
my
first
introduction
was
when
a
colleague
over
a
decade
ago
said,
if
you
heard
about
this
new
version
control
system
that
Linux
Torvalds
is,
is
writing.
I
said
no
I
haven't.
Actually
what
is
it?
He
said.
Well,
it's
kind
of
distributed
so
like
everybody
has
like
their
own
copy
of
the
repository
and
like
anybody
can
kind
of
like
make
a
new
version.
I
said
well
hold
on
a
moment
that
doesn't
make
any
sense.
A
B
C
C
Breanna
Swift
I'm,
a
github
trainer,
so
I
spend
a
lot
of
time
talking
about
git
and
github,
so
I
love
getting
merged.
Y'all
are
my
people
here.
My
first
experience
with
git
was
just
typing
stuff
into
a
black
box,
because
the
internet
told
me
to
and
I
did
not
understand
it
for
a
very,
very
long
time,
once
I
really
royally
screwed
up.
That's
when
I
first
started
to
like
like
oh.
This
is
why
people
want
version
control
and
yeah,
obviously
I've
been
using
it
ever
since
I'm.
D
James
Ramsay
product
manager,
gitlab
working
on
the
the
get
bits
of
get
lab,
I
think
it's
the
easiest
way
to
summarize
it
and
my
first
experience
of
get
was
when
I
was
using
CVS
in
2008
and
it
ate
my
data
without
me
realizing
and
so
then
I
started
exploring
other
alternatives
and
I
think
back.
Then
we
were
self
hosting
our
own
get
server,
I!
Think
back!
A
Awesome
so
I
think
it's
almost
coincidence.
It's
like
a
common
theme
of
like
you
know
what
what
is
this
decentralized
part
to
it,
and
this
distributed
nature
and
I
kind
of
think.
When
you
look
at
most
enterprises,
most
enterprises
are
very
much
around
centralization.
You
know
when
the
typical
version
control
tool
before
enterprises
started
using
it
was
kind
of
like
yes,
here
is
our
global
central
repository
here
is
we
we
keep
our
code,
it's
central,
it's
safe,
secure
everything!
Everybody
comes
to
the
central
truth.
A
How
is
it
that
git
has
been
so
widely
adopted
in
enterprises
when
you'd
think
kind
of
just
know
evie
that
it's
not
actually
that
that
that's
suitable
at
all
for
that
sort
of
environment?
And
it's
really
I
mean
caring
or
going
in
this
order
for
a
while,
and
then
you
know,
yeah
butting
in
and
any
orders
you
see
foot
and
then
I
can
use
my
moderating
yeah
yeah.
B
I
guess
start
I,
don't
know
really
I
get
it
is.
It
is
a
little
weird
that
a
in
some
ways
that
a
that
a
tool
that
and
not
only
sort
of
was
designed
for
a
fairly
specific
task
in
in
open
source.
This
this
one,
this
one
repo
and
a
very
specific
workflow-
that
in
amongst
the
sea
of
SCM
tools,
not
like
their
war,
no
no
other
SCM
tools,
their
professional
tools
that
were
good
tools
that
also
it
had
a
terrible
UI.
B
Let's
be
honest,
it's
still
done,
but
now
there's
that
go
we're
following
a
Google
everything
but
ten
years
ago,
is
different,
that
that
would
you
know
make
it
into
sort
of.
You
know
the
de-facto
SEM
not
just
for
open
source
but
everywhere,
and
so
I'm,
not
quite
sure
like
on
the
one
hand,
there's
the
technical
merits
like
it
is
is
very
fast
to
use.
C
I
really
agree:
I
think
that
you
know
version
control,
especially
at
a
get
conference.
We
think
so
much
about
the
really
really
detailed
zoomed
in
view
and
from
my
experience
when
I'm
working
with
you
know,
developers
new
to
get
that's
really
not
where
their
heads
at
they're,
like
some
of
the
talks
earlier.
Just
how
do
I
do
my
job?
How
do
I
get
through
today
with
get
and
that's
the
collaboration
it
whether
it's
distributed
or
not
whether
they're
using
it
as
its
distributed
or
not,
is
it
might
be
secondary?
D
A
So
I
mean
it's
kind
of
just
as
summarized
it's
kind
of
like
it's
it's
it's
almost
by
surprise.
That
gets
so
widely
adopted.
I
opted
kind
of
in
the
enterprise
and
kind
of
thinking
of
situations,
I've
come
across
I
think
a
lot
of
its
kind
of
been
sort
of
from
the
ground
up,
so
you
sometimes
get
kind
of
like
teams
going.
You
know
our
existing
processes
are
slowing
us
down.
Let's
just
do
a
little
git
thing
and
then
it
becomes
popular
enough.
It
becomes
kind
of
trending
and
people
want
to
adopt
it.
A
So
I
wonder
about
typical
typical
kind
of
use
cases
and
users
in
the
enterprise.
How
do
their
needs
differ
from
from
kind
of
like
open
source
users?
What's
the
challenges
forget?
How
do
how
do
people
have
to
use
it
differently
and
and
I
guess
you
know,
are
these
tools
we've
built
on
top
of
git
kind
of
addressing
that
gap?
I.
D
Differences
in
how
open-source
projects
use
get
to
large
enterprises,
particularly
open
source
projects,
are
using
a
forking
model
where
everyone's
got
a
distributed
copy
of
the
repository
and
then
a
sharing
it
back
with
each
other,
whereas
most
large
enterprise
customers
have
one
repository
or
a
couple
of
big
repositories
and
make
use
of
a
branching
model.
So
the
kinds
of
access
controls
they
need
are
quite
different
developers,
often
empowered
to
merge
things
quite
easily
and
quickly,
whereas
in
an
open-source
community
there's
a
pretty
small
ring
of
maintainer
x'
and
only
those
have
write
access.
D
B
I
tell
you
anything:
is
that
much
to
add,
but,
like
the
biggest
thing
I
think
is
stricter
controls
or
at
least
different
kinds
of
controls.
With
you
know
it's
a
typical
branch
of
workflow,
it's
at
the
center
of
it,
and
so
therefore
you've
got
permission
permission
model,
not
just
as
the
gatekeeper
towards
a
repository,
but
on
individual
branches
or
even
certain
operations
on
a
branch
return.
He
can
you
can
rebase
or
which
branch
you
can
read
base
on.
Who
can
do
that?
B
Whether
or
not
changes
can
go
in
you
know
without
a
pull
request
or
if
they
have
to
go
through
a
floor
gastic
the
what
kind
of
requirements
there
are
before
pelorus
can
be
merged.
There's
a
lot
of
kind
of
stuff
that
you
know
in
a
typical
open-source
project,
or
at
least
sort
of
the
the
more
established
ones
that
use
mailing
lists
and
patches
still
that
that's
quite
different.
A
That's
very
different,
so
I
really
enjoyed
a
lot
of
the
talks
that
you've
had
earlier
today,
and
especially
some
of
the
talks
about
kind
of
scale
and
how
we
have
incredibly
large
repositories
and
kind
of
thinking
about
it.
All
these
all
these
enterprise
features
the
ability
to
handle
kind
of
huge
repositories
now
at
node,
so
technically
Android
is
open
source
and
therefore
it's
like
a
bit
of
an
exception,
but
it
is
kind
of
driven
fairly
heavy
by
an
enterprise.
A
B
Yeah
I,
don't
know
the
I
think
it's
a
really
difficult
one
like
mono
repos
are
a
like.
Yoanna
had
a
really
good
talk
on
it
this
morning
it
was
fantastic,
yeah
and,
and
and
even
he,
instead
of
after
looking
at
the
resource
and
whatever
sort
of
you
know
concluded
that
III
didn't
know
like
them,
both
work,
I
suppose
in
and
I
guess,
there's
evidence
of
that
right.
There
is
there
people
that
that
it
divides
a
little
bit
right.
It's
people
that
really
believe
in
like
the
kimono
repo.
B
For
you
know,
those
kinds
of
enterprises
really
is
the
way
to
go,
and
you
know
breaking
it
down
into
smaller.
Repos
really
isn't
and
there's
people
that
argue
the
other
way
around
I
don't
know
if
I
necessarily
in
a
in
the
best
position
to
be
the
judge
of
that
I
do
not
work
on
a
mono
repo.
We
do
not
have
like
what
you
would
call
a
mono
repo,
but
it's
obviously
something
that
we
were
interested
in,
because
it's
not
necessarily
about
us.
B
D
We
see
the
request
for
large
repositories
pretty
frequently.
It
is
a
small
minority
of
organizations
that
have
truly
large
repositories
in
the
the
scale
of
chromium
or
Android,
or
even
bigger
and
they're,
often
migrating
from
systems
that
are
not
get
so
that
they're
trying
to
enter
get.
They
may
have
already
migrated
all
their
other
projects
to
get
and
there's
one
last
holdout
in
some
other
version
control
system.
D
But
a
lot
of
the
discussion
around
mono
repo
is
like
is
is
really
around
the
ergonomics
of
dealing
with
lots
of
repos,
not
necessarily
the
the
scaling
problem,
and
sometimes
those
two
problems
can
be
conflated,
gets
making
a
lot
of
progress
in
supporting
larger
and
larger
repos
more
and
more
effectively,
but
yeah
I
think
that
there's
also
a
parallel
set
of
tooling.
That
is
solving
some
of
those
different
problems
around
managing
lots
of
services
that
are
maybe
all
hosting
the
same
repository.
But
it
could.
D
C
So
I
think
mono
repos.
Today,
that's
like
the
hot
topic
I
mean
we
can
talk
about
it
for
hours,
but
I
think
what
I
find
really
interesting
is
that
they're?
A
really
great
example
of
you
know
whether
it's
mono
repos
or
the
next
thing
that
it
can
do
it
really
well
either
way,
but
still
there's
this
this
hunger,
this
you
know
you
many
I,
feel
enterprise
customers
just
want
you
to
tell
them
what
to
do.
Just
tell
me,
which
is
the
right
way,
whether
it's
gonna
be
a
mono
repo
or
break
it
up.
C
B
Does
bring
up
a
good
point
right
like,
as
you
said,
like
a
lot
of
our
customers.
I
think
ultimately
are
looking
up
to
the
vendor
to
see
like
yeah
I.
Don't
know
like
you
guys
must
know
like
of
anyone
like
what
should
we
be
using.
You
know
think
that
is
a
like
I
think,
that's
a
bit
of
a
like
a
requirement.
B
D
There's
a
space
for
guidance,
but
then
there's
also
a
space
for
every
customers
going
to
have
their
own
demands
and
as
much
as
a
vendors
going
to
provide
guidance
that
we
think
this
works
well
like
say:
mono
repo
works.
Well,
because
you
don't
need
to
deal
with
merge
requests
in
20
different
places.
D
A
D
We're
working
on
this
at
the
moment.
We
have
this
problem
with
how
we
have
our
repository.
Structured,
get
labs,
got
a
monolithic
rails
application
which
is
the
the
web
application
and
then
a
range
of
other
components
like
giddily
and
some
other
services
and
each
being
a
separate
repository
every
release.
We
have
to
bundle
them
up
and
changes
often
touch
multiple
components
in
the
system.
B
Maybe
even
github
I
can
call
those
things
as
well,
and
you
know
you
can
you
can
build
a
a
huge
large
index,
an
actual
code
index
and
at
that
point,
like
I,
think
it's
possible
to
make
the
scenario
a
lot
better
right.
We're
like
I
am
going
to
refactor
this
thing.
Who
is
it
gonna
impact,
and
it's
not
just
a
matter
of
of
you-
know,
sort
of
knowing
that
Judy's
library's
used
there,
so
they
were
probably
talked
to
the
the
maintainer
of
this
other
thing.
A
D
A
Yeah
and
I
found
kind
of
personal,
a
side
story.
It's
kind
of
like
a
I,
find
that
I
fully
trust,
get
grep
to
find
all
instances
of
a
local
repository.
I
have
here
any
sort
of
code
search,
that's
been
kind
of
like
indexed
and
I
know
that's
kind
of
like
magic
index.
It's
a
sign.
The
scene,
I
always
kind
of
think.
Is
it
up-to-date?
Is
it
working?
Has
it
found
everything
so
so
yeah
we've
got
to
kind
of
build
built,
fill
the
ability
to
trust
our
tools
and
yeah.
It
depends
a
bit
on
the.
B
A
I'm
gonna
change
tack
a
little
bit
and
talk
about
kind
of
like
him,
users,
learning
and
training.
So
it's
kind
of
like
open
source
projects
to
tend
to
kind
of
use
tools
that
are
kind
of
chosen
by
the
maintainer
and
the
kind
of
kind
of
core
developers
and
it's
kind
of
in
enterprises.
A
lot
a
lot
of
times.
Kind
of
tools
are
mandated
is
is
get
accessible
enough
to
their
to
the
average
developer
or
even
designer
or
somebody
else
who
needs
to
make
changes.
Can
we
make
it
easier?
Should
we
make
it
easier?
I.
C
Could
talk
about
this
I
think
yes,
get
is
accessible.
That
does
not
mean
it's
easy,
I.
Think
one
of
my
favorite
things
during
a
git
and
github
training
is
helping.
Somebody
who
really
does
not
think
they
can
learn
get
and
also
really
just
doesn't
want
too
much
like
the
design
speech
earlier
you're
like
going
through
a
few
things
and
actually
doing
it
and
seeing
okay.
This
is
clicking,
even
if
I
don't
necessarily
understand
the
big
picture,
yet
just
enough
to
do
something
that
I
can
be
successful.
C
It's
a
horrible
feeling
to
already
be
in
your
career
established
at
you,
know
a
large
company
and
then
have
to
learn
something
that
at
least
when
I
learned
get
it
just
made
me
feel
like
such
an
idiot.
You
know
like
that.
Sucks
nobody
likes
that,
but
having
trained
so
many
people,
it's
also
I
think
a
great
opportunity
for
them
to
have
that
lightbulb
moment
again
and
hopefully
be
become
excited
about
it.
That
being
said,
I
definitely
think
we
can
always
be
improving,
how
we
teach
it
and
how
we
help
people
use
it.
B
D
I
think
there's.
This
is
there's
a
lot
of
work
that
has
happened
over
the
past
years
to
improve
some
of
the
commands
of
get
to
make
them
more
easy
and
there's
some
proposals.
I
think
out
there
to
streamline
some
of
the
common
commands
and
in
favor
of
some
new
ones.
So
I
think
that's
really
exciting
to
see
that
the
courgette
project
is
working
to
make
the
command-line
tool
easier
to
use,
but
I
think
there
also
is
a
big
market
of
all
these
desktop
clients.
D
I
think
you,
you
have
the
github
desktop
and
the
Lycian
source
tree
and
there's
Tower
and
a
whole
bunch
of
other
great
vendors
out
there.
Building
these
amazing
visual
tools
to
help
people
not
only
use
get
successfully,
but
also
exposed
more
of
like
the
underlying
capabilities.
I
think
it's
very
hard
for
a
new
user
to
often
get
their
head
around
rewriting
history
and
that's
one
of
the
most
powerful
things
that
you
can
do
on
a
git
branch.
D
I
know
that
some
organizations
don't
like
that
and
it's
you
never
want
to
do
it
on
a
master
branch,
for
example,
but
don't
make
that
mistake,
but
exposing
that
to
new
users
and
helping
them
feel
powerful
and
feel
successful
user
get
I.
Think
is
a
really
great
thing,
because
it's
not
just
about
get
add
git
commit
get
push
like.
D
A
I
certainly
enjoy
the
joy,
the
power
of
it,
but
I
guess
I
guess
backwards,
compare
back
with
compatibility
as
the
spectra
in
the
room,
because
you
know
all
of
the
git
commands
that
people
are
very
experienced
with
it
familiar
with.
They
don't
want
them
to
change
suddenly
under
them,
so
and
and
and
it's
it's
it's
so
flexible.
So
I
guess
my
the
question
that
I
least
like
to
answer
from
from
somebody
who's
asking
for
help
is
is
well
what
does
get
pushed
without
arguments
do
and
it's
kind
of
like.
Well
that
depends.
A
B
C
C
Say
actually,
I
think
something
in
training,
as
you
know,
get
enthusiasts.
It's
so
has
taken
me
time
and
I
still
struggle
with
no
not
telling
them
too
much.
I
can
be
so
excited.
I
can
give
them
the
long
answer
and
I
really
want
to
and
knowing
when
that's
just
not
right
for
them.
At
that
moment,
you
know
what
do
they
need
to
hear
to
move
their
understanding
along
meaningfully
and
keeping
my
own
excitement.
D
D
B
I
think
that's
really
important.
Right,
like
you,
can
be
effective
and
I
think
a
lot
of
like
sort
of
in
average
or
whatever
good
engineers
developers
that
just
use
these
tools
to
get
their
worked
on.
They
can
get
by
very
far
without
you
know,
knowing
how
to
rebase
and
how
to
reset
and
do
all
these,
these
kind
of
things-
yes,
sometimes
it's
necessary,
but
I,
don't
think
it's
necessary
to
immediately
understand
all
that
kind
of
stuff
and
in
fact
it
might
be
better
to
maybe
not
immediately.
B
You
know
jump
on
that
and
so
I
feel
that
maybe
sometimes
new
engineers
sort
of
get-get
hand
at
this.
This
sheet
of
these
are
the
things
you
need
to
do
when
you
already
to
rebase
and
you
need
to
force
push
to
I
know
what
that
is.
Yeah
I'll
just
do
it.
Oh,
it
seems
to
work
like
that's
a
dangerous
thing
in
that
comes
back
in
support
cases.
Cuz,
you
know
blows
up.
Sometimes
they
you
have
no
idea
what
to
do
know
like
again
I
think,
there's
a
responsibility
for
it.
B
For
us
I
mean
that's
you're,
a
trainer.
If
you
do
that
stuff
all
the
time,
but
for
our
products
to
to
guide
people
towards
you
know
like
a
sense
of
workflow
like
that,
you
know,
we
know,
is
a
good
place
to
start
and
not
overload
them
with
all
these.
Like
things
that
you
know
it
could
do
and
sensible.
D
A
C
Surviving
get
in
the
enterprise.
That's
that's!
That's
a
big
one,
I
guess,
if
you're
ever
I
think
in
the
enterprise
there's
an
assumption
that
people
may
already
know
stuff
that
they
don't
know,
and
it's
there's
people
maybe
not
ask
questions,
even
though
they
have
them.
So
whenever
you're,
interacting
with
someone
I'm
in
my
experience,
just
don't
assume
that
they
know
something.
You
know
you
don't
need
to
be
insulting
and
talk
down
to
them,
but
it's
also
okay,
I'm,
like
the
first
person
to
say
I,
don't
know
everything
about
git
and
I.
A
D
We
can
reward
users
that
do
those
right
things
and
streamline
those
workflows
and
sort
of
I.
Don't
not
gamify
like
that's
that
can
be
quite
annoying,
but
just
magnify
the
benefits
of
best
practices
so
that
even
someone
who
just
stumbles
into
get
lab
or
and
does
something
well
like
it
just
makes
their
life
easier.