►
From YouTube: Create:Source Code Walk Through - Jan 2020
Description
This is a walk through of the Source Code Management and Code Review categories of GitLab.
A
So
the
most
basic
and
key
feature
is
the
fact
that
good
Labs
supports,
store
and
get
repositories,
and
this
is
a
git
repository.
I've
got
here.
The
git
project
itself
and
one
of
the
the
really
important
features
of
git
lab
is
the
ability
to
browse
and
view
repositories
so,
and
you
can
click
around
view,
all
the
source
code
in
the
get
lab
application
for
a
git
repository.
A
You
can
view
the
tags
and
the
branches,
so
these
are
really
the
basic
fundamentals
of
browsing
or
repository,
but
gilliam
supports
a
lot
of
really
useful.
Other
features
that
make
storing
your
git
repositories
on
github,
really
great
and
the
first
one
I
wanted
to
highlight
is
mirroring
so
git
lab
allows
you
to
mirror
projects
from
an
external
source
in
ticket
lab,
and
so,
in
this
case,
we're
mirroring
the
git
project
from
the
canonical
source
at
gift
kernel.org,
which
is
the
the
canonical
source
of
the
git
of
project.
A
But
you
can
also
push
mirror
so,
rather
than
pulling
the
source
code
in
to
get
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
or
from
so
that's
the
the
first
feature
I
wanted
to
highlight
in
this
walkthrough.
The
next
feature
is
to
do
with
forking,
so
jumping
over
here
to
a
copy
of
this
same
repository,
you
can
fork
repositories
and
get
lab.
A
This
is
really
a
wonderful
workflow
for
collaborating.
It
means
that
anyone
can
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
backs.
Real
note
requests,
so
forking
is
really
one
of
the
the
key
workflow
features
of
modern-day
get
workflows,
teacherly,
open
source
and
I.
Guess
I
wanted
to
also
call
out
the
fact
that
there
is
the
get
early
category
of
get
lab
which
isn't
a
marketed
category.
A
But
giddily
is
the
service
that
sits
behind,
get
repositories
and
get
lab.
It
provides
stable,
fast,
reliable
access
to
get
repos
it's
how
administrators
manage
and
store
to
get
repositories,
and
we
do
a
lot
of
clever
features.
So
when
you
fork
a
repository
in
get
lab,
we
D
duplicate
the
data
on
the
server.
So
this
is
really
helpful
for
systems
administrators
to
reduce
the
storage
requirements
of
storing
large
projects
with
many
many
Forks.
So
you
don't
have
to
set
all
exactly
the
same
data
a
hundred
times
over.
A
A
One
of
the
really
important
features
of
you
of
any
kind
of
tool
that
you
store
get
repositories
in
is
really
the
access
controls
that
they
provide.
So
I
wanted
to
walk
you
through
these
core
features,
and
the
first
is
push
rules,
push
rules
prevent
they
allow
you
to
configure
ways
of
preventing
certain
kinds
of
data
to
enter
your
repository
at
the
time
that
you
push
it
from
your
computer
to
the
server,
and
so
we
have
a
range
of
different
push
restrictions
they
get
validated.
Every
time
you
do
a
push
you
can
restrict.
A
Who
is
doing
the
push
whether
commit
sucide?
Who
the
user
is
commute
message?
Formatting
branch
name
requirements,
prohibited
file
names
commit
site
file-size.
These
are
all
different
controls
that
help
you
maintain
the
cleanliness
and
hygiene
of
your
repository
to
make
whatever
standards
you
want
so
very
useful,
very
flexible
used
by
many
of
our
customers.
A
The
next
I
guess,
access
control
feature
I
wanted
to
highlight
is
protected
branches.
So
this
is
one
of
the
the
I
guess,
the
other
really
critical
features
master
or
developer.
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
basically
making
sure
it's
a
trusted
source
and
you've
got
appropriate
gates
in
front
of
that
branch.
A
That
might
be
because
you
have
continuous
delivery
practices
where
anything
that
gets
merged
onto
that
master
branch
is
queued
up
for
deployment.
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
from
modifying,
because
they're
really
there
for
archival
purposes,
protected
branches.
A
A
Folder
kai
is
going
to
get
notified
and
of
that
change
and
depending
on
my
settings,
his
approval
might
be
optional
or
required,
and
this
is
leading
into
approval
rules,
which
is
a
more
general
form
of
code
owners,
and
so,
if
we
come
down
to
the
repository
settings,
this
is
where
we'll
find
a
lot
of
these
really
useful
settings.
So
merge
requests,
and
these
are
a
bunch
of
important
preferences
and
controls
around
how
we
like
to
use
our
repository.
We've
got
different,
merge
methods
based
on
our
preferences.
A
A
A
Does
a
security
team
or
a
compliance
team
need
to
conduct
the
review?
Do
you
have
database
maintenance
or
some
other
kind
of
critical
function
in
your
organization
that
needs
to
give
their
approval
before
you?
Changes
to
the
application
occur,
Mergent
requests,
approvals
and
code
owners
are
critical
pieces
in
controlling
access
to
your
repository
and
which
changes
can
be
accepted.
A
So
you'll
notice
the
little
thing
that
code
owners
are
control
from
prep
to
protect,
protect
Brandon's
interface
and
these
approval
rules
which
apply
to
all
merge
requests,
irrespective
of
the
files
that
are
changed,
are
configured
from
this
screen
here.
So
we
can
specify
that
we
just
need
anyone
to
approve.
Currently
it's
completely
optional,
but
we
could
specify
we
need
exactly
one
or
exactly
two
approvals
before
we
can
have
our
met
requests
match
Oh.
A
Alternatively,
we
can
be
more
specific,
so
a
good
example
would
be
a
security
rule.
We
need
one
approval
from
the
security
team
and
let
me
just
see
if
I
can
find
Kristin.
Yep
I'll
add
her
she's,
not
actually
on
the
security
team,
but
it's
a
good
example,
and
so
we
had
multiple
people
to
our
approval
rule
we
can
add
groups
and
so
anytime,
there's
a
merge
request.
A
There
are
none
locked
yet,
but
let's
go
and
lock
a
file
and
take
a
look,
so
I
think:
let's
go
to
documentation
and
coding
guidelines,
so
we
can
lock
this
file
and
this
means
no
one
else
is
going
to
be
able
to
change
it.
We
can
also
see
that,
as
I
mentioned
before
KY
as
a
code
owner
of
the
documentation
folder,
and
so
this
is
a
helpful
little
tooltip
showing
us
that
that's
the
case.
A
If
we
go
back
to
Fox
files,
we
can
see
a
list
of
that
and
I'll
unlock
that
now,
because
that's
unnecessary
great.
So
that's
really
a
quick
introduction
into
repositories
and
particularly
the
source
code
management
side
of
things.
The
access
controls,
the
permissions
that
we
support,
there's
quite
a
lot
of
different
options
to
meet
the
various
needs
of
different
customers.
A
So
let's
take
a
look
at
code
review
which
is
really
where
the
meat
and
potatoes
of
development
happens,
Engineers,
write
features
and
then
they
push
them
up
to
get
lab
the
code
review
and
ultimately
to
merge
them
into
their
master
or
development
branch
or
whichever
branch
they
use.
So
here's
a
merge
request
that
I've
opened
on
the
git
repository
I
didn't
write
this
code,
one
of
our
engineers
Kristen
and
I've,
copied
it
from
the
mailing
list.
For
this
example.
A
So
this
is
the
overview
page
where
we
get
really
a
Mission
Control
Center
for
the
change.
We
can
see
the
branches
we
can
open
in
the
web
IDE
and
if
you
haven't,
checked
out
Kies
video
about
the
internet
group
and
the
wonderful
web
ID
a
feature.
That's
part
of
that
I'd
strongly
encourage
you
to
do
that,
and
we
can
also
see
our
approval
requirements
because
I've
already
created
this.
A
A
If
I
leave
this
comment,
one
of
the
really
great
features
of
git
lab
is
that
you
can
start
a
thread
on
any
any
comment,
and
this
helps
because
a
lot
of
the
time-
and
there
are
multiple
things
being
discussed
simultaneously
on
imagery
and
it's
really
hard
to
keep
track
of
all
the
different
discussions,
if
they're
all
in
a
flat
line.
It's
very
very
hard
to
follow
so
replying
to
comment
is
a
great
way
to
start
a
thread
just
like
you
would,
in
slack.
A
Alright,
so
this
is
what
a
thread
looks
like
people
can
keep
replying,
and
one
of
the
interesting
items
to
highlight
is
you
can
resolve
threads
so
until
a
threaded
or
a
discussion
thread
is
resolved,
the
merge
will
be
blocked.
So
if
we
refresh
the
page,
we
should
notice
that
oh
maybe
I
need
to
check
my
major
quest
settings,
but.
A
This
is
an
unresolved
thread
and
then
we
can
resolve
it
when
we're
done
and
we
can
see
who
resolved
this
discussion
and
we've
got
a
nice,
the
Lord
of
trail
here.
So
that's
general
discussion
on
merge
requests,
but
most
of
the
time
we
want
to
actually
be
discussing
specific
code
changes,
and
here
I
want
to
highlight
some
really
great
features
of
git
lab
when
it
comes
to
reviewing
changes.
One
of
the
things
that's
kind
of
unique
to
get
lab
is:
we've
got
a
great
file
tree.
A
A
A
Documentation
and
what
I
might
do
is
like
leave
a
sort
of
like
half-baked
suggestion
or
something
like
that.
But
then
the
author
of
The
Merchant
request
has
to
go
away
copy.
Our
little
suggestion
add
it
to
a
new
commit
and
then
push
that
new
commit,
and
it's
a
little
bit
time-consuming.
So
one
of
the
great
features
we've
got
is
inserting
a
suggestion
which
quickly
takes
the
line.
A
And
you'll
notice
I've
got
two
options
now.
I
can
start
a
review
or
add
the
comment
now
and
and
starting
a
review
is
really
handy
because
I
find
when
I'm
reviewing
mode
requests.
I'll
often
have
questions,
but
as
I
read
further
through
the
merge
request,
my
questions
will
be
answered
or
I
want
to
refine
them
and
clarify
them
in
the
context
of
things
that
I've
learned
as
I've
been
reviewing
other
changes
and
so
as
I
scroll
down
I
might
realize.
Oh
I
want
to
go
back
to
this
comment
up
here
and
edit.
A
It
make
an
adjustment
and
then
save
that,
but
when
I'm
done,
I
can
click
finish'
review
and
then
I
click
Submit
review
to
confirm-
and
here
we
can
see
what
the
suggestion
looks
like
you-
can
see
that
I've
taken
this
whole
block
of
documentation
from
line
31
through
the
bottom
of
35
and
I've
proposed
to
convert
into
this
one
line
and
now
because
we
used
a
suggestion,
we
didn't
just
write
it
in
the
comment
in
a
freestyle
text.
We've
got
this
special
apply.
A
A
We're
building
up
an
audit
trail
of
every
single
discussion
and
we
can
see
that
I've
changed
this
line
and
a
new
commit
was
added,
and
so
this
is
a
really
great
way
when
you've
got
lots
of
people
collaborating
giving
feedback
to
be
much
more
efficient
about
proposing
things
that
are
actionable
and
as
the
mode
requests
also
quickly
applying
suggestions,
rather
than
having
to
check
to
change
out
locally
and
apply
it
manually.
So
a
really
good
time,
saver
and
so
I
think
that's
a
nice
summary
of
the
changes,
tab
and
I
think
yeah.