►
From YouTube: Labs & Latte: Introduction to Git Part 5 - Git Remotes
Description
In this edition of Labs and Latte, Matt dives into Part 5 of our "Introduction to Git" series, which covers our ability to work with remote Git repositories, such as those hosted by GitHub.
If you want to follow along, you can play with this lesson right now at https://go.nrelabs.io/labs/?lessonSlug=git-version-control&lessonStage=4
EDITORS NOTE: Yes, I realize my video is a bit big in this one and is obscuring the terminal. Will find a better size/position in future episodes.
Introduction to Git Series:
- Part 1 - https://www.youtube.com/watch?v=YAXWxA4x8vs
- Part 2 - https://www.youtube.com/watch?v=b203WRT_hIg
- Part 3 - https://www.youtube.com/watch?v=mOj7kCfu7TY
- Part 4 - https://www.youtube.com/watch?v=qOmQzUR5t0E
- Part 5 - https://www.youtube.com/watch?v=Bqtk0wpgl4A
A
A
And
we've
got
a
great
episode
lined
up
today.
This
is
the
fifth
episode
in
our
version:
control
with
git
series,
there's
probably
gonna,
be
one
more
I
have
one
more
plan
and
then
maybe
we'll
look
at
some
other
subjects,
but
today
we're
gonna
be
starting
to
get
into
a
topic
that
I
think
is
really
important
if
you're
going
to
start
learning
about
using
git,
either
professionally
or
for
your
personal
projects,
and
that
is
the
idea
of
git
remotes
now
before
I,
get
into
get
remotes.
A
I
do
want
to
mention
a
little
bit
of
a
perspective
here.
If
you
haven't
seen
any
of
the
earlier
episodes,
I
highly
advise
that
you
go
back
and
watch
them
and
maybe
go
through
some
of
the
lesson
content.
The
reason
for
that
is
up
until
now,
we've
been
really
only
focusing
on
what
I
like
to
call
get
fundamentals.
A
These
are
concepts
like
working
with
staging
so
moving
files
into
and
out
of
staging
in
an
in
a
git
repository
in
a
local
git
repository
committing
those
those
changes
so
that
you
have
a
record
of
what's
changed
and
by
who,
and
at
what
time
things
like
that,
working
with
git
branches
and
merging
and
doing
things
like
that.
Checking
things
out.
All
of
these
are
are
under
an
umbrella
that
I
like
to
call
get
fundamentals.
A
I
call
them
that,
because
mostly
they're
gonna
be
with
you
no
matter
what
you'll
find
that
git
is
actually
a
very
robust
tool
and
there
are
a
lot
of
things
about
git
and
as
well
as
a
lot
of
the
other
software.
That's
built
on
top
of
git
that
we'll
get
into
shortly.
That
is,
that
is
actually
very
different.
Based
on
what
project
you're
working
on
and
what
environment
you're
in
and
if
you're,
working
with
git
professionally.
A
Now,
though,
as
we
start
to
get
into
this
topic
of
git
remotes,
we
start
to.
We
start
to
really
broaden
the
scope
of
what
we're
talking
about
there
are.
There
are
a
lot
of
things
that
we'll
talk
about
today
and
in
the
next
episode
that
are
actually
a
little
different
from
project
to
project
I'll,
try
to
call
those
things
out
as
I
come
across
them,
but
just
FYI
starting
really.
Now
roughly.
This
is
when
we
start
to
get
into
some
of
the
things
that
may
vary
based
on
project.
A
You
know,
from
project
to
project
I'll
try
to
keep
things
as
close
to
the
core
fundamentals,
as
I
can,
but
just
understand
that,
starting
now
we're
gonna
start
to
look
at
some
things
that
might
be
might
have
a
little
bit
of
variability
based
on
where
you're,
using
those
tools.
So
with
that,
if
you
haven't
grabbed
a
coffee,
please
do
so
and
let's
dive
in
to
get
remotes.
So
here
we
are
in
part
5
of
this
lesson
and
as
always,
if
you'd
like
to
follow
along
which
I
encourage
you
to
do
the
lesson.
A
The
link
to
this
particular
part
of
the
lesson
will
be
in
the
video
description
below
so
navigate
down
and
click
on
that.
If
you'd
like
to
follow
along
with
me
and
yeah,
so
so
get
remotes
we've
again,
we
thus
far
really
only
been
working
with
a
local
repository
in
the
first
four
parts
of
not
only
this
lesson,
but
all
these
different
videos
that
I've
recorded
on
this
on
this
subject,
we've
only
been
working
really
with
our
own
local
repository
and
naturally
this
is
where
people
start
using
get
really.
A
However,
in
practice,
in
my
experience,
it's
fairly
uncommon
for
it
to
stop
there
unless
it's
a
really
like
temporary
project
or
if
it's
just
sort
of
versioning,
maybe
some
simple
configuration
files
that
you
just
want
to
keep
track
of.
It's
pretty
rare
to
work
with
git
in
only
a
local
capacity.
Generally
speaking,
if
you're
using
git,
you
also
want
to
use
it
to
collaborate
with
other
people.
A
That
I
know
are
there
on
that
remote
repository
pull
them
into
my
repository,
so
you
can
think
you
can
kind
of
think
think
of
them
as
two
different
copies
of
the
same
repository
now.
The
visual
I
have
here
in
the
lesson
guide,
is
probably
a
really
good
way
of
looking
at
this.
This
is
certainly
not
the
only
way
that
git
remotes
can
work,
but
it's
a
very
popular
one
and
you'll
find
that
a
lot
of
what
I
have
in
this
lesson
is
based
on.
What
is
what
is?
What
is
what
is
common
in
practice?
A
Not
necessarily,
what's
always
going
to
be
true
for
you
in
your
particular
scenario,
but
this
is
a
pretty
common
way
of
looking
at
it.
If
you
are
trying
to
you,
get
to
collaborate
with
others,
you're
all
probably
going
to
have
a
copy
of
the
repository,
but
what
you
need
is
a
version
of
that
repository
or
yet
another
copy,
that's
sitting
out
there
that
everybody
can
access
generally.
A
And
what
this
does
is
it
allows
a
bunch
of
different
distributed
people
to
have
their
own
copies
of
the
repository,
but
then
there's
a
sort
of
there's
a
sort
of
neutral
middle
ground.
So
to
speak,
where
the
sort
of
the
golden
copy
of
that
repository
is
located,
and
the
idea
is
what
you
can
do
is
you
can
make
changes
in
your
local
repository
and
then
push
those
changes
to
the
remote
repository
so
that
other
people
can
see
what
you've
done
and
that
way
they
don't
have
to
have
access
to
your
laptop.
A
You
all
can
sort
of
meet
in
the
middle
in
this
public
repository
now.
This
brings
me
to
the
next
point
that
I'd
like
to
be
pretty
clear
on
a
lot
of
people
when
they
get
started
with
get.
They
get
hung
up
on
something
which
is
that
git
and
github
kind
of
sound
like
they're
the
same
thing
and
they're.
Absolutely
not
git
is
not
the
same
thing
as
github.
You
can
kind
of
think
of
git
as
really
pointing
to
a
lot
of
the
fundamentals
that
I've
talked
about
thus
far.
A
In
fact,
in
the
FIR
in
the
previous
four
parts,
I
haven't
brought
up
github
at
all
or
used
github
at
all.
Github
is
a
hosted
service
that
takes
the
core
fundamentals
of
get
all
the
things
that
we've
learned
about
and
more
and
what
they
do
is
they
actually
build
value
on
top
of
that
they
do
a
pretty
good
job
of
it.
In
my
opinion,
they
have
a
lot
of
really
cool
tools
for
collaborating
using
git,
but
in
a
more
streamlined
capacity,
especially
for
open
source.
So
things
like
issue
or
poll
requests
projects.
A
Now
they
have
actions
for
doing
things
like
running
serverless
functions
within
github.
All
these
things
are
specific
to
that
platform
and
are
not
core
to
get
itself
and
you're
gonna
find
that
I
try
to
do
as
best
I
can
to
use
the
terms
appropriately
when
I
when
I
mean
get
fundamentals,
I'll,
say
git.
When
you
hear
me
using
the
term
git
I'm
really
only
talking
about
those
fundamentals,
the
the
concept
of
you
know
staging
and
commits
and
branches,
and
all
that
kind
of
stuff
when
I
say
github.
A
What
I'm
talking
about
are
the
services
that
github
adds
on
top
of
those
core
get
fundamentals.
Now
the
benefit
of
using
a
platform
like
github
is
is
actually
multifaceted
again
it
they.
They
use
the
core
fundamentals
of
git.
So
if
you
want
to
use
things
like,
you
know
ingesting
commits-
and
things
like
that-
they're
built
around
that,
but
they
also
add
a
lot
of
value
on
top.
A
So
if
you
want
to
collaborate
with
an
open-source
project,
the
idea
of
using
a
pull
request
is
part
of
that
we're
gonna
get
to
that
in
the
next
part,
using
issues
and
projects
they
do
a
lot
of
really
cool
stuff.
But
I
want
to
be
clear
about
the
difference
between
the
two,
because
this
is
this
is
a
frankly
when
I,
when
I
am
helping.
People
understand,
get
I
run
into
this.
Oh,
my
goodness,
so
many
times,
people
get
hung
up
on
the
difference
between
git
and
github.
A
So
yeah
just
be
aware
that
the
two
things
are
not
the
same.
Github
is
really
built
on
top
of
git
and
offers
a
lot
more.
That
is
not
part
of
the
the
get
experience
that
we've
been
looking
at
thus
far.
The
the
experience
we've
been
looking
at
thus
far
is
really
mostly
only
about
the
fundamentals.
Okay,
now
that
that's
out
of
the
way,
let's
get
started
with
this
lesson,
this
lesson
is
actually
pretty
simple.
What
we're
really
only
going
to
do
now
is
get
become
accustomed
to
the
idea
of
using
the
remotes.
A
We
really
won't
be
going
into
too
much
detail
the
the
lesson.
This
part
of
the
lesson
really
only
focuses
on
the
bare
minimum
of
what
you
need
to
get
started
with
using
remotes
in
general,
because
there's
a
few
set
up
related
things
that
we
need
to
make
sure
are
taken
care
of,
and
the
first
thing
is
authentication
again.
If
you're,
using
a
service
like
github,
you're,
probably
gonna
have
some
sort
of
a
user
account
that
you're
gonna
need
to
set
up
and
when
you're
contributing
to
a
repository,
that's
located
within
github.
A
You
need
to
be
able
to
authenticate
to
that
service.
Github
needs
to
know
hey.
This
person
is
trying
to
push
all
these
commits
to.
Who
is
this
and
do
they
have
access
to
do
what
they're
trying
to
do
so?
The
way
that
we
do
that
is
we
authenticate
using
either
if
we're
using
HTTP.
That's
a
transport
protocol
that
you
can
use
with
git,
in
which
case
you
would
provide
baby
blah,
Blee
basic
authentication,
or
maybe
they
use
a
token
system
now.
A
I,
actually
don't
use
that
because
the
other
transport
that
you
can
use
is
SSH,
which
I
find
to
be
much
frankly
easier
to
use
and
it's
also
more
secure
and
you
can
also
use
when
I
have
two-factor
authentication
on
my
github
account,
and
this
is
compatible
with
that.
So
I
find
SSH
to
be
a
better
transport
protocol
to
use
in
general.
Obviously,
if
you
would
like
to
use
HTTP,
that's
your
prerogative,
but
this
lesson
guide
is
going
to
use
SSH
as
an
option.
A
So
in
order
to
do
this,
the
very
very
first
thing
we
need
to
do
is
actually
generate
an
SSH
key.
What
this
is
going
to
do
is
it's
going
to
create
a
public
and
private
key
pair
they're,
going
to
use
to
tell
our
git
remote
hey.
This
is
the
SSH
key
that
we
would
like
to
use
to
authenticate
to
you,
so
we
got
to
generate
that
key
first
and
you
can
click.
This
handy
run
this
snippet
button
and
it's
gonna
copy
that
command
over
here
into
the
Linux
one
terminal.
A
There's
no
output
to
that,
but
I
can
just
show
you
what
happened.
It's
gonna
generate
a
private
and
public
key
pair.
The
public
key
is
what
we
actually
need.
So,
let's
cap
the
contents
of
that-
and
you
can
see
that
the
contents
here,
everything
from
SSH
RSA
all
the
way
down
here
to
the
the
first
instance
of
antidote
at
Linux-
one
be
careful
not
to
include
this.
This
is
not
part
of
the
key.
This
is
just
the
next.
A
You
know
the
bash
prompt
itself
so
make
sure
you
don't
include
that
copy
all
the
way
up
to
here
and
all
the
way
back
to
SSH
RSA
make
sure
that
that's
highlighted.
You
can
then
copy
this
to
your
clipboard
by
hitting
a
control
insert
and
now
that
that's
in
our
clipboard.
The
next
step
is
to
navigate
over
to
our
remote.
Now,
a
quick
aside
on
this
as
well.
The
software
that
you're
looking
at
right
now
is
called
git
T.
A
This
is
designed
to
really
look
very
similar
to
github,
but
it's
not
github
just
want
to
be
clear
about
that.
It's
designed
to
look
very
similar
to
github
and
I
included
it
in
this
lesson
to
make
it
pretty
close
to
the
experience
that
you
would
get.
If
you
were
used.
Github
just
know,
it's
gonna
be
a
little
different,
it's
gonna
be
pretty
close,
but
it's
a
little
different.
A
There
are
some
very
minor
differences
in
general,
though,
what
you
should
do,
if
you
do
want
to
use
something
like
github,
you
should
already
have
a
creator
to
user
account
and
then,
once
you
have
an
account,
you
can
kind
of
pick
up
here
because
just
like
in
what
we're
gonna
do
here
with
git
T
you'll
still
have
to
do
the
same
thing
we're
doing
with
github.
So,
let's
sign
in
as
our
user
and
again
in
this
case,
we've
already
created
a
user
account,
but
in
github
you
should
create
your
own.
So
password
is
password.
A
One
exclamation
point:
let's
get
rid
of
that,
so
you
can
see,
there's
really
nothing
here.
What
we
need
to
do
is
we
need
to
add
the
SSH
key
to
our
profile.
What
this
does
is
it
tells
this,
the
our
git
remote
software,
that
whenever
we
send
a
request
using
this
ssh
public
key
that
we
are
authenticated
properly
and
that
we're
authenticated
as
this
jane
user.
So
to
do
that,
you
go
down.
Go
to
this
drop-down
and
click
settings
go
over
to
ssh,
gbg
keys
next
to
manage
SSH
keys.
A
You
click
Add
key,
just
skip
the
key
name:
cuz,
it's
gonna
get
filled
in
for
us
automatically
and
paste
the
contents
of
your
clipboard,
which
is
what
we
copied
from
the
last
step
into
this
content
field
and
then
just
simply
add
key.
The
UI
in
github
specifically,
is
a
little
different,
but
the
up,
but
otherwise
the
process
is
exactly
the
same.
You
go
to
your
profile,
there's
a
section
on
SSH
keys
and
you
add
your
SSH
SSH
key
there
so
cool.
A
What
this
means
is
the
SSH
key
that
we've
generated
in
the
Linux
one
terminal
in
this
container
is
now
added
to
our
account
and
we
can
now
use
it
to
authenticate
to
our
git
remote
software.
So
this
brings
us
to
the
first
use
case,
which
is
pushing
a
repository.
You
already
have
to
a
remote-
and
this
is
like
I
said
before
this
is
actually
not
a
very
uncommon
use
case.
It's
not
that
uncommon
to
just
want
to
work
with
get
locally
up
sort
of
off
the
bat.
A
Maybe
you
just
have
some
simple
config
files
that
you'd
like
to
apply
some
version
control
logic
to
I
mean
we
all
have
these
directories
on
our
laptops.
That's
got
some
important
config
files
in
them,
and
it
would
be
nice
if
we
could.
You
know,
track
the
changes
that
we've
made
to
them,
so
that
if
we
make
a
mistake,
we
can
go
back
maybe
weeks
later
and
make
sure
that
we
we
store
them
the
differences
between
them.
A
Maybe
you
know,
if
maybe
you
just
want
to
have
a
remote
copy
of
the
repository
so
that
if
your
laptop
gets
bricked,
you
still
have
a
copy
of
it
somewhere
else,
and
that's
totally
fine,
maybe
also
you
you,
may
you
may
say:
hey
you
know,
I've
had
this
local
repository
for
you
know
locally
for
a
while
and
I'd,
like
other
people
to
at
least
see
it
that
way
they
can
see
what
I'm
working
on
so
the
boss
doesn't
ask
questions
about.
What's
on
my
plate,
maybe
that's
another
use
case
like
I
said.
A
Inevitably,
there's
gonna
be
a
situation
where
you're
gonna
want
to
push
the
contents
of
your
repository
to
a
remote
repository,
and
that's
the
use
case
that
I'd
like
to
tackle
in
this
lesson
in
the
next
video.
By
the
way,
we're
gonna
get
way
more
complicated
with
this.
So
this
will
be
a
sort
of
a
simple
use
case
and
then
we're
gonna
build
on
what
we
learned
today
in
the
next
video
with
a
much
more
I
think
complex
and
useful
use
case.
A
So
for
now,
let's
just
focus
on
getting
the
the
repository
that
we've
been
working
with
this
whole
time.
This
this
repository,
my
first
repo
that
we've
been
working
with
for
four
videos
now
and
in
this
video,
we'll
concentrate
on
pushing
that
local
repository
to
the
git
remote
that
we
just
authenticated
to
so
the
first
step
is:
we
need
to
create
a
home
for
this
repository
right
now.
The
remote
has
no
knowledge
of
this
repository
whatsoever.
A
The
only
instance
of
this
repository
is
located
in
this,
my
first
repo
directory
that
we've
been
working
with
all
along,
and
you
can
see
this
is
here
right.
All
of
those
commits
are
still
here
right
now.
This
is
this
is
the
only
place
this
repository
is
located,
so
we're
so
what
we
have
to
do.
If
we
want
to
push
this
somewhere,
we
have
to
create
a
placeholder
for
it.
A
We
have
to
create
the
repository
itself,
so
we
go
to
new
repository
in
this
drop-down
and,
let's
name
it
my
first
repo
you
can
see,
there's
a
drop-down
just
ready
for
us,
which
is
nice,
my
first
repo.
Now,
let's
just
leave
everything
else.
Blank
and
the
main
reason
for
that
really
well,
first
off,
we
really
don't
need
to
populate
any
of
these.
You
can,
if
you'd,
like
I,
wouldn't
make
it
private,
you
can
fill
in
a
description.
If
you
want
I
would
leave
everything
else,
blank.
A
The
really
important
thing
that
you
should
leave
blank
is
this
checkbox
here
the
reason
for
that
is-
and
this
is
by
github
as
the
exact
same
option.
If
you
create
a
repository,
it
gives
you
this
option
for
initializing
the
repository.
Let
me
just
be
real
clear
about
what
this
option
actually
does.
If
we
were
to
check
this,
what
this
actually
does
is
it
creates
the
repository
and
then
it
automatically
adds
a
commit
of
its
own.
A
It
generated
it
automatically
makes
a
commit
that
includes
these
files,
that
it's
saying
the
the
dot
get
ignore
the
license
and
the
readme
and
normally
that
would
actually
be
great
because
it
sort
of
bootstraps
our
our
repository.
It
allows
us
the
opportunity
to
make
the
repository
have
at
least
something
in
it.
A
However,
in
our
case
this
is
actually
a
problem
because
we've
already
been
making
commits
of
our
own,
and
if
we
were
to
check
this
box,
it
would
create
a
commit,
a
root
commit
that
is
incompatible
with
the
ancestry
that
we
already
have
and,
and
we
wouldn't
be
able
to
push
the
commits
that
we
have
without
doing
some
crazy
magic.
So
what
we
actually
want
to
do
is
uncheck
this
and
create
a
totally
blank
repository
that
has
exactly
zero
commits
and
the
reason
again
for
that
is,
we
have
our
own
commits
that
we
intend
to
push.
A
So,
let's
just
create
a
blank
repository
for
now,
click
create
repository,
and
you
can
see
you
go
to
this
next
screen
now.
You'll
see
here,
as
mentioned
before,
there
are
two
transport
options
for
working
with
git
remotes
you
can
push
over
HTTP
or
you
can
use
as
SH
is
a
transport
and
if
you
navigate
between
the
two
really,
this
doesn't
do
anything
other
than
just
changing
some
of
these
helper
commands.
A
Then
then,
I'll
talk
about
shortly,
but
let's
just
highlight
SSH
so
that
everything
that
comes
pretty
clear,
you'll
see
the
URL
here
will
reference
this
in
a
little
bit
we'll
break
down
everything
inside
of
this
URL.
You
also
note
that
we
have
to
sort
of
code
snippets
that
are
provided
here
for
us
to
run,
based
on
what
we're
trying
to
do.
If
we
don't
have
an
existing
repository,
we
can
use
these
commands,
but
since
we
have
an
existing
or
posit
or
e,
we
actually
want
to
use
these
commands,
because
what
this
does
it
says?
A
Okay,
well,
you
already
have
your
own
commits,
so
I'm
not
gonna,
bother,
adding
commits
here.
What
I'm
gonna
do
is
actually
just
allow
you
to
create
a
reference
to
this
remote
and
push
what
you
already
have,
which
is
exactly
what
we
want:
okay,
so
let's
scroll
down
and
we'll
go
to
the
next
step
and
we'll
what
in
the
in
the
snippet
you
here
you
see
here
in
the
lesson
guide
you
see,
I
actually
have
copied
the
command.
A
That's
straight
from
this
example,
so
we're
actually
gonna
run
that,
but
before
I
actually
run
that,
let
me
explain
what
it
does
we're
already
in
the
my
first
repo
direction.
So
we
don't
need
directories,
so
we
don't
need
to
run
that,
but
let
me
break
down
this
a
git
remote
command,
because
this
is
a
little
new.
It's
a
sub
command.
We've
been
working
with
the
git
command
this
whole
time,
but
the
get
remote
sub
command
is
new.
Any
time
we
are
working
with
making
changes
to
remotes
we're
gonna
be
using
the
git
remote
command.
A
What
this
does
is
it's
actually
a
helper
command
on
top
of
git
config.
Remember
all
the
way
back
in
part,
1
we
work
with
git
config.
The
git
remote
command
allows
us
to
make
changes
to
the
configuration,
but
specifically
for
working
with
git
remotes,
so
we're
gonna
use
this
command
to
add
a
reference
to
the
git
remote
that
we
work,
that
we
just
setup
and
that
will
allow
us
to
use
another
sub
command,
namely
git
push
to
then
push
the
commits.
A
We
already
have
to
this
git
remote
a
little
bit
of
a
little
bit
of
a
sort
of
a
word
soup,
but
fortunately
what
we're
about
to
do.
We
only
need
to
do
once.
We
only
need
to
add
the
git
remote
configuration
once
and
then
from
there.
We
just
need
to
push
and
pull.
That's
it.
So
git
remote
again
allows
us
to
add
a
reference
to
our
remote.
As
you
might
imagine,
the
next
command
is
the
word
add
because
again
we're
adding
a
reference
to
this
remote
next
step.
Next
keyword,
rather
is
we're
gonna
type
origin.
A
Now,
technically,
you
can
put
whatever
you
want
here.
This
is
really
a
human
readable
label
for
the
remote
here
locally
and
we're
gonna
be
actually
referencing
this
label
in
the
next
command
that
we
run.
So
we
do
want
to
make
sure
we
use
a
name,
that's
reasonable.
We
don't
it
to
be
super
long.
Some
people
even
use
much
crazier
and
shorter
names
for
their
remotes
because
they
just
want
to
you
know:
save
keystrokes
we're
gonna
use
origin,
mostly
because
this
is
an
overwhelmingly
common
convention.
A
There
are
a
lot
of
other
commands,
for
instance,
get
clone
if
you're
cloning,
one
of
the
repositories
that
exists
remotely
to
your
local
file
system.
That
uses
this
as
the
default,
and
so
as
a
result,
origin
is
the
is
just
a
very
popular
convention
for
naming
remotes.
So
I
would
recommend
that
we
stick
with
that
and
that's
what
we're
gonna
do
for
now
in
the
next
version
of
the
in
the
next
video,
by
the
way,
we're
gonna
be
playing
with
us
a
little
bit,
but
for
now
we'll
just
keep
it
simple,
get
add
origin.
A
So
we're
saying
I
want
to
I
want
to
add
a
reference
to
a
remote
and
I
want
that
reference
to
be
named
origin,
so
that
I
can
use
that
reference
in
future
commands
now
the
last
parameter
for
this
command
is
that
URL
we
saw
earlier.
This
is
a
URL
for
using
the
git
protocol
specifically
and
by
using
this
we're
going
to
be
using
the
SSH
transport.
Now,
if
you
wanted
to
use
an
HTTP
transport,
the
URL
here
would
be
totally
different.
A
It
would
use
HTTP,
obviously
at
the
beginning
or
probably
HTTP,
and
then
the
format
would
be
a
little
bit
different
after
that.
But
since
we
want
to
use
SSH,
let's
start
with
git.
This
is
the
username
that
we're
forwarding
to
the
remote.
This
is
pretty
popular
actually
for
most
for
most
get
remotes
that
use
SSH
github
works
the
same
way:
you're
not
actually
authenticating,
as
the
get
user
you're
authentication
is
actually
being
done
by
the
SSH
key
we
set
up
before.
A
So
what
we're
doing
here
is
we're
just
saying
the
user
get
is
what
we're
using
in
this
particular
sort
of
protocol
that
we're
setting
up
here,
but
we're
still
authenticating
as
the
Jayne
user
by
virtue
of
our
SSH
key.
So
just
keep
that
in
mind.
Next
is
the
hostname.
Now
again,
if
you're
using
github,
this
is
probably
gonna
be
github
comm,
but
in
our
case
our
our
git
server,
the
the
server
that's
running
our
remote
software
is
actually
located
at
the
hostname
remote
and
we
can
even
access
that.
A
A
But
again
in
our
case
in
this
lesson
the
hostname
is
remote
from
there
we
type
a
colon,
and
here
is
now
from
now
it's
just
the
path
to
the
repository
you
can
think
of
it
kind
of
like
a
path
on
a
website,
so
we
say,
like
Jane,
is
our
username
or
in
it.
You
know.
This
is
where
our
repository
is
located
and
then
the
name
of
the
repository
itself,
my
first
repo
get
and
we
click
enter,
and
you
can
see
using
git
remote
V.
A
You
can
see
that
we
now
have
a
reference
to
the
remote
we
named
origin,
and
it
even
includes
the
URL
for
fetching
commits
as
well
as
pushing
which
is
cool
now.
V
I
also
want
to
mention,
as
I
mentioned
before,
get
remote
is
also
a
hell,
is
basically
a
helper
command.
On
top
of
git
config,
so
this
actually
does
modify
our
git
config.
So
if
we
list
the
git
config
options,
you
can
see
that
our
git
config
has
been
augmented
with
these
options.
A
So
the
URL
that
we've
added
is
is
is
right
here
and
the
name
origin
is
also
added
as
an
option
there.
So
yeah,
it's
Turtles,
all
the
way
down.
Okay,
rubber
meets
the
road,
we've
added
a
reference
to
the
remote,
but
we
haven't
actually
pushed
anything
to
our
remote
repository,
and
you
can
see
this
by
clicking
again
on
my
first
repo.
Nothing
has
changed.
So,
let's
push
our
changes.
A
That
way,
we
can
actually
see
some
stuff
here
in
the
web
UI
if
we
do
get
push
and
we
type
dashed
you
and
in
the
origin
or
the
the
name
of
the
remote
again
is
origin.
So
we're
saying
I
want
to
push
to
this
remote
and
we
reference
it
by
name,
so
we
set
up
the
remote
first
and
then
we're
referencing
it
by
the
name
origin,
and
then
we
specify
the
git
ref
or
the
really
the
reference
to
the
the
thing
that
we
want
to
push.
A
This
could
be
any
number
of
things
by
the
way,
but
in
this
case,
what
we're
doing
is
we're
pushing
the
master
branch,
so
we
just
type
master
now,
there's
a
whole
bunch
of
output.
To
this
you
can
see
that
the
very
first
bit
of
output
is
actually
from
SSH
itself,
saying:
hey
I've
added
this
IP
address
and
this
hostname
to
the
list
of
known
hosts
and
that
way
going
forward.
A
Basically,
the
server
is
letting
the
client
know
that
it
was
created
which
is
kind
of
cool,
and
if
we
go
back
to
the
remote
branch,
we
can
then
click
on
my
first
repo
and
now
that
all
that
helper
text
is
gone
and
we
can
see
the
contents
of
our
repository,
and
this
simply
contains
the
entered
interface
config-
that
txt
file
that
we've
been
working
with.
This
whole
time-
and
you
can
even
click
on
it
and
see
its
contents.
You
can
also
see
the
commits
tab.
A
So
if
you
wanted
to
see
all
the
commits
that
we've
made,
this
is
a
nice
graphical
representation,
all
of
the
SHA,
the
the
Hat.
You
know
the
commit
the
commit
IDs
are
represented
here
you
can
click
on
them
or
the
commit
message
to
see
the
actual
commit
and
the
changes
that
were
made
here.
This
is
Fred
sort
of
interacting
with
our
repository
that
we
saw
before
so
yeah.
That's
pretty
cool.
A
Now
the
last
thing
I
want
to
show
we've
pushed
commits
to
the
remote,
let's
figure
out
a
way
to
pull
or
fetch
commits
from
the
remote
repository
to
our
local
to
our
local
repositories.
So
if
somebody
were
to
make
a
change
say
to
the
remote
repository,
we
can
then
incorporate
those
changes
back
to
our
repository
again.
This
is
a
common
example
like
there
are
some
open-source
projects
that
have
people
integrating
their
changes.
A
You
know
maybe
hundreds
or
even
thousands
of
times
every
day,
and
we
need
to
be
able
to
constantly
be
able
to
pull
those
changes
down
to
our
local
repository
so
that
we
can
make
sure
we're
working
with
the
most
recent
version
and
the
way
that
we
do,
that
is
by
use
we've
used
the
git
push
command.
Now,
let's
use
the
git
pull
command
before
we
do
that.
Let's,
let's
put
let's
get,
let's
generate
a
change
so
that
we
can
actually
pull
something
right
now.
A
The
our
local
repository
is
actually
that
the
same
version
of
as
our
remote
repository.
So
in
order
to
pull
something,
we
need
to
make
a
change
now
again.
Normally
this
would
be
done
by
somebody
else,
but
let's
simulate
this
by
just
making
a
change
of
our
own.
The
cool
thing
about
remote
software
like
this
as
well
as
github
github,
offers
the
same
feature
is
you
can
actually
make
changes
to
files
right
here
right
here
in
the
web?
Ui
I
wouldn't
necessarily
rely
on
it
for
complex
changes,
because
it's
not
a
full-blown
IDE.
A
It
doesn't
have
any
sort
of
like
linting
or
anything
like
that.
But
for
simple
changes:
it
can
be
quite
handy
so
we'll
just
edit
this
file
real,
quick
and
make
a
quick
change
change.
The
IP
address
to
something
silly
like
that.
You
can
see
that
you
can
make
your
own
commit
message
right
here
in
the
web
UI.
You
also
have
an
option
to
commit
directly
to
the
master
branch.
You
you'll
see
an
option
here
that
says,
create
a
new
branch
and
start
a
pull
request.
A
You
know,
you
know
about
branches,
but
we
haven't
actually
covered
pull
requests.
Yet
that's
something
we'll
cover
in
the
next
video
so
for
now,
let's
just
commit
directly
to
the
master
branch
cool.
So
if
we
go
back
to
the
commits
tab,
you
can
see
it
actually
created
a
commit
for
us
three
seconds
ago.
The
commit
message-
the
default.
One
anyway
is
update
interface,
config
txt,
and
it's
it's
built
off
of
the
last
commit.
A
But
if
we
were
to
go
back
to
Linux
one
you
can
see
if
we
do
get
log
not
got
log
git
log,
you
can
see
that
the
current
latest
commit.
Is
this
999
four
six,
six
five,
which
is
this
commit?
So
there
is
now
a
commit
in
the
remote
repository
that
we
don't
have
locally
and
we
need
to
make
sure
we
pull
that
down,
as
you
might
expect
that
uses
the
git
pull
command.
Now
again,
we've
already
specified
the
remote
we've
already
set
up
that
reference
to
origin.
We
don't
have
to
do
that
again.
A
We
simply
refer
to
it
here
in
the
git
pull
command
and
again
we
specify
the
branch
that
we
would
like
to
fetch
and
you
can
see.
We've
we've
moved
from
the
the
the
head
was
previously
pointing
to
that
99
commit
and
now
we're
pointing
at
E
5
3
1
be
F
0.
You
can
see
the
deaths
now,
yes,
that's
the
that's.
A
The
latest
commit
that
I
should
have
oops
didn't
mean
to
navigate
out
of
that,
and
now
we
can
type
git
log
one
more
time
and
you
can
see
that
we
now
have
that
latest
commit
and
if
we
cat
interface
to
config,
you
can
see
the
change
is
here
so
yeah
we've
we've
actually
pushed
and
pulled
commits
to
and
from
our
remote
and
now
we're
set
up
to
do
much
more
complicated
things.
So
this
is
a
pretty
light,
intro
to
get
remotes,
but
I
think
this
is
really
gonna.
A
This
is
really
necessary
to
really
level
set
and
get
us
started
working
with
git
remotes,
because
we're
gonna
be
building
on
a
lot
of
what
we
just
did
in
the
next
lesson,
which
talks
about
things
like
how
do
I
contribute
to
a
project
that
I
don't
own.
For
instance,
that's
that's
another
very
common
use
case
for
this
use
case
we're
just
dealing
with
a
repository
that
we
control,
but
if
you're
using
git,
maybe
to
contribute
to
an
open
source
project
that
you,
that
is
in
a
repository
that
you
don't
control.
How
do
you
do
that?