►
From YouTube: Git Basics - GitLab Webinar
Description
Are you new to Git? Watch this webinar targeted at beginners working with source code, where we will review the basics of using Git for version control and how it works with GitLab to help you get started quickly
A
All
right:
let's
kick
it
off
thanks
everyone
for
joining
us
today
on
our
get
Basics
webinar
we're
excited
to
have
you.
My
name
is
Taylor
Lund
I'm,
a
member
of
the
customer
success
team
here
at
gitlab
and
I'm
joined
by
my
colleague,
Chris
catarte,
who
is
a
customer
success
engineer
we're
excited
to
be
with
you
today,
just
a
couple
of
housekeeping
items
before
I
pass
it
over
to
Chris.
A
First
off
this
webinar
is
being
recorded,
so
you
can
look
for
that,
recording
as
well
as
the
deck
to
come
through
to
your
inbox
here
in
the
next
day
or
two.
If
you
have
any
questions
that
come
up
throughout
the
presentation
feel
free
to
put
those
in
the
Q
a
portion
of
zoom,
and
we
will
be
happy
to
answer
some
of
those
throughout
and
Chris
will
have
some
time
to
answer
a
few
at
the
end
as
well
and
without
further
Ado
I
will
pass
it
over
to
Chris.
B
Perfect
thanks
a
lot
Taylor
for
that
intro.
So
again,
my
name
is
Chris
guitarte
I'm,
a
customer
success
engineer
here
at
gitlab
and
in
today's
webinar
I'll,
be
focusing
on
foundational
or
beginner
Concepts
and
usage
for
git.
So,
for
example,
you
might
be
a
developer
coming
from
another
source,
Control
Management
Tool
other
than
git,
so
this
webinar
will
really
help
you
understand
how
git
works
and
how
to
utilize
git
with
gitlab.
B
This
is
set
some
expectations.
Detailed
migration
assistance
from
another
source,
Control
Management
tool,
is
out
of
scope.
For
today's
conversation,
I'd
recommend
that
you
contact
our
sales
team
to
inquire
about
our
full
service
migration
Consulting
package.
In
case
you
need
some
hand
holding
or
assistance
directly
from
a
Professional
Services
team
I'll
provide
you
a
link
at
the
end
of
this
conversation
for
a
description
and
contact
form
for
that
package.
But
if
you
prefer
to
migrate
repositories,
yourself,
I'll
also
have
some
resources
available
to
allow
you
to
self-service
your
migration
so
without
further
Ado.
B
Finally,
next
up
we'll
also
have
a
section
where
I'll
be
able
to
show
you
more
interactively
how
get
Works
they'll
get
in
action
at
a
clone
repository
from
a
gitlab
project
repository
work
with
it
locally
create
some
changes.
Push
those
changes
into
commit
those
changes
to
a
feature,
Branch
push
that
feature
Branch
to
the
remote
repository
and
then
actually
working
within
gitlab
in
a
merge
request
to
collaborate,
do
some
code
review
and
then
finally
merging
those
changes
into
the
main
or
default
branch.
B
Lastly,
we'll
share
some
good
resources
around
migration
to
get
as
well
as
some
additional
introductory
to
get
resources
to
help.
You
learn
get
at
your
own
pace
as
Taylor
mentioned.
If
you
have
any
questions,
please
use
the
Q
a
feature
Zoom
to
submit
your
questions
to
the
team
as
I
present.
Today's
webinar
alongside
me
are
some
members
of
the
gitlab
customer
success
team,
but
we'll
be
able
to
help
guide
you.
If
there's
anything
that
comes
to
mind
anything
that
you
become
inspired
to
ask
with.
B
Based
on
what
I'm
presenting
you,
don't
have
to
wait
till
the
very
end
to
ask
any
questions
we'll
get
to
them
as
soon
as
we
can
so
in
terms
of
context.
Here
you
know
before
we
dive
into
git
and
using
gitlab
versus
horse
Control
Management.
Let's
take
a
step
back,
you
know,
gitlab,
as
a
solution
is
a
platform
approach
that
brings
together
the
entire
software
development
life
cycle
into
a
single
application.
B
A
platform
approach
enables
a
value
stream
driven
mindset,
a
mindset
that
shortens
the
time
from
idea
to
customer
value
and
establishes
a
powerful
flywheel
for
data
collection
and
aggregation.
The
benefit
of
a
value
stream
platform
approach
is
the
visibility
across
personas
and
projects.
So
you
can
measure
Improvement
and
cycle
times
and
a
platform
approach
in
unifies
the
entire
experience,
so
that
organizations
and
companies
like
yourself
can
be
faster
than
your
competition.
Moving
from
an
idea
to
the
customer's
value.
B
B
We
give
those
teams
better
insights,
greater
efficiency,
improved
collaboration
and
faster
time
of
value
by
uniquely
creating
this
offering
as
a
single
application,
we're
best
able
to
provide
our
customers
with
end-to-end
visibility
across
the
software
delivery.
Life
cycle
in
a
single
application
gitlab
provides
all
the
functionality
of
a
complete
devotech
Ops
platform.
We
allow
organizations
to
deliver
software
faster,
while
strengthening
security
and
compliance,
thereby
maximizing
the
return
on
software
development.
B
To
make
it
a
little
bit
more
concrete
and
tangible,
let's
look
at
let's
take
a
look
at
a
typical
workflow
from
planning
and
creating
software
to
integrating
and
verifying
software,
to
deploying
an
operating
software
and
to
moderating
monitoring
and
improving
software.
Each
of
these
steps
brings
in
different
stakeholders
and
teams
in
your
company.
Everyone
plays
a
role
even
when
secop
shifts
left.
This
workflow
also
uniquely
helps
developers
as
security
shifts
left
with
the
solution.
We
help
customers
proactively,
identify
vulnerabilities
by
integrating
and
automating
vulnerability
management
within
the
development
life
cycle,
issues
can
be
identified.
B
Log
triage,
cracked
and
remediated
all
in
the
same
application
in
gitlab
developers
can
address
vulnerabilities
in
real
time,
avoiding
release,
delays
and,
what's
most
powerful,
is
that
our
solution
uniquely
allows
data
to
be
collected
from
requirement
to
production.
You
can
leverage
this
data
to
provide
incremental
checks
along
the
way
to
ensure
only
the
best
code
is
merged
and
delivered
to
your
customers.
B
You
know
one
of
our
customers
was
able
to
use
our
value
stream
dashboards
to
identify,
identify
their
best
performing
Java
engineers
and
deploy
them
to
the
most
critical
projects.
Another
customer
was
able
to
measure
the
cost
of
creating
a
new
capability
demonstrating
to
the
company
exactly
what
their
team
is
capable
of.
As
a
manager
or
executive
you'll
get
access
to
actionable
insights
from
an
application
team
project
line
of
business
and
Company
level.
You
will
use
this
data
to
help
teams
become
more.
B
Try
better
experiences
and
ensure
security
and
compliance
needs
are
being
met,
so
we
have
the
most
comprehensive
desk
hookups
platform
and
we're
just
getting
started.
We're
constantly
innovating
new
capabilities
in
our
platform,
as
you
can
see
here,
typically,
a
customer
will
start
using
gitlab
to
solve
their
source
code
management
and
CI
CD
challenges.
So
over
time
a
customer
may
expand
their
usage
to
get
efficiency
and
value
benefit.
It
costs
more.
B
The
git
lab
offers
all
the
phases
of
a
devops
lifecycle,
but
we're
going
to
start
where
you
are
many
customers
choose
to
adopt
gitlab
in
a
gradual
process,
starting
with
a
use
case
where
they
feel
the
greatest
pain.
Typically,
they
start
with
either
Sports
control
management
or
continuous
integration.
B
Sometimes
they
might
start
with
agile
apologetic
management,
but
most
often
it's
sem
or
CI,
then
over
time
our
customers
will
adopt
more
capabilities
in
gitlab,
including
security
and
continuous
delivery,
and
the
common
theme
that
we
hear
from
customers
is
that
they
adopt
as
they
adopt
more
breadth
of
git
lab
capabilities.
They
uncover
greater
and
greater
value.
So
with
that
said,
let's
Dive
Right
into
managing
source
code
using
git
on
gitlab.
B
A
B
B
B
B
Contributors
shows
a
list
of
users
who
have
contributed
commits
to
the
Repository
graph
is
a
visual
representation
of
your
branches
and
the
changes
made
and
merge
between
them.
Finally,
compare
allows
you
to
compare
changes
between
branches
tags
or
specific
commits
using
the
hash
of
a
commit
itself.
B
Next
I
want
to
go
into
detail
around
the
merge
requests.
This
is
the
equivalent
of
a
pull
request
in
other
tools
to
obtain
feedback
from
other
team
members.
You
should
create
a
merge
request
in
gitlab
from
there
you
can
assign
or
mention
the
person
that
you'd
like
to
have
review
the
code
and
then
you'd
push
corrections
to
that
same
feature.
B
B
You
can
collaborate
via
the
threaded
messages
or
comments
here
to
ensure
you
have
context
on
the
conversation
that's
happening
and,
finally,
you
can
see
what
the
proposed
changes
are
by
looking
at
the
commits
from
the
feature
branch
and
what
changes
have
been
made
using
the
diff
interface
on
the
changes.
Tab.
B
The
Upstream
repo
is
also
known
as
remote.
This
is
the
hosted
repository
on
a
shared
server,
or
instance
in
this
case,
and
when
you're
using
gitlab
or
is,
is
that
remote
Repository,
untrack
files
are
new
files.
That
git
has
not
been
told
subtract
previously
commit
commits,
can
be
thought
of
as
snapshots
or
Milestones
along
the
timeline
of
a
get
project
and
commits
are
equated
to
capture
the
state
of
a
project
at
that.
B
Working
area
are
files
that
have
been
modified,
but
not
committed.
A
staging
area
is
a
modified
or
added
files
that
are
marked
to
go
into
the
next
commit
a
branch
is
an
independent
line
of
development,
typically
scoped
to
a
feature
or
a
bug
fix
I
also
call
them
this
feature
branches.
If
it's,
you
know,
work
targeted
at
integrating
a
new
feature
for
next
iteration
of
the
code
base.
B
Some
of
the
git
internal
terminology,
just
to
give
you
some
context
here,
you've
got
object,
types
of
commit
tree
and
blog
a
commit
contains
the
author
a
commit
message,
which
is
a
short
description
of
what's
contained
in
that
commit
and
a
pointer
to
a
tree
of
changes
a
tree.
On
the
other
hand,
a
tree
object
is
used
to
represent
directories
or
folders
of
files
and
other
subdirectories.
B
B
The
current
commit
and
works
up
to
the
parent
chain
touching
tree
and
blob
content
to
get
checkout
is
an
easy
way
to
load
any
snapshots
into
your
develop
machine
and
git
clone
is
used
to
create
a
copy
or
clone
a
remote
repositories
with
Git
clone.
You
pass
the
repository
URL
and,
in
this
case
the
gitlab
project
repository
URL.
B
All
the
work
that
you
do
locally
is
not
seen
on
gitlab
until
you
push
to
the
gitlab
remote
repository.
This
allows
you
to
work
offline
without
network
access
and
to
push
your
changes
for
review
whenever
you're
ready,
I've
seen
in
the
previous
slides
gitlab,
is
your
primary
collaboration
tool
for
code
review
and
merging
changes
from
a
feature
Branch
to
the
main
or
default
branch
here?
I
want
to
take
you
through
a
basic
git
workflow.
Developing
a
project
revolves
around
the
basic
edit
stage
and
commit
pattern
to
start
working.
A
B
Next
I
want
to
walk
through
some
get
branching
strategies
with
you
with
gitlab.
You
can
use
any
branching
strategy.
You'd
like
I,
want
to
go
over
some
common
ones
and
share
the
pros
and
cons
of
each
organizations
coming
from
git
coming
to
get
from
other
Version
Control
Systems,
frequently
find
it
hard
to
develop
productive
workflow
get
flow
is
one
branching
strategy.
This
strategy
suggests
a
main
branch
and
a
separate,
develop
Branch
with
supporting
branches
for
features,
releases
and
hot
fixes.
B
B
B
Gitlabflow
incorporates
a
pre-production
branch
to
make
bug
fixes
before
merging
changes
back
to
Maine
before
going
to
production
teams
can
add
as
many
pre-production
branches
as
needed,
for
example,
from
Main
to
test
from
test
to
acceptance
and
from
acceptance.
Production
GitHub
flow
is
where
you
might
have
a
long
running.
Dev
branch
that
merge
to
main
when
you
do
a
release
in
gitlabflow.
You've
got
short-lived
feature
branches
with
main
base
development
and
everything
is
coming
off
of
the
main
branch.
A
B
Being
able
to
leverage
environment,
branches
and
kitlab
flow
lets,
you
incorporate
differently
named
environment
branches
that
are
automatically
updated
to
the
main
branch.
For
example,
let's
say
that
you
have
a
staging
environment,
a
pre-production
environment
and
a
production
environment
with
this
flow,
essentially
teams
practice
feature
branching,
while
also
maintaining
a
separate
production.
Branch
Guild
outflow
decreases
the
overhead
of
releasing
tagging
and
merging,
which
is
a
common
challenge
encountered
with
other
types
of
git
workflows,
so
this
recommended
flow.
You
could
first
deploy
the
main
branch
to
staging
then
to
deploy
to
pre-production.
B
B
If
you
need
a
cherry
pick
a
commit
with
a
hotfix,
it's
common
to
develop
it
on
a
feature,
branch
and
merge
it
into
the
main
branch,
with
a
merge
request
in
this
case
do
not
delete
the
picture
Branch.
Yet
the
main
Branch
passes
automatic
testing.
You
then
merge
the
future
Branch
into
the
other
branches.
Now
this
is
not
possible.
Before
manual
testing
is
required.
You
can
send
merge,
requests
from
the
future
Branch
to
the
downstream
branches.
B
B
You
create
stable
branches
using
the
main
branch
as
a
starting
point
and
Branch
as
late
as
possible.
By
doing
this,
you
minimize
the
length
of
time
during
which
you
have
to
apply
bug
fixes
to
multiple
branches.
After
announcing
a
release,
Branch
only
add
serious
bug
fixes
to
the
branch
if
possible.
First,
you
should
merge
these
bug,
fixes
into
the
main
branch
and
then
Cherry,
Picks
Them
cherry
pick
them
into
the
release
branch.
A
B
Setting
a
new
tag,
some
projects
also
have
a
stable
branch
that
points
to
the
same,
commit
as
the
latest
release
branch
in
this
flow.
It
is
common
not
to
have
it's
not
common,
to
have
a
production
branch
all
right.
So
let's
get
the
terminology
out
of
the
way
and
actually,
let's
see
the
issues
in
practice
with
a
bit
of
interactive
command
line
time
working
with
Git
at
the
command
line.
B
B
On
your
operating
system,
you'll
have
different
instructions
to
get
git
CLI
setup
next,
in
order
to
communicate
with
the
remote
gitlab
server.
You'll
need
to
create
an
SSH
key,
which
is
an
access
credential.
That's
used
in
SSH
protocol
you'll
generate
the
key
locally
and
then
save
it
in
your
dot.
Ssh
folder
on
your
local
machine,
where
you're
doing
the
development
so
authenticate
and
communicate
with
the
gitlab
instance
from
your
local
machines.
Get
CLI
you'll
need
to
add
the
SSH
key
generated
to
your
gitlab
account
to
the
web
interface
and
just
like
the
previous
slide.
B
I
won't
go
into
too
much
detail
here,
but
you
can
navigate
to
the
link
reference
here
at
the
top
for
more
directed
guidance
and
as
a
security
best
practice
I
recommend
generating
a
new
SSH
key
for
each
device
that
needs
to
communicate
with
gitlab
using
the
git
CLI.
For
example,
your
desktop
and
laptop
machines
should
use
a
separate
SSH
key
that
is,
each
uploaded
circuit
lab
account
in
the
web
interface.
B
When
you
first
install
git
you'll
need
to
configure
your
user
ID
information
to
identify
who's,
making
the
commits
from
git
CLI.
You
can
check
the
settings
here,
but
it
can
get
config
list
command.
So
you
can
see
that
here
from
my
local
machine
I've.
Given
you
an
example
of
what
my
local
configuration
looks
like
my
username
is
Chris
guitarte
I've
got
my
email
address,
listed
there
as
well.
B
Next,
in
the
git
workspace,
you
will
choose
a
directory
on
your
machine
that
is
easy
to
access
I
recommend
you
create
a
new
directory
called
workspace
or
development.
This
is
where
you'll
work
from
to
add
or
change
to
repository
content.
First
I'll
clone
a
repository
project
repository
in
that
directory
that
we'll
be
working
with
today.
Here's
an
example
of
me
creating
that
directory
navigating
to
that
directory
and
doing
the
git
clone
command
using
the
git
URL
to
clone
that
into
my
local
workspace.
B
When
you're
working
locally,
it
may
not
always
be
in
sync,
with
the
latest
changes
on
the
remote
repository.
If
you've
cloned
for
a
remote
gitlab
project,
Repository
I
recommend
you
use
these
commands
to
update
your
local
repository
after
cloning
and
to
get
the
status
of
local
changes
that
you've
made.
Here.
You
can
see
that
some
remote
changes
on
the
readme.md
file
have
been
updated,
removing
some
lines
and
using
the
git
git
pull
command,
I've,
updated
and
merged.
Those
changes
to
remove
some
lines
on
my
local
Repository
using
git
status.
B
So
now
that
we've
pushed
our
feature
Branch
to
the
remote
repository,
we
can
work
on
getting
feedback
and
validation
by
creating
a
merger
Quest
and
the
merge
request.
You
can
check
out
the
changes
made
and
mention
different
books
to
provide
feedback
on
your
changes.
You
can
make
changes
again
in
your
local
repository
push
them
to
the
remote
server
and
you'll
notice
that
the
merge
request
will
update
when
you're
ready
an
emergency
code
to
the
main
branch.
You
can
click
merge.
A
B
B
Right,
it's
been
pushed
up
and
now
we'll
go
back
to
the
merger
Quest
and
see
that
those
additional
changes
have
been
made.
We've
added
I've
got
some
feedback
from
another
team
member
saying
we
need
more
emphasis,
adding
more
exclamation
points,
so
here
in
the
diff
inline
and
activity
feed
we
can
see
those
changes
have
already
been
reflected
on
the
remote
Repository.
B
B
B
So
here's
a
couple
of
resources
that
I
would
recommend
the
first
being
a
game
that
you
can
play
in
a
web
browser
to
learn,
git
commands
and
branching
in
a
visual
and
interactive
way.
It's
really
fun
I,
definitely
recommend
it.
The
second
is
a
git
command,
cheat
sheet
that
you
can
download
and
reference
and
it's
created
by
gitlab.
B
Next,
we've
got
some
helpful
migration
links
if
you
have
a
long
history
working
with
another
sem
tool-
and
you
want
to
bring
all
that
history
over
to
git
on
gitlab.
These
resources
are
available
to
you
so
that
you
can
either
self-service
your
migration
or,
if
accelerating
your
time
and
value,
is
important,
you
can
have
a
Professional
Services
team.
Take
the
lead
on
migrating
for
you
with
our
migration
package
again
we'll
provide
the
deck
after
the
webinar
is
completed,
so
you
have
access
to
all
these
links.
B
I
also
want
to
leave
you
with
some
advice.
If
you're
coming
from
CVS,
SVN
or
TFS,
so
unlike
centralized,
Version
Control
Systems
would
get,
each
developer
has
their
own
copy
of
the
Repository.
This
means
you
can
commit
as
often
as
you
want,
without
affecting
others.
Even
if
your
changes
are
incomplete,
breaks
an
API
or
causes
the
bill
to
fail,
you
can
commit.
B
This
allows
you
to
structure
your
commits
as
logical
units
of
work,
as
opposed
to
one
monolithic
commit
that
represents
the
entire
new
feature
and
get
all
operations
for
Atomic.
Either
this
they
succeed
as
a
whole
or
they
fail
without
any
changes
and
CVS,
for
example,
commits
and
other
operations
are
not
atomic.
If
an
operation
on
the
repository
is
interrupted
in
the
middle,
the
repository
can
be
left
in
an
inconsistent
state.
If
you
get
into
trouble,
lose
commits
or
find
that
you've
broken
everything
turn
to
your
ref
log.
B
And
in
most
centralized
Version
Control
Systems
updating
your
local
Source
feed
to
match.
The
repository
cannot
be
taken
lightly.
If
you
made
significant
changes,
updating
from
head
can
cause
a
huge
headache.
This
is
because
you're
essentially
fetching
the
new
revision
and
merging
it
with
your
Source
tree
and
get
the
concept
of
fetching
and
merging
can
actually
be
applied
separately
with
fetch.
You
only
retrieve
the
metadata
of
changes
when
you
also
want
to
download
the
actual
changes
you
do.
A
pull
a
pull
operation
always
includes
a
fetch
operation.
B
B
B
Separate
branches
makes
it
very
easy
to
move
effortlessly
between
tasks
all
right.
Well,
I
want
to
thank
everybody
for
joining
my
webinar
today,
I'll
pass
things
back
to
our
host
Taylor
for
some
housekeeping
items
and
with
time
permitting
on
maybe
I'm
able
to
access
or
address
some
of
the
questions
live
on
the
call.
A
Thank
you,
Chris
yeah
I'm,
just
going
to
open
up
a
quick
feedback
poll
looking
forward
to
receiving
some
feedback
from
you
all
just
a
couple
of
of
quick
questions
on
that
and
with
that
yeah
I
I
will
go
over
a
few
questions
here
and
ask
those
to
you
Chris,
the
first
one
here.
What
do
you
think
is
the
best
branching
strategy.
B
Yeah
great
question,
so
it
all
really
depends
on
your
team's
expertise
and
release
deployment
strategy.
Yeah
I
presented
three
options
earlier
with
the
get
flow,
GitHub
flow
and
gitlab
flow.
Well
with
gitlab.
We
don't
necessarily
force
you
to
use
one
or
the
other.
It's
entirely
up
to
you
and
your
team.
B
Yeah
great
question
so
I
know
we
focus
a
lot
of
using
git
on
the
git
CLI
on
your
local
machine,
committing
those
changes
locally
and
pushing
them
up
to
the
remote
repository
which
is
gitlab.
But
if
you
wanted
to
you
actually
can
utilize
the
built-in
web
IDE
now
based
on
vs
code
to
create
new
feature
branches
and
start
a
merge
request.
All
from
your
web
browser
for
really
quick
changes,
I'm
going
to
switch
over
to
the
other
tab
here
in
my
web
browser-
and
you
can
see
here-
there's
a
web
ID
button.
B
B
B
Reviewing
all
emphasis,
commit
and
push
that
new
change
and
I
want
to
create
a
new
branch,
we'll
go
ahead
and
click
yes
here
and
suggests
a
new
Branch
name
main
patch,
and
the
hash
of
that
commit
can't
leave
that
empty
to
use
the
keyfold
hit
enter
now
we'll
go
ahead
and
create
that
branch
for
you
and
you
can
create
an
MR
or
merge
request
directly
from
that
web
IDE
interface
and
click
that
see
the
new
merge
request.
Removing
all
emphasis,
gonna
assign
yourself
assign
a.
B
B
Another
great
question:
so
there
actually
isn't
a
specific
time
frame
that
I
would
recommend,
but
as
a
best
practice,
I
would
recommend
using
short-lived
feature
branches
as
much
as
possible.
I'm
going
to
use
a
short
little
feature
Branch.
It
allows
you
to
make
smaller
iterations
to
your
code
base
and
really
makes
it
a
lot
easier
for
your
team
to
review
your
code.
So
the
example
that
I
showed
here
if
the
change
was
really
just
to
you
know,
remove
the
emphasis
on
that
salutation
in
the
readme
file.
B
B
I
can
see
that
pretty
clearly
that
only
the
readme
file
has
been
changed,
but
if
this
becomes
a
little
bit
more
monolithic
of
a
feature,
Branch
a
lot
more
long-lived
you'll
start
to
see
a
lot
more
changes
here
on
this
changes
time,
and
it
becomes
a
little
bit
more
difficult
to
review
and
actually
make
that
quick.
Iteration
to
the
readme
file,
so
definitely
recommend
short-lived
feature
branches
as
much
as
possible,
and
it
just
makes
makes
it
a
lot
easier
to
review
the
code.