►
From YouTube: SCM Use Case Demo
Description
This is the SCM Use Case Demo (MVC1)
A
The
most
basic
and
key
feature
is
the
fact
that
I
get
lab,
supports,
store
and
get
repositories.
This
is
a
git
repository,
and
one
of
the
really
important
features
of
git
lab
is
the
ability
to
browse
and
view
repositories.
So
you
can
click
around
and
view
all
the
source
code
in
the
gate
lab
application.
A
Aoz
you
to
mere
projects
from
external
source
indicate
lab
in
this
case
we're
marrying
the
git
project
from
the
conical
source
at
git
kernel.org,
which
is
the
conical
source
of
the
git
project,
but
you
can
also
push
mirror
so,
rather
than
pulling
the
source
code
in
a
gate
lab,
you
can
also
push
source
code
from
a
git
repository
out
to
another
location.
These
features
are
all
controlled
from
the
repository
mirroring
settings
page
where
you
can
control
the
authentication
and
which
repositories
you're
mirroring
to
and
from.
A
You
can
fork
repositories,
which
is
a
really
a
wonderful
workflow
for
collaborating.
It
means
that
anyone
contribute
to
a
project
without
having
write
permissions
to
your
project.
As
long
as
they
can
read
your
project
read
the
repository.
They
can
create
a
fork,
make
improvements
and
then
propose
those
back
through
a
merge
request.
So
forking
is
really
one
of
the
key
workflow
features.
A
modern-day
get
workflows,
particularly
with
open
source
high
performance
for
all
compute
networking
and
storing
activities
is
crucial
for
user
satisfaction.
A
I
want
to
talk
about
git
lab
to
get
alee,
which
is
a
service
that
sits
behind
git
repositories
and
get
lab,
and
it
provides
stable,
fast,
reliable
access
to
get
repos.
It's
how
administrators
manage
and
store
git
repos
when
you
fork
a
repository
and
get
lab
wedi
duplicate
the
data
on
the
server.
This
is
really
helpful
for
system
administrators
to
reduce
the
storage
requirements
of
storing
large
projects
than
many
many
Forks.
So
you
don't
have
to
set
all
exactly
the
same
data
a
hundred
times
over.
Only
the
difference
between
that
information
will
be
stored.
A
A
Organizations
often
have
a
need
to
share
their
own
templates
across
teams.
This
feature
allows
an
administrator
to
pick
a
project
to
be
the
instance.
Wide
collection
of
file
templates
inside
the
repository
interface
I
can
go
at
a
new
file
or
directory'.
In
this
case
a
file
I'm
gonna,
add
a
gitlab
CI
mo
file,
choose
the
get
lab
CL
of
CI
mo
file
template
and
then
I'm
gonna
apply
a
specific
template
to
that.
In
this
case,
let's
do
the
auto
dev
ops
and
now
it's
mine
to
customize
and
make
my
own.
A
In
this
case,
I'm
gonna
go
back
to
the
repository.
We
already
have
a
llamo
file
and
I'm
gonna
talk
about
file,
locking
which
helps
you
avoid
merge
conflicts
and
better
manage
your
binary
files.
Now
lock
any
file
or
directory.
You
can
make
your
changes
and
then
you
can
unlock
it.
So
another
member
of
the
team
can
edit
it
in
this
case.
I
am
locking
I've
locked
the
CSS
file,
I'm
editing.
It
and
I
will
make
my
changes
and
I
don't
want
to
have
any
merge
conflict
so
right
now,
I
have
it
locked.
A
A
Push
rules
allow
you
to
configure
ways
of
preventing
certain
kinds
of
data
to
enter
your
apposite
or
e
at
the
time
that
you
push
it
from
your
computer
to
the
server.
So
we
have
a
range
of
different
push
restrictions
that
get
validated
every
time.
You
do
a
push
and
you
can
restrict
who
is
doing
the
push
whether
a
commit
is
assigned
who
the
user
is
committing,
commit
message:
formatting
branch
name
requirements,
prohibited
file
names
commit
size,
file
size.
These
are
all
different
controls
that
help
you
maintain
the
cleanliness
and
hygiene
of
your
repository
to
make.
A
A
Protective
branches
are
one
of
the
really
critical
features.
The
branch
that
you're
doing
most
of
your
work
on
generally
needs
to
have
some
kind
of
control
over
who
has
permission
to
make
changes
to
it
and
whether
they
can
push
directly
to
it
and
make
sure
it's
a
trusted
source
and
you've
got
appropriate
gates
in
front
of
that
branch.
That
might
be
because
you
have
continuous
delivery
practices
where
anything
that
gets
merged
under
that
master
branch
is
queued
up
for
deployment.
A
You
might
also
have
release
branches
that
you
want
to
keep
really
locked
down,
or
you
might
have
historical
branches
of
previous
versions
that
you
want
to
prevent
anyone
modifying
because
they're
really
there
for
archival
purposes,
protect
the
branches.
Allow
you
to
do
this
by
setting
a
wild
card,
and
you
can
select
a
specific
branch
from
the
list
and
then
you
select
which
users
have
different
permissions.
A
A
We
have
the
equivalent
feature
for
tags
as
well
as
branches
tags
are
really
lightweight
with
creating
named
check
points
and
get
history.
So
tagging
a
specific
version
means
it's
easy
for
something
to
check
out
in
version
1.3
and
know
that
it's
the
1.3
version,
whereas
branch
continues
to
evolve.
As
you
add,
more
and
more
commits
to
it,
tags
are
very
useful
and
you
can
protect
them
in
much
the
same
way.
A
Restricting
who
can
create
certain
kinds
of
tags,
see,
release
tags
may
only
be
may
be,
only
maintained
errs,
who
could
create
them
and
also
prevent
people
from
deleting
tags,
merge
requests.
These
are
a
bunch
of
important
preferences
and
controls
around
how
we'd
like
to
use
our
repository.
We've
got
different,
merge
methods
based
on
our
preferences.
We've
got
different
restrictions
about
preventing,
merge
without
pipelines,
passing
naming
around
suggestions
and
event
request
templates,
but
the
approval
rules
are
real
important
aspect
of
merge
requests
for
a
lot
of
people.
A
These
are
the
rules
that
must
be
met
before
the
merge,
but
becomes
enabled
so
not
only
cake
control
who
has
permission
to
press
the
merge
button.
But
these
are
preconditions
for
before
that.
Merge
button
is
available,
who
has
to
review
the
merge
request
and
give
their
approval.
Does
the
security
team
or
a
compliance
team
need
to
conduct
the
review?
A
Do
you
have
a
database
maintenance
or
some
other
kind
of
critical
function
in
your
organization
that
needs
to
give
their
approval
before
you
can
change
your
changes
to
the
application
occur,
merge
request,
approvals
and
code
owners
are
critical
pieces
in
controlling
access
to
your
repository
and
which
changes
can
be
accepted.
Here
we
have
two
new
p-tech,
which
is
a
parent
group
to
the
project
employee
portal
inside
of
employee
portal.
This
is
where
our
repository
is
going
to
reside,
I'm,
going
to
start
a
wiki,
which
is
a
system
for
documentation.
A
That's
built
right
into
each
get
that
project.
Wiki's
are
very
convenient
if
you
don't
want
to
keep
your
documentation
in
your
repository,
but
you
do
want
to
keep
it
in
the
same
project.
For
your
code
resides
you
can
create
wiki
pages
in
the
web
interface
or
locally
using
git,
since
every
wiki
is
a
separate
git
repository
here
we
have
simple
documentation
on
who
the
team
for
this
project
is
the
repos
that
are
tied
to
it
and
the
agile
planning
boards
that
coincide.
A
I'm
gonna
click
on
the
dev
board
go
to
see
what's
in
progress
and
dive
into
there.
I
can
add
an
issue,
but
in
this
particular
case,
I'm
gonna
go
into
an
issue
that
sort
of
being
created
and
being
worked
on
by
myself.
Here
I
can
see
the
activity
within
the
discussion
showing
some
designs
have
been
added,
as
some
discussions
between
me
and
Jordi
we're
gonna
head
over
to
the
design
tab,
which
is
a
great
piece
instead
of
get
lab
that
adds
that
design
management
and
connects
designers
to
engineered
teams.
A
Here's
where
we
can
upload
designs
that
are
being
expected
or
being
hoped
for
in
the
issues
that
are
being
created
or
submitted
to
the
engineering
team.
Here
we
can
see
that
there's
two
versions
showing
of
the
current
log
in
and
the
the
anticipated
or
the
desired
screen
with
the
logo
change
and
with
a
button
color
change,
that's
brand
approved.
We
could
see
some
discussion
is
capable
within
the
design
management.
A
So
if
the
engineer
and
designer
want
to
talk
to
each
other
to
have
more
vacation,
that
could
be
done
here
simply
just
adding
a
comment
on
a
particular
area
and
then
making
that
comment,
and
there
can
be
further
deliberation
between
the
two
and
trying
to
get
to
that
perfect
expectation
of
what's
been
submitted
up
here.
We
can
delete
these
files
and
what
that's
gonna
do
is
not
delete
it
completely,
but
it's
going
to
version
control
those
images.
A
So
if
I
were
to
go
back
to
version,
two
I
can
see
that
there
is
a
different
screen
submitted
that
has
no
logo
on
it,
but
just
the
color
change
the
icon
up
here
is
gonna.
Show
me
that
this
was
added
in
this
version.
So
if
we
were
to
go
to
version
four
we'll
see
that
the
v3
login
screen
was
added
in
version,
four
I
go
to
version
six.
A
There's
been
some
changes
made
in
terms
of
archiving
a
couple,
different
ones,
but
no
new
version
has
been
added
now
if
I
did
want
to
add
a
design
that
had
a
change
and
I
went
to
add
designs
and
I
simply
added
a
login
screen.
It
still
has
the
same
name,
but
now
it's
showing
that
this
here
has
been
modified
in
this
version
it
was
already
saved
as
VT
login
screen
and
now
I
added
a
new
one
that
has
a
yellow
button,
and
it's
going
to
identify
that
with
this
blue
icon
from
here.
A
As
an
engineer,
I'm
gonna
go
and
start
working
on
making
these
changes.
I
can
create
our
merge
request,
which
is
really
where
the
core
development
happens.
Engineers
write
features
and
then
they
push
them
up
to
get
lab
for
code
of
view
and,
ultimately
to
merge
them
to
their
master
development
branch
or
whichever
branch
they
use.
This
is
the
overview
page
where
we
really
get
a
Mission
Control
Center
for
the
changes
made
we
get
to
the
branches
and
we
can
open
in
a
web
IDE,
which
is
a
wonderful
web
IDE
feature.
A
A
We
can
also
see
our
approval
requirements.
You
can
see
that
Dave
as
a
code
owner
for
index.html
and
is
approval,
is
mandatory.
You
also
notice
that
I
can't
click
approve,
because
by
default,
the
author
of
the
merge
request
doesn't
have
permission
to
approve
their
own
change,
which
is
typical
for
most
teams.
Really.
The
bulk
of
the
work
that
happens
in
a
merge
request
is
discussion
and
feedback
in
get
lab.
We
have
the
overview
tab
where
we
got
the
merge,
request,
description
and
a
summary
of
all
the
discussions
by
creating
a
thread
change
if
I
leave.
A
A
I
can
start
a
review
and
a
comment
now,
as
mentioned,
it's
really
hard
to
keep
track
of
all
the
different
discussions,
if
they're
all
in
the
flat
line,
and
it's
very
hard
to
follow
so
we're
applying
to
a
comment
is
a
great
way
to
just
start
a
thread
just
like
you
would
in
slack-
and
this
is
a
general
discussion
on
merge,
requests.
So
I
had
that
comment,
and
now
it's
part
of
this
threaten
a
lot
of
the
time
we
actually
want
to
be
discussing
specific
code
changes
when
it
comes
to
reviewing
changes.
A
One
of
the
things
that's
unique
to
get
lab
is:
we've
got
a
great
file
tree.
You
can
quickly
see
which
files
have
changed
and
you
can
quickly
jump
between
them.
You
don't
have
to
scroll
down
a
giant
list
which
really
improves
the
efficiency
moving
through
changes
made.
You
can
search
as
well,
and
you
may
want
to
leave
a
comment,
and
you
do
that
by
clicking
on
the
line
that
you'd
like
to
start
a
discussion.
I.
A
A
For
this
particular
case,
I
see
that
the
buttons
yellow
and
I
need
that
to
be
orange.
What
I'm
going
to
do
is
go
down
the
snippets
and
then
inside
of
snippets
I'm
gonna
pull
the
already
saved
orange
button,
a
CSS
code
that
was
previously
done.
This
is
approved
I'm,
just
gonna
pull
that
because
we
previously
already
put
this
together
so
no
need
to
do
that
again.
Go
back.
I'm
gonna
apply
this
to
this
suggestion
here.
A
If
we
go
back
we'll
look
at
the
pipeline
that
was
just
kicked
off
with
that
suggestion
that
was
made
here.
I
can
see
that
I've
defined
a
pipeline
in
that
CI
llamó
file,
and
this
is
where
I'm
gonna
see
a
lot
of
my
CI
CD
being
conducted.
It's
gonna
run
through
these
various
stages
and
jobs,
and
then
a
passer
fail
that
new
change
once
that's
completed,
I'll
see
that
this
is
passed
and
given
that
David
has
approved
the
from
security
that
this
merge
request
is
good
to
go.