►
From YouTube: Digital Experience Team: Git 101 Class 4
Description
The digital experience team goes over Git commands and where they live on the Git cycle
A
Hello
everyone,
so
this
is,
I
think,
the
fourth
session
of
get
learnings
get
101.,
I'm
not
sure
what
we're
calling
these
lessons.
I
know
that
we've
met
with
michael
and
I
think,
lauren
to
make
merge,
requests
and
kind
of
get
a
handle
on
what's
happening
in
the
get
cycle.
So
this
time
we're
meeting
we've
already
successfully
made
a
merge
request
with
lauren
and
so
the
goal
of
this
101
lesson
104.
I
don't
know
how
lessons
work
is
to
go
over
the
git
cycle.
A
I
know
that
just
I
should
be
on
the
design
team,
but
it
is
really
just
a
basic
kind
of
cycle
and
I've
written
the
git
commands
on
the
side
here
that
we've
seen
throughout
our
studies
and
I
just
kind
of
want
to
go
through
where
they
live.
On
this
cycle,
I
also
included
system
commands
that
you've
worked
with
before
ls
pwd
cd.
These
are
not
git
commands.
Anything
that
get
handled
starts
with
the
word
git,
so
these
are
just
kind
of
for
navigating
to
and
from
files
on
your
computer.
A
So
I'm
going
to
leave
these
out
of
the
git
cycle,
but
yeah
I
just
kind
of
wanted
to
talk
about
this
cycle,
so
there
are
kind
of
two
locations
involved,
there's
your
local
machine
and
then
there's
the
get
lab
repo
that
is
remote.
That's
the
repo
that
all
of
us
are
working
on
and
pushing
to
and
has
like
this
shared
repository
of
all
the
code
and
just
constant
changes,
and
this
is
kind
of
managing.
This
is
what
makes
it
get.
A
So
in
order
to
do
that,
we've
seen
that
we
need
to
do
a
few
other
things
so
on
our
local
machine.
We
know
that
we
have
to
kind
of
check
out
a
branch,
so
we
create
our
own
branch.
You
know
laura's
issue
number.
Whatever
we
check
out
that
branch
on
our
machine,
so
that's
kind
of
the
very
beginning
of
the
process.
We
make
all
of
our
changes.
A
A
We
also
have
to
do
a
git
commit
and,
while,
like
while
we're
in
this
kind
of
process,
I
can
do
a
git,
add,
add
all
my
changes
and
then
go
back
to
working
and
make
more
changes
and
then
do
a
get
ad.
Then
I
can
make
more
changes
and
I
can
do
a
git
ad
and
I
can
do
the
same
thing
with
committing.
I
can
make
changes
that
I'm
happy
with
commit
them
and
then
go
back.
Make
changes,
get
add,
git
commit,
go
back,
make
changes
get
ad.
A
You
can
do
these
as
many
as
many
times
as
you
want.
You
don't
have
to
do
a
get
ad,
every
time
that
you
change
a
file
and
then
get
committed
and
then
push
it.
So
you
can
kind
of
bundle
all
of
these
processes
together
and
once
we've
committed
that
tells
git
like
okay,
we've
got
this
code
on
the
launch
pad
and
like
we're,
gonna,
send
it
up
to
the
cloud.
A
So
the
analogy
that
I
was
always
taught
was
like
it's
like
a
rocket
ship
or
whatever,
and
your
code
is
like
sitting
on
the
launch
pad
and
then
running.
The
actual
git
push
is
what
sends
it
off
to
space
and
sends
it
over
to
this
repo
and
lets.
You
make
a
merge
request
and
at
this
point
once
you've
done
this
git
push
all
of
the
stuff
that
you've
done
is
now
public.
A
Other
people
within
gitlab
can
see
your
changes,
but
all
these
things
that
you've
done
up
until
then
making
your
own
branch
adding
committing.
This
is
just
on
your
local
machine.
You
can
make
branches
named
whatever
you
want,
and
no
one's
gonna
see
them.
No
one's
gonna
like
you
can
test
out
stuff,
and
this
is
just
like
just
for
your
eyes
only
until
you've
actually
pushed
that
code.
So
I
did
add.
A
I
think
I,
like
version
of
I'm,
adding
like
a
line
of
public
knowledge,
so
this
kind
of
is
a
private
part
and
then
once
you
push
it,
it
becomes
public
and
then
likewise,
as
soon
as
you
know,
you
want
to
go
and
start
a
new
project
or
you
want.
Maybe
tyler
has
done
something
for
me
that
I
want
to
add
in
my
branch.
A
I
need
to
pull
that
to
my
machine
and
merge
it
in
with
my
changes,
so
I
can
do
a
git
pull
if
tyler
has
touched
the
same
code
as
me.
It's
probably
going
to
yell
at
me
and
say
that
I
have
conflicts,
and
at
that
point
I
need
to
do
a
git,
rebase
or
get
merged
here
at
gitlab.
We're
all
about
the
rebase.
It's
very
like
rebase
culture,
which
I
never
really
used
before.
Get
merging
and
get
rebase
essentially
should
do
the
same
thing.
A
Merge
tries
to
take
code
a
and
code
b
and
make
sure
that
they
fit
together.
Rebase
takes
all
the
code
a
and
plays
it
on
top
of
code
b.
So
if
tyler
did
changes,
it'll
like
every
commit
he's
made
it'll
make
on
top
of
mine
and
it'll
stop
as
soon
as
it
hits
a
conflict
and
be
like
which
one
of
these
did
you
want
a
or
b,
so
they
do
the
same
thing
they
just
are:
some
are
better
for
certain
processes,
but
I'm
going
to
add
git,
rebase
or
git
merge
here.
A
A
I
ran
out
of
space
here.
I
should
make
my
art
more
bigger
or
my
frame
bigger,
but
yeah
get
rebased.
So
all
of
those
are
like
public
changes
that
will
help
you
get
your
local
version
back
to
normal
and
then
get
status.
I've
left
to
the
end
because
we
can
use
this
all
the
time.
I'm
just
gonna
like
make
a
bunch
of
copies
and
like
get
status
everywhere.
All
the
time.
A
You
should
get
to
a
clean
state
on
master,
so
even
where
you
are
now
where
you've
done
a
merge
request,
but
it
was
a
few
weeks
ago
and
there
have
been
lots
of
changes
to
master
since
then.
It's
always
a
good
idea
to
pull
those
changes.
So
if
you
want
to
on
your
local
machine,
you
can
always
do
get
pull
like
just
always.
Keep
that
up
to
date,
it'll
save
you
from
doing
like
huge
pulls
every
couple
of
weeks,
but
again,
if
you're
not
using
it.
A
That
often
that's
that's
up
to
you,
but
again,
I
always
start
with
get
status,
see
which
brands
I'm
on
it
says
like
on
branch
master
or
on
branch
laura
whatever,
and
if
that's
the
case,
I
need
to
go
to
check
out
master
and
if
it
gives
me
trouble,
it
says,
like
you've
got
changes.
What
do
you
want
to
do
with
them?
Get
stash
stash
those
changes?
It
saves
them
kind
of
on
this
local
area
in
your
computer,
and
you
can
always
pull
them
back
by
doing
a
git
stash
pop.
A
A
In
with
your
local
version
of
your
your
repository,
this
I've
had
to
use
more
often
than
I'm
proud
of
it's
like
not
a
not
a
good
thing,
if
you're
in
a
state
where,
like
you're
pulling
and
pushing
and
it's
giving
you
errors
a
million
times
over,
and
you
just
can't
do
anything
and
you
don't
know
what
the
conflicts
are.
As
far
as
you
know,
you
haven't
made
changes,
but
it
says
you
have
or
something
it
just
kind
of
gets
in
this
weird
state.
A
Maybe
a
script
has
run,
that's
changed,
something
for
you
and
you
don't
know
which
files
are
changing.
You
just
want
to
undo
it
just
forget
it
git
reset
hard
origin
master.
This
does
a
like
a
hard
reset.
It's
exactly
what
it
says:
hard
reset
to
the
origin
version.
Whatever
is
currently
live
in
production,
so
whatever
that,
whatever
the
most
recent
working
state
is
it'll,
pull
that
and
make
that
your
local
version,
so
it's
just
kind
of
like
a
you
know
in
emergencies.
Use
this
thing.
A
I've
had
to
use
it
a
few
times
since
I've
been
here
because
I
just
kind
of
get
stuck
in
these.
You
know
this
merge,
conflict,
hell
or
something
terrible
is
happening,
and
I've
made
two
lines
of
code
changes
and
I
can
just
remake
those
changes
later.
I
just
need
to
get
to
a
clean
state
and
then
making
murder
request,
which
you
all
did
like
a
few
weeks
ago.
A
I
don't
know
what
time
is,
but
yeah
always
get
status,
check
out
a
new
branch,
make
your
changes
and
then
get
ad,
get
commit,
get
push
and
get
push
usually
says,
like
you
have
to
push
where,
like
you
want
to
push
to
this
branch
and
you're
like
yeah,
I
do
and
then
it
makes
the
merge
request
and
you're
able
to
see
your
merge
request
in
gitlab
and
make
it
all
nice
and
and
get
someone
to
merge
it
in.
So
that's
my
like
wall
of
text
that
I
have
for
all
of
you.
B
A
Yeah,
this
has
happened
a
few
times,
it's
kind
of
one
of
the
beauties
of
git.
This
happened,
for
example.
I
don't
remember
when,
but
I
know
that
I
have
made
changes
and
then
I
get
brandon
to
review
those
changes.
He's
reviewed
my
merge
request
and
something
doesn't
look
quite
right,
but
I
don't
know
how
to
fix
it.
Maybe
something
with
cookie
bot,
so
brandon
can
check
out
my
branch,
it's
on
his
local
machine.
He
can
see
exactly
what
I've
done
and
he
can
make
changes
and
push
them
to
my
branch.
A
So
both
of
us
are
on
that
branch.
If
we
both
make
changes
to
the
exact
same
file
and
we
both
push
those
changes,
that's
when
we
get
merge
conflicts
it'll
be
like
which
one
do
you
want
to
keep,
and
one
of
us
has
to
like
undo
our
version
like
we
just
have
to
pick
one
or
the
other
one
commit
to
undo
and
one
commit
to
to
save
so:
yeah,
okay,
yeah,
the
beauty
of
git,
yeah
and
then
yeah
again,
some
confusion
between
fetch
and
pull
it's
a
preference
thing.
A
I
mean
it's
like.
I
always
do
a
get
pull
because
it
combines
fetch
and
merge.
Fetch
does
a
check
that
there
are
changes
and
kind
of
holds
them
before
pulling
them
into
your
computer.
Like
it's
like
there
are
changes.
Do
you
want
to
merge
them
in
or
like?
These
are
the
files
that
have
changed
and
they
might
mess
up
your
file
like?
If
you
merge
them
in,
you
might
get
conflicts
or
whatever.
A
So
some
people
like
to
do
a
fetch,
see
what's
different
between
their
version
and
the
remote
version
and
then
merge
it
as
long
as
they
think
it
looks
safe.
I
like
to
do
it
all
in
one:
go
just
pull
it
in
if
they're
merge
conflicts
I'll
deal
with
it
later,
but
I
think
they
both
effectively
do
the
same
thing.
The
pull
or
fetch
and
merge.
A
B
A
A
Same
same
with
me,
I,
like
I,
had
learned
this
at.
I
did
a
boot
camp
and
it
was
you
know
they
kind
of
used
that
spaceship
analogy,
so
it
wasn't
just
arrows
they
had
like
spaceships
and
stars
and
like
whatever
they
had
a
very
nice
kind
of
way
of
teaching
it.
But
it's
it's
very,
very
helpful
to
know
where
you
are
in
this
process
when
you're
doing
a
git
commit
like
for
me.
I
like
to
kind
of
fail
privately.
A
I
know
that
that
kind
of
goes
against
gitlab's
values,
but
I
like
to
test
things
out
and
play
around
on
my
local
machine,
and
only
when
I
know
that
things
are
like
kind
of
crisp,
then
I
commit
them.
So
it's
nice
to
know
exactly
how
much
this
process
I
can
do
privately
before
it
goes
publicly
and
could
break
something,
and
you
know
people
are
knocking
on
my
door
like
what
did
you
do
whatever
so
yeah?
That's
all
that
I
have.
I
will
stop
recording
last
last
call
for
questions.