►
Description
Presented by Sarah Guthals, Manager, Engineering (GitHub) & Rachel Macfarlane, Software Engineer (Microsoft).
Independently, the Visual Studio Code team at Microsoft and the editor tools team at GitHub began exploring the possibility of an integration between their two products. The team at Microsoft started to design a pull request experience within Visual Studio Code, while the GitHub team prototyped one modeled after the same experience in the Visual Studio IDE. In this session, you’ll get an overview of how two companies worked together to support collaborative and open source development. You’ll also hear about the latest features and learn how you can contribute.
About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.
For more information on GitHub Universe, check the website:
https://githubuniverse.com
A
First
I'd
like
to
introduce
you
to
the
team
from
Microsoft.
We
have
Rachel
Peng,
CAI
and
Kenneth,
and
from
github
we
have
Shana
she
and
myself
Sarah
and
if
you're
here
at
universe,
locally,
we'd
love
for
you
to
come,
say
hi
to
the
four
of
us
who
are
walking
around
chat
with
us.
Let
us
know
what
you
think.
A
B
So,
as
Sarah
said,
my
name
is
Rachel
I'm,
an
engineer
working
at
Microsoft
on
vs
code
and
I'm
really
excited
to
show
you
what
we've
created.
So
this
extension
is
actually
already
available
in
the
marketplace.
So,
if
I
go
to
the
extensions
viewlet
within
vs
code,
I
can
search
for
polar
quest
and
find
the
github
for
quests
extension
you'll
notice
that
it
has
this
preview
tag.
B
So
this
means
that
we
may
continue
to
iterate
on
the
UI
and
there
are
still
things
we'd
like
to
add
to
the
extension,
but
it
currently
is
stable
and
you
can
go
download
it
and
use
it
right
now.
So
I've
actually
already
installed
it's
my
machine.
So
the
first
thing
I'd
like
to
do
is
sign
into
github
and
I
can
do
that
in
one
of
two
ways:
I
can
either
use
this
status
bar
item
at
the
bottom
or
I
can
use
the
command
palette.
B
So
I
have
open
NBS
code,
an
actual
fork
of
the
extension
code,
so
today
we're
going
to
use
the
pr
extension
to
review
a
PR
for
the
PR
extension.
So
where
do
I
go
within
vs
code
to
find
information
about,
pour
requests?
Well,
if
you're
familiar
with
vs
code,
you
know
that
the
source
control,
viewlet
houses,
information
related
to
source
control.
So
this
is
where
I
go
to
stage
and
commit
changes,
and
we
thought
this
was
a
great
place
to
put
this
new
github
pull
requests
view.
B
B
It
looks
like
my
coworker
pong
has
been
hard
at
work
and
has
created
two
pull
requests
today.
So,
let's
dive
into
these
as
soon
as
I
expand
the
pull
requests.
Node
I
see
a
description
note
and
a
list
of
file
changes
associated
with
the
pull
request
clicking
on
the
description.
Node
gives
me
more
information
about
the
pull
request,
including
the
description.
Any
commits
any
comments
on
it
and
from
here
I
can
also
add
more
comments
directly
to
the
PO
requests.
I
can
also
jump
directly
to
github.com
from
this
page.
B
So
we
see
the
exact
same
information
is
displayed
here.
So
what
is
this
pleure
quest
actually
about
here?
Poem
says
that
he's
adding
an
avatar
to
the
commits
tree.
So
let's
take
a
look
at
the
file
changes
as
soon
as
I
click
on
a
file
change
a
diff
a
determines,
just
as
it
would
for
any
other
type
of
file
change
with
NBS
code.
One
thing
that's
important
to
note
is
this:
change
is
not
actually
local
to
my
machine
at
this
point.
B
We're
essentially
browsing
github,
so
the
extension
is
fetching
the
diff
from
github
and
constructing
the
entire
file
view.
For
us
one
thing:
that's
new
to
the
UI:
is
this
white
gutter
margin,
so
this
indicates
exactly
where
I
can
add
comments
within
the
editor.
If
you're
familiar
with
polar
quest
on
github.com,
you
know
that
you're
limited
to
commenting
in
and
around
changes
and
since
we're
using
the
same
API.
We
have
the
same
limitation.
B
B
You'll
notice,
as
soon
as
I
started,
adding
the
comment
a
decoration
appeared
in
the
gutter.
This
diamond
decoration
indicates
where
comments
are
and
it
can
be
used
to
collapse
and
expand
comments.
So
I
feel
really
good
about
this
change
and
I
actually
want
to
go
approve
it.
If
I
go
back
to
the
description
page
I
can
do
this.
Just
that
so
I
can
approve.
I
can
request
changes,
I
can
close
or
merge
the
pull
request
from
here.
I'll
approve
it
so
now
I
want
to
prove
to
you
that
I
did
actually
just
do
this.
B
B
So
Punk
says
this
is
a
work
in
progress
and
he
has
some
questions
that
he
wants
me
to
answer.
I
can
scroll
down
the
description
page
and
see
what
exactly
these
questions
are.
I'd
really
like
to
be
able
to
navigate
to
the
file
with
comments
by
just
clicking
on
this,
but,
as
I
said,
this
is
still
a
preview
version
of
the
extension.
So
currently
we
don't
have
this.
B
In
fact,
this
is
something
we
would
love
to
see
a
PR
for,
if
you
feel
inspired
so
since
I'm
not
able
to
navigate
here
I'll
instead
go
back
to
the
file
changes
view,
so
you'll
notice
that
some
of
these
files
have
diamond
decorations
next
to
them.
This
indicates
what
files
have
comments
on
them
clicking
on
this
once
again
opens
it
if
you
and
I'm
scrolled,
immediately
to
the
common,
so
here
pong
is
asking:
should
we
be
using
URI
to
parse
or
URI
dot
file?
B
I,
remember
that
one
of
these
takes
a
string
as
takes
a
pass
as
the
argument
and
the
other
one
takes
the
complete
URI
I
can't
remember,
which
is
which,
though
so
I'd
really
like
to
be
able
to
go
to
definition.
But
as
I
said
earlier,
these
changes
aren't
local
to
my
machine,
so
I'm
not
able
to
do
that
right
now,
but
if
I
go
back
to
the
scription
page,
I
can
either
use
this
check
out
button
or
this
context
menu
item
to
actually
check
out
the
pull
request.
B
So
by
doing
this,
I
now
have
a
local
branch.
That
is,
that
porpoise
branch,
so
I
have
all
of
those
changes
to
review
and
you'll
notice
that
two
things
changed
in
the
UI
when
I
did
that
first
I
know
how
the
changes
in
pull
request
view.
So
since
we're
looking
at
a
particular
branch
associated
with
a
pull
request,
we
really
want
to
focus
in
on
that.
So
this
once
again
shows
the
list
of
files
as
well
as
the
list
of
commits.
So
this
is
what
Poong
was
adding
an
avatar
to
earlier.
B
The
second
piece
of
the
UI
that's
been
added
is
this
comets
panel.
So
this
gives
me
an
overview
of
all
of
the
comments
within
my
workspace
and
from
here
I
can
easily
navigate
to
them.
If
you're
the
person
who
submitted
the
PR,
this
could
also
act
as
a
sort
of
to-do
list
of
things
you
might
need
to
fix.
B
B
B
If
I
wanted
to
I
could
actually
directly
make
changes
in
this
file,
so
I
can
delete
this
line
myself
and
I'll
see
that
that
change
shows
up
on
top
of
the
current
changes.
So
if
I
wanted
to
I
could
actually
commit
that
and
then
push
it
to
the
branch,
but
instead
I
want
to
explore
what
would
happen
if
Poong
was
also
making
changes
to
this
while
I
was
reviewing
it.
So
what
happens
if
he
makes
a
commit,
while
I
have
this
checked
out,
and
to
do
that?
B
So
I'll
remove
that
blank
line
and
commit
that
change
go
back
to
use
code,
so
the
extension
is
pulling
for
updates
in
the
background
so
to
expedite
that
process.
I'm,
actually
just
gonna
do
a
refresh
right
now
and
as
soon
as
I've
refreshed.
It
I
see
this
notification
telling
me
that
there
are
updates
available
for
my
branch,
so
I'm
able
to
pull
them
right
in,
and
you
see
that
the
line
has
now
been
removed
and
I
can
continue
to
work.
B
B
So
I've
addressed
both
of
Punks
questions
and
I'd
now
like
to
leave
this
sort
of
review
state.
How
do
I
do
that?
Well,
how
did
I
get
into
the
state
in
the
first
place?
All
I
did
was
change
to
a
branch
that
was
associated
with
a
pull
request,
so
to
leave.
All
I
need
to
do
is
check
out
a
different
branch.
B
So
as
soon
as
I
check
out
a
different
branch,
other
UI
updates
automatically
I
now
no
longer
have
the
changes
in
poor
Crestview
and
the
Comets
panel
is
gone.
I'm
now,
in
the
exact
same
state,
I
was
before
I
started
and
I've
completed.
Looking
at
these
two
pull
requests
so
I
hope
that's
giving
you
a
sense
of
what
you
can
do
with
the
extension
and
I'll.
Now
give
it
back
to
Sara
to
talk
more
about
the
motivation
and
the
background
of
this
extension.
A
Thanks
Rachel
are
people
excited
about
this
whoa
come
on
yeah?
Well,
we
are
before
we
get
into
where
we're
going
next.
I,
don't
know
if
you've
heard,
but
github
really
cares
about
developer
workflows.
Have
you
have
you
all
heard
about
that?
I,
don't
know,
maybe
a
couple
times
this
week
we
really
really
care
about
developer
workflows
and
we
recognize
that
developers
aren't
always
in
a
web.
Page
I
know
it's
crazy.
They
also
are
on
a
local
machine
using
other
tools,
other
editors,
IDE,
etc,
etc.
A
Typically,
when
you
start
your
on
github.com,
you
might
be
looking
through
some
issues
trying
to
figure
out
what
you
want
to
solve.
Next,
what
you
want
to
close
out,
you
might
fork
the
repository
and
then
you'll
head
back
down
to
your
local
environment
and
you'll
clone
and
create
a
branch.
Maybe
you'll
do
this
in
your
IDE,
maybe
you'll.
Do
this
on
command
line
or
maybe
I'll
use
github
desktop,
then
you'll
write
code.
This
is
pretty
well
handled
by
your
editor,
whether
you're
using
vs
code
atom,
something
else,
and
then
you'll
actually
want
to
contribute.
A
I,
don't
know
why
this
isn't
then
you'll
actually
want
to
contribute
your
code
back
to
the
repository
and
the
way
that
you
do
this
on
github
is
by
creating
a
pull
request.
This
is
essentially
requesting
that
the
changes
that
you've
made
on
your
branch
get
pulled
into
the
branch
that
you're
targeting.
A
But
then
something
really
interesting
happens.
You
have
this
complex
conversation
between
a
contributor
and
a
maintainer
and
I
say
complex,
because
it's
not
just
a
series
of
comments
back
and
forth.
For
example,
the
maintainer
may
want
to
actually
pull
down
the
code
and
test
it
and
maybe
even
help
debug
something
that
can
that
a
contributor
is
running
into
and
all
this
while
the
contributor
may
also
still
have
other
features,
they're
developing
on
this
polar
quest
or
other.
A
You
know
bits
and
pieces,
and
so
they
may
want
to
be
responding
to
comments
coming
in
from
the
maintainer
--zz.
You
saw
this
in
the
demo.
This
is
a
back-and-forth
dance
between
github,
calm
and
your
local
environment
that
we're
trying
to
solve
the
paid
point
for,
and
then
you
might
have
heard
of
something
about
github
actions
coming
along.
This
is
where
we
really
care
about,
deploying
and
eventually
merging
your
code
and
getting
it
out
into
the
hands
of
your
users.
A
I'd
really
like
to
highlight
this
piece,
though,
because
back
in
2015
we
were
building
the
github
Desktop
for
Windows
app
and
our
developers
were
using
Visual
Studio
to
build
this
and
the
dance
between
Visual,
Studio
and
github
comm
was
just
a
huge
time-suck.
We
found
it
very
difficult
to
have
two
large
windows
open
on
one
small
laptop,
and
we
were
doing
a
lot
of
communication
back
and
forth
using
github
comm.
A
At
that
time
we
started
the
github
extension
for
visual
studio,
and
today
you
can
find
a
similar
list
of
features
where
we
have
pull
requests.
You
can
check
them
out,
create
them
and
have
in
line
comments
all
within
your
visual
studio
environment.
Around
the
same
time,
we
were
building
a
first
class
experience,
for
we
were
building
a
first
class
experience,
github
experience
for
Adam,
starting
with
get
operations
such
as
cloning,
committing
pushing
pulling
syncing,
etc.
A
I,
don't
know
why
this
is
I'm,
just
gonna
stop
and
then
in
2016
we
started
exploring
another
developer:
workflow
the
game,
developer,
workflow
folks,
using
unity,
we're
caring
about
other
things
like
file,
locking
and
get
LFS.
So
we
provided
support
for
that
in
2017.
We
began
thinking
about
vs
code.
Vs
code
is
very
important
for
a
lot
of
open
source
developers
and
we
wanted
to
make
sure
that
we
were
supporting
our
github
experience
where
all
of
our
developers
are
so
we
started
working
on
a
prototype
and
in
early
2018.
A
Yes,
before
acquisition
announcements
before
we
ever
knew
anything.
We
went
and
visited
Rachael's
team
up
in
Redmond
and
found
out
that
they
had
a
very
similar
prototype
only
they
had
access
to
vs
code
api's
that
were
not
yet
available.
So
we
decided
to
collaborate
on
this
project.
I'm
now
gonna
have
Rachel.
Tell
you
a
little
bit
about
how
Microsoft
came
to
to
work
on
this.
B
B
But
at
that
time
we
looked
on
the
extensions
marketplace
and
nothing
gave
the
end-to-end
experience
that
I
just
demoed,
so
we
decided
that
we
wanted
to
bring
in
code
review
features
2
vs
code
and
whenever
we're
adding
a
new
feature
to
vs
code.
The
first
question
we
have
to
answer
is:
does
this
belong
in
the
Corvis
code,
or
should
this
be
implemented
as
an
extension?
B
We
can
think
of
code
editors
as
being
on
a
spectrum
between
pure
text
editors
and
heavyweight
IDs,
and
we
want
vs
code
to
be
in
the
sweet
spot
between
these.
That
is,
we
want
it
to
be
as
lightweight
as
possible,
while
still
maintaining
the
best
support
for
the
developers,
inner
loop,
the
cycle
of
coding,
building
and
testing.
B
When
we
first
discussed
the
code
review
features,
it
quickly
became
apparent
that
this
should
be
implemented.
As
an
extension
for
some
of
our
users
code
review
was
part
of
their
inner
loop.
It
was
something
they
did
every
day,
but
for
others
it
wasn't,
and
secondly-
and
this
may
shock
you,
but
we've
heard
that
not
everyone
uses
github
to
do
it.
So
we
wanted
to
be
able
to
create
code
review
experiences
that
would
work
with
a
number
of
providers,
but
we
started
with
github
so
that
we
could
self
host
on
our
own
extension.
B
So,
in
April
of
this
year
we
started
building
a
prototype
of
this
extension
and
Sarah's
team
reached
out
to
us
at
this
time,
and
we
met
and
demoed
our
prototype
search
teams
showed
all
of
the
work
they've
done
on
Visual
Studio,
and
we
realized
that
we
were
really
working
towards
a
common
goal.
So
from
that
point
onward,
all
of
our
effort
on
the
extension
was
joint
effort
to
actually
build
the
extension.
We
reused
a
number
of
vs
codes
api's,
but
we
also
created
new
api.
So
I
want
to
talk
a
bit
about
that
process.
B
First,
what
was
the
existing
API?
We
could
use
for
the
github
pull
request
view
we
use
the
tree
data
provider
API
most
of
the
API
is
with
NBS
code.
Are
a
data
provider
model
that
is
the
extension,
provides
data
to
vs
code
and
vs
code
is
responsible
for
determining
the
view
and
actually
rendering
this
data.
B
This
is
in
contrast
to
the
webview,
which
is
what
we
use
for
the
description
page
with
this
API,
the
extension
control.
What
UI
is
shown
within
the
editor?
So
for
the
description
page,
we
wanted
this
to
be
specific
and
custom
to
github,
which
is
why
we
went
with
the
get
with
the
webview
API
here.
So
then,
what
was
the
missing
piece
of
API?
B
As
we
began
developing
and
prototyping
the
extension?
We
realized
that
there
was
a
real
gap
around
commenting
we
couldn't
cobble
together.
Any
existing
API
is
to
create
a
good
experience
for
this.
More
importantly,
we
realized
that
commenting
would
be
a
really
killer
feature
to
have
in
vs
code.
We
could
see
this
being
used
in
a
broad
range
of
extensions,
anything
related
to
code,
review
and
code
collaboration
could
make
use
of
this
API.
B
So
the
next
question
was:
how
much
control
does
the
extension
have
over?
What
a
comet
looks
like?
Is
this
a
data
provider
model,
or
is
this
more
like
a
web
view,
and
we
went
back
and
forth
on
this,
but
ultimately
we
decided
that
this
should
be
a
data
provider.
So
first
we
wanted
to
make
sure
that
comments
would
be
consistent
across
extensions.
We
didn't
want
users
to
have
different
experiences
with
different
commenting
extensions,
so
comments
should
have
both
consistent
UI
and
behavior.
Thinking
back
to
the
demo,
we
had
added
this
command
in
tersh
Orkut.
B
We
wouldn't
want
each
individual
extension
to
come
up
with
its
own
shortcut
for
this.
Instead,
we
want
one
editable
key
binding.
Secondly,
this
is
going
directly
into
the
editor.
This
is
the
most
important
part
of
es
code,
so
we
want
to
make
sure
that
anything
that
gets
contributed
directly
to
the
editor
is
not
going
to
compromise
its
responsiveness,
stability
or
security,
and
so
for
that
reason
we
went
with
the
data
provider
model,
and
this
is
what
that
API
actually
looks
like.
B
So
when
Pung
and
I
first
implemented
this.
It
only
had
the
ability
to
show
comments
and
to
add
new
comments,
and
so
we
created
a
version
of
this
extension
using
that
API
and
gave
it
out
to
the
rest
of
the
team
to
test
every
other
person
kept
asking
us
hey.
How
do
I
edit
comments?
Twitter
replied:
just
don't
make
mistakes,
but
in
the
last
iteration
we've
added
support
for
editing
and
deleting
comments,
and
this
is
still
an
evolving
API.
So,
with
NBS
code
we
have
two
stages
of
API
proposed
and
stable.
B
A
A
From
here
you
can
see
from
here
you
can
access
the
extension
from
the
vs
code
marketplace.
You
can
quickly
get
to
the
open
source
repository.
You
can
open
up
an
issue
here
or
better,
yet
close
one
out
and
contribute,
and
you
can
also
connect
with
us
in
other
ways
we're
on
Twitter
and
we
also
run
usability
research
studies
for
all
of
our
editor
extensions
and
we'd
love
to
have
you
participate
so
that
we
can
understand
your
unique
developer,
workflow
and
see
if
we
can
better
support
it.