►
Description
This is a short video that explains why this use case is called VC&C, what this use case is comprised of and the problems it tries to tackle making it important and relevant to our users and clients.
VC&C resource page → https://about.gitlab.com/handbook/marketing/product-marketing/usecase-gtm/version-control-collaboration
VC&C Solutions page → https://about.gitlab.com/solutions/version-control/
A
So
hello
and
welcome
to
this
short
video
about
what
is
version,
control
and
collaboration
and
why
it
is
important.
So
the
short
definition
of
what
version,
control
and
collaboration
use-cases
is
that
it
is
a
set
of
features
that
allow
any
company
to
store
safely
manage
access
and
make
changes
to
their
IP
in
the
case
of
gitlab.
That
comprises
a
set
of
categories
that
most
of
them
fall
into
the
create
stage.
A
In
fact,
all
the
categories
in
the
created
stage,
part
of
this
use
case,
but
not
all
of
them,
but
not
all
of
the
categories-
are
exclusive
to
the
create
status
you
can
see.
There
are
several
across
other
stages,
manage
plan
package
and,
on
the
far
right
column,
you'll
see
a
few
categories
that
are
not
either
that
belong
to
the
serious
case
that
are
not
even
part
of
any
any
stage.
A
A
There
are
several
reasons
for
that,
but
the
the
one
one
of
the
main
ones
is
that
the
fact
that
this
use
case
covers
more
ground
than
only
source
code
management,
so
source
code
management
and
code
review,
so
the
ability
to
manage
source
code
and
the
workflows
to
collaborate
and
and
merge
it
and
improve
it
and
make
changes
to
it
or
the
background
of
this
use
case.
They.
They
are
the
central
part
of
this
use
case.
They
are
fundamental,
but
one
of
the
reasons
to
name
this
use
case
version.
A
A
It
is
true
that
at
the
point
in
which
software
is
created,
which
is
the
space
that
this
use
case
covers,
other
assets
are
also
important,
especially
in
the
case
of
Kepler,
because
the
one
of
the
three
top
differentiates
is
listed
in
the
resource
page
in
the
handbook
of
this
use
case
is,
you
need
to
get
lab
and
it's
the
fact
that
it
can
manage
other
types
of
assets.
Think
of
design
management.
A
A
Well,
this
quote
is
from
them
from
1980,
and
it's
still
valid
at
the
at
the
stage
in
which
software
is
created,
changes
constantly
happening
the
problem
that
companies
are
the
problems
that
companies
are
facing
in
this
in
the
state
of
the
of
the
cycle
are
multiple
one
is
that
change
is
constant.
It
constant.
It
comes
from
many
places
it
comes
from
for
me,
it
happens
for
many
reasons,
and
it
can
generate
if
not
properly
managed.
It
can
generate
a
confusion
of
versions.
Also
again,
these
changes
can
be
proposed
by
different
teams
that
might
be
siloed.
A
That
might
not
be
explaining
the
reasons
why
those
changes
are
proposed.
What
is
the
goal
for
that
and
how
they
should
be
articulated
and
merge,
and
that
can
be
eventually
that
can
become
eventually
a
problem,
because
the
communication
between
those
groups
or
even
inside
of
the
those
teams
is
is,
is
broken.
There's
lots
of
information,
there's
lack
of
context,
etc.
There's
not
a
culture
of
short
toes
and
experimentation
and
small-batch
integration
and
there's
actually
cultures
of
finger-pointing
and
blame.
A
So
the
end
result
of
the
problems
just
expressed
right
now
in
the
previous
slide
is
poor
call
quality
so
eventually
integrations
or
changes
proposed
that
are
integrated
into
the
code
line
to
the
main
code
base
of
poor
quality.
For
several
reasons,
the
developer
experience
is
is,
is
not
it's
not
good,
eventually
in
the
long
term,
for
making
it
make
an
employment
turnover
hi,
among
other
other
consequences.
A
The
release
cycle,
the
integration
cycle,
which
is
the
specific
area
that
this
use
case
covers,
is,
is
pretty
long.
So
the
velocity
is
not
something
that
our
people,
this
problems,
companies
with
these
problems
excel
at
and
eventually
they
lose
the
opportunity
to
become
a
significant
player
and
take
advantage
of
destruction
and
a
fast
go
to
market
with
with
the
software
IP.
A
So
so
at
the
foundation
of
their
Bob's
is
proper
version,
control
and
collaboration.
The
solutions
to
these
problems
comes
from
the
ability
to
enable
cross-functional
teams
to
work
together,
not
only
between
teams,
but
also
among
team
members,
to
allow
them
to
iterate
fast
in
small
batches
and
have
the
ability
to
collaborate
to
the
detail
of
the
line
of
code
of
the
pixel.
A
They
can
automate
workflows
as
soon
as
the
workflow
is.
It's
been
done
a
few
times
and
some
parts
can
be
automated.
It
is
easy
to
understand
which
parts
can
be
can
be
subject
to
that
which
eventually
will
make
integrations
and
releases
faster
and
there's
a
cross
team
visibility
of
how
things
work
of
the
context,
of
the
reasons
for
the
proposed
changes,
the
consequences
of
those
and
how
teams
internally
work,
so
that
visibility
allows
groups
to
learn
about
best
practices
elsewhere
and
clear
cases
of
inner
sourcing
and
so
on.
So
that's
it.
Thank
you.