►
From YouTube: GitLab Basics for Developers
Description
Recorded using GitLab v13.0
Technical Bootcamp Prerequisite 2
A
A
So
in
this
case
we're
going
to
be
going
over
the
advantages
of
using
a
merge
request
based
branching
strategy.
So
what
you
see
is
a
common
workflow
that
all
starts
with
a
branch
we
begin
with
the
main
branch,
and
that
represents
your
production
release
or
official
canonical
code
repository
and
when
starting
a
typical
work
process.
A
Typically,
we
can
start
this
process
by
viewing
the
issue
board
and
selecting
an
issue,
that's
ready
to
start
work
on
meaning
it
has
clearly
defined
requirements
and
expected
outcomes
and
includes
all
necessary
material
like
design
comps
as
a
developer.
This
is
where
my
code
begins.
I
can
start
working
on
this
issue
and,
in
turn,
deliver
the
necessary
code
changes
as
a
merge
request.
Once
the
merge
request
has
been
created,
it
serves
as
a
collaboration
point
around
the
implementation
of
the
changes.
A
A
A
Now,
let's
talk
about
what
a
merge
request
is
specifically
you'll
see
here
at
the
top.
The
description
says:
it
closes
issue
number
16.,
while
it's
not
required
to
have
a
corresponding
issue.
It
helps
to
have
one
for
traceability
in
context.
Just
below
the
description.
We
have
the
git
details.
Now,
a
merge
request
is
always
associated
with
a
specific
git
branch.
Like
the
name
suggests,
it's
a
request
to
merge
one
branch
into
another.
In
this
case
I'm
merging
my
feature,
branch,
which
contains
the
changes
made
to
resolve
this
issue
into
the
master
branch.
A
This
page
also
tracks
my
commit
history,
any
ci
pipelines
that
have
run
against
this
branch,
which
we'll
get
into
later,
as
well
as
code
comments
and
discussions.
Gitlab
has
been
ranked
by
forrester
and
gartner
as
the
best
in
class
source
code
management
tool,
so
you're
not
just
getting
git
you're,
getting
the
best
tools
to
collaborate
wrapped
around.
Yet
on
the
left,
we
see
a
screenshot
of
the
web
ide,
and
this
is
useful
for
making
quick
changes
directly
on
the
branch
without
having
to
pull
down
and
open
up
your
desktop
editor
and
at
the
bottom.
A
A
Now,
let's
look
at
how
merge
requests
actually
bring
people
together
and
enable
collaboration
beyond
the
name
and
references
to
branches
and
issues.
There
are
several
other
useful
pieces
of
information
here
at
the
top.
We
see
the
status
of
the
most
recent
pipeline
that
was
run
for
this
merge
request.
It's
likely.
Each
project
in
gitlab
will
have
a
gitlab
ci
yaml
file,
which
contains
the
configuration
of
how
automation
will
be
run
against
this
project.
A
A
Next
is
the
approval
panel.
It's
very
common
to
have
a
workflow
where
code
changes
must
pass
through
either
an
individual
or
a
group
of
approvers,
say,
for
example,
software,
architects
or
security
reviewers.
So
the
approval
button
acts
as
a
gate
in
that
process
and
it's
possible
to
find
who
is
responsible
for
providing
that
review
and
approval
below
that
is
what's
going
to
drive
the
approval.
This
is
where
the
results
of
different
scans
that
take
place
within
the
gitlab
ci
pipeline
will
be
displayed.
A
So
we
see
here
that
code,
quality
security
scans
and
license
compliance
all
ran
within
this
merge
request
and
have
provided
their
results
below
it's
possible
to
view
each
of
these
reports
to
see
specifically
how
this
change
will
impact
the
broader
code
base.
Is
this
improving
code,
quality
or
degrading
it?
Are
we
introducing
any
new
security
or
compliance
risks?
Reports
aren't
just
limited
to
what
you
see
here.
It's
very
easy
to
add:
container
scanning
dependency,
scanning
unit,
test
results
and
plenty
of
other
data
points
and
reports
to
use
in
the
merge
request.
A
Merge
requests
enable
collaboration
and
visibility.
It's
more
than
just
a
git
repository
with
a
ci
pipeline
attached.
If
you're
working
within
a
large
organization
with
many
developers,
then
code
reviews
and
discussions
are
part
of
everyday
life
and
those
tools
are
built
right
into
the
merge
request
screen
and
that
provides
visibility
for
anyone
involved
in
this
particular
effort
and
because
those
are
all
preserved,
it's
possible
to
go
back
and
review
past
merge
requests
to
get
a
very
clear
and
traceable
picture
of
the
history
of
a
given
project.
A
Here
we
see
the
history
of
a
given
merge
request.
It
includes
the
comments
from
users
individual
commits
to
the
repo
changes
to
the
status
and
approval
state
and
any
code
review,
discussion,
threads
that
have
been
opened
and
when
we're
satisfied
with
the
work,
we
have
the
merge
button
which
allows
us
to
push
those
changes
into
the
selected
branch
and
when
that's
completed,
the
user
performing
the
merge
is
logged,
and
in
this
case
the
issue
referenced
by
the
merge
request
was
closed.