►
Description
Pull Requests are one of most essential workflow pieces of modern application development. If used effectively with proper code review and your existing workflow, they can not only help ensure high quality of written code, but do so without sacrificing the speed of development.
Brent Beer starts out by looking at what makes a great pull request, and what barriers people have with sending and receiving them. He'll discuss code review best practices and he'll show how and why these pieces are a crucial part of a proper workflow, and what advantages the GitHub Flow has.
About GitHub Universe:
Great software is more than code. GitHub Universe serves as a showcase for how people work together to solve the hard problems of developing software.
For more information on GitHub Universe, check the website:
http://githubuniverse.com
A
So
my
name
is
Brent
beer
I'm,
one
of
the
Sales
Engineers
at
github,
I've,
been
forgetting
at
github
for
a
little
while
now
before
that
I
was
on
the
training
team.
So
you
may
have
seen
my
face
or
been
in
one
of
my
webinars
or
seen
me
out
publicly
speaking
at
a
another
conference
or
doing
another
workshop.
A
That's
not
always
the
case
and
there's
some
some
tips
we'll
see
throughout
this
and
some
approaches
we'll
see
that,
hopefully
you
can
take
back
to
your
office
and
work
with
once
you
get
there.
If
you
do
see
some
things
up
here
that
are
familiar
to
you.
Maybe
you
already
know
how
pull
requests
work?
That's
great,
hopefully,
there's
additional
things,
I,
say
or
there's
some
additional
notes.
A
You
may
have
to
ask
me
at
the
end,
during
any
QA
time,
where
we
can
kind
of
discuss
anything
that
you'd
like
and
I'd
like
to
discuss
about
any
of
different
approaches
or
how
you
can
take
some
of
these
back
to
your
company,
and
we
can.
We
can
talk
about
how
to
kind
of
grow
and
change
certain
culture
you
may
have
within
your
company
as
well.
A
So
let's
jump
right
into
it.
So
this
is
at
one
version,
I,
guess
of
a
traditional
software
process.
People
work
on
a
work
on
some
change.
They
have
some
sprint
planning,
they
have
a
ticket
to
get
assigned
to
someone,
they
do
some
development
and
they
make
some
changes.
They
have
some
kind
of
continuous
integration.
Work
testing
great
glad
to
see
that,
but
then
code
review.
Is
this
completely
separate
thing
off
to
the
side
because
it
can't
work
with
their
current
workflow?
A
They
don't
use
pull
request,
maybe
because
they're
using
some
other
version
control
tool
and
besides
github
they're
on
on
SVN,
and
they
don't
even
do
branching
that
well
or
I.
Don't
know
the
most
developers
that
I
talked
to
are
more
than
I'd
like
to
admit
run
into
problems
like
this.
They
don't
get
good
feedback
on
their
code
right
away
and
they
often
struggle
to
improve
their
own
quality
of
code.
So
this
isn't.
A
This
is
feels
pretty
rigid
to
me
and
it
doesn't
have
to
work
that
way
and
I
want
to
help
show
that
we
can
all
do
better
and
we
can
do
better
for
this,
and
maybe
this
just
isn't.
Maybe
what
we
we
have
appear
is
a
version
of
what
you'd
like
to
have.
I,
certainly
think
this
is
a
little
bit
better.
You
have
maybe
an
issue
a
bug.
It
features
some
kind
of
backlog
depending
on
your
process.
A
Again
it
gets
assigned
to
a
person,
but
after
it
gets
assigned
to
a
person,
we
see
that
first
commit
come
in
and
once
we
have
that
difference
of
code
we
have
people
able
to
start
opening
a
pull
request,
collaborating
on
their
changes.
Talking
back
and
forth,
hey
I
tried
this
approach.
Lauren,
do
you
know
of
another
approach?
I
can
work
on?
Oh,
maybe
we
should
talk
to
Tim.
Maybe
he's
got
ideas
because
he's
done
this
before
and
you
have
this
cycle
of
continuous
collaboration
and
then
continuous
deployment
to
go
test.
How
that
code
actually
looks.
A
A
Maybe
we'll
take
a
look
at
default
branches
with
protected
branches
here
in
a
little
bit,
and
maybe
you
also
then
do
another
depending
on
which
process
you
actually
have
kind
of
have
the
choice
to
do
that
here,
and
this
is
actually
a
generalization
of
how
github
itself
works,
the
the
core
team
at
github.
We
we
work
on
changes.
We
have
a
branch
that
we
work
on
them.
We
get
feedback
from
our
co-workers
and
we
deploy
that
branch
out
to
production.
We
see
how
it
is,
how
it
looks.
We
actually
monitor
Twitter
a
little
bit.
A
A
So
with
this
with
this
workflow,
we
have
I,
don't
know
if
anyone's
seen,
guides
github.com
just
a
few
people
and
see
if
you
attempted
to
raise
your
hands
a
little
bit
more.
What
about
you?
Have
engineering
comm,
maybe
one
that
people
seem
a
little
bit
more
proud
to
raise
our
hand
about.
So,
let's
take
a
little
bit
peek
at
both
of
those
I
love
guides.
A
I
worked
with
a
lot
of
the
early
people
who
put
together
our
guides,
and
the
one
I
like
in
particular
is
that
github
flow
guide
we
put
that
in
the
hello
world
guide
kind
of
at
the
very
top,
so
that
people
would
be
see.
Okay.
This
is
a
general
workflow
that
I
can
start
applying
to
my
company
and
here's
a
hello
world
guide
to
get
me
started
to
actually
work
with
some
of
these
changes.
A
A
A
Do
I
turn
it
on
its
side
and
see
all
these
different
branches
I,
don't
really
understand
how
I
didn't
understand
how
it
actually
used
that
to
be
effective
when
I
was
first
starting
software
development,
but
luckily,
with
the
github
flow,
one
thing
that
we
really
like
is
how
lightweight
it
is.
So
we
don't
force
anyone
workflow
with
this,
but
this
is
our
suggested
flow
with
this.
A
So
sorry,
this
is
what
we'll
be
working
towards
when
we
talk
about
pull
requests
and
when
we
talk
about
code
review,
we'll
talk
about
collaboration,
practices
we'll
be
working
towards
this
and
then,
as
I
mentioned,
the
get
up
engineering
blog.
This
is
one
of
the
post
up
there
that
I
particularly
love.
It's
a
mom
had
wrote,
I,
don't
know
it
says
back
at
June,
2nd.
A
He
wrote
this
blog
post
talking
about
how
we
actually
deploy
our
code
and
he
walked
through
the
whole
process.
Talking
about
it
and
when
he
talked
about
this,
he
actually
sent
a
pull
request
back
to
our
guides
page
to
add
in
this
little
extra
step
of
deployment,
because
we
we
work
a
little
bit
differently
than
just
a
basic
github
flow.
We
deploy
our
code
on
our
feature:
branch
out
to
production,
so
I'm
dropping
I'm
starting
to
drop
a
little
bit
more
and
more
terms,
pull
requests
branches
commits
deploys.
A
We
won't
talk
too
much
about
deploys,
but
let's
start
at
the
the
key
thing
of
collaboration
and
the
thing
that
I
think
changes
everyone
everyone's
lives
when
they
get
to
github
calm
when
they
first
see
their
first
project
that
oh
well,
this
was
a
really
complicated
project.
It's
developed
by
Facebook,
it's
using
Java
or
juicing,
go
I,
don't
understand
any
of
those
languages,
but
I
do
understand
this
documentation
piece
and
that
parts
wrong
and
I'd
like
to
collaborate
on
just
that
piece.
A
So
right
away,
one
of
the
first
early
things
we
can
do
to
send
a
pull
request
is
to
find
the
common
piece
within
their
code.
We
can
edit
for
me
a
lot
of
times
that
ends
up
just
being
a
simple
documentation.
Change
I,
keep
telling
myself
one
of
these
days,
I'm
going
to
send
a
pull
request
or
well
not
a
pull
request,
but
submit
a
patch
to
court,
get
to
fix
some
of
their
man
pages,
because
if
I
look
through
some
of
the
commands,
I
get
confused
myself.
A
Maybe
that
would
be
my
contribution
for
this
month,
so
pull
requests
themselves.
Work
on
some
change
propose
that
change
back
and
have
a
conversation
about
it.
Sometimes
people
tell
me
why
would
I
use
github
I
can
just
merge
changes
locally
and
I
can
just
push
directly
to
master
she'd.
Do
that?
There's
no
collaboration
in
that
and
you
don't
want
to
work
in
a
silo
you're
not
going
to
be
enriching
your
own
software
development
learning,
if
you're
working
by
yourself
without
anyone
else,
you're
not
getting
any
feedback
from
anyone.
A
You
can't
learn
from
their
experiences
if
you
haven't
talked
to
them
and
that
talking
and
that
collaboration
piece
is
one
of
the
most
important
pieces.
I
want
all
of
you
to
remember
by
the
end
of
this
talk.
So
if
I
forget
it
or
if
I
go
over
five
minutes
without
mentioning
collaboration,
just
raise
your
hand
or
yell
out
the
word
collaboration
to
me
and
we
can
Anna
I'll
just
yell
about
it
again.
A
So
again,
I
mentioned,
if
you
don't
know,
git
or
github
and
I'm
sure
some
of
you
do
inevitably
we're
at
I
get
up
a
conference,
but
maybe
you're,
not
a
software
developer.
Chris
mentioned
earlier.
We
have
11
million
developers,
developers
on
github
and
traditionally
they
there
were
studies.
That
said,
there's
only
20
million
in
the
world,
but
there's
so
many
people
nowadays
who
are
contributing
to
projects
on
github,
they're,
writing
in
markdown
they're,
finding
a
misspelling
and
some
documentation
I
would
count
them
as
developers
if
you're
just
working
on
it
as
a
hobby.
A
If
you've
went
to
a
rails,
girls
or
a
rails,
bridge
or
girl,
develop
it
or
any
of
those
great
community
organizations
out
there
helping
people
learn
to
code
your
developer.
So
what
is
a
pull
request?
Pull
request
start
with
a
branch
that
branch
itself
is
when
you
have
your
main
set
of
code,
so
in
this
case
we're
going
to
call
that
master
and
you
decide
you
find
a
bug
or
find
something
you'd
like
to
change.
A
You
work
on
a
different
branch,
we'll
call
that
a
feature
branch,
and
so
when
you,
when
you
branch
off
of
master
and
you
try
something
new
I,
often
relate
that
to
a
sandbox
environment.
You
have
the
full
history
of
all
the
code.
All
the
text
changes
all
the
files,
but
I
want
to
work
over
here.
Not
affect
what's
on
master
has
often
people
relate,
what's
on
master,
to
being
deployed
in
production.
I
want
to
mess
with
that,
and
I
want
to
try
something
new
out
and
I
want
to
practice
it.
A
So
you
have
your
branch.
You've
made
some
changes
and
you
push
that
change
up
to
github.
Then
github
will
actually
make
it
a
lot
easier
for
you
now,
once
you
have
that
branch
with
some
different
changes
on
it,
it'll
pop
open,
a
little
green
button
for
you
that
says,
compare
and
pull
requests,
and
you
can
just
get
started
right
from
there
once
you've
created
those
changes.
A
One
one
barrier
people
said
to
my
abstract:
I
talked
about
some
barriers.
People
have
to
pull
requests,
so
here's
one
of
the
first
ones
they
don't
understand
how
to
use
them.
That
seems
like
a
pretty
big
barrier
to
entry.
There's
some
tool,
I'm
told
to
use
and
I,
don't
know,
understand
how
it
works.
I'm,
not
gonna,
use
it
because
I
don't
feel
safe
using
it,
but
with
getting
with
github.
A
If
you
start
using
these
branches
and
you
send
pull
requests-
and
you
just
talk
to
your
your
co-workers,
your
friends,
your
prospective
teammates
and
collaborate
with
them
they're
in
its
collaboration
again,
you
can
actually
get
started
on
this.
So
instead
of
live
demoing.
Any
of
my
any
of
my
talk
here
today.
I
have
a
series
of
videos.
A
Test
test
test
test
check
check
one
one:
two
there
we
go
hey
welcome
back.
So
what
we're
gonna
talk
about
in
this,
this
short
little
30-second
to
a
minute,
clip
I
forget
how
long
this
particular
one
is
and
I'm
just
gonna
demonstrate
this
quick
pull
request
flow,
I'm,
gonna
I
have
a
markdown
document
here
called
markdown
practice
creatively
enough
and
in
this
actual
project
I
just
want
to
add
to
the
readme,
add
a
little
bit
of
markdown.
A
This
this
line
of
code
and
I
just
add
this
little
bit
of
markdown-
is
that
I'm
actually
gonna
be
sending
this
pull
request
to
myself
some
people,
often
when
they're
first
exposed
to
github
and
pull
requests,
is
they
send
their
pull
request
from
some
other
open-source
project
that
they
didn't
have
access
to
over
to
theirs?
So
I'm,
just
sending
this
to
myself.
A
Just
wait
for
this
to
finish
up.
There's
some
pieces
in
here:
I
have
sped
up
just
for
the
purposes
of
me
not
sitting
up
here
awkwardly
silent
in
this
actually
sending
myself.
A
pull
request
on
my
own
project
is
something
that
often
looks
strange
to
people.
Well,
what's
the
point
of
sending
myself
a
pull
request
if
I'm
not
working
with
anyone
else
well,
besides,
just
practicing
using
the
tool
and
practicing
for
when
I
do
work
with
other
people.
A
I
don't
know
that
this
project
will
always
remain
just
something
I
work
on
what
if
later
I
decide
that
I
want
to
practice
using
github
with
colleagues
at
work,
I'm
gonna,
do
a
quick,
Lunch
and
Learn
session
and
I
want
to
show
this
project
and
invite
them
to
work
on
it
and
use
pull
requests
with
me.
Well,
they
can
go
see
an
example
of
how
I
sent
myself
a
pull
request
and
some
collaboration
that
I
actually
did
even
with
myself.
I
always
send
a
pull
request
with
a
concise
title.
A
The
title
itself
I
often
relate
to
an
email
and
an
email
subject:
line
I
want
to
be
able
to
see
what
that
subject
line
is
and
know,
what's
gonna
be,
what's
gonna
come
when
I
open
that
up
and
then
I
always
comment
as
well
or
I,
try
to
as
much
as
I
can.
If
you
ever
find
me
opening
a
pull
request
somewhere
on
github
and
I.
A
Don't
have
a
message
in
that
first
opening
post
feel
free
to
comment
on
there
and
tell
me
otherwise
art
that
I
should
go
back
and
edit
it,
and
now
this
pull
request
lives
up
there
forever.
So
this
isn't
some
email
chain
or
some
conversation
that
happened
before
a
new
developers
started.
Someone
new
came
in
saw
this
piece
of
code
change
and
said
what
was
the
motivation
behind
this?
How
did
we
do
this?
Why
did
we
do
this
change?
A
A
So
that's
one
way
you
use
pull
requests,
but
how
do
you
use
them?
Well,
a
lot
of
people
here
already
know
how
to
use
pull
requests
so
I'm
pulling
you
through
this
and
I'm
getting
everyone
to
a
baseline
so
that
we
can
talk
about
how
to
use
them.
Well,
there's
actually
a
research
paper
that
I
found
and
friends
pointed
me
pointed
out
to
me
talking
about
some
pieces
of
a
pull
request
that
actually
allow
it
to
be
merged
faster
and
more
often,
especially
when
submitting
it
to
other
people.
A
So,
of
course
the
emphasis
here
is
mine,
but
the
two
things
I
want
to
I
want
to
look
at
here.
The
shorter
it
is
that
the
changes,
the
shorter
that
changes
are
the
faster
it
will
be
reviewed
and
I
think
we
can
all
agree
with
that
right.
If,
if
someone
submitted
something
to
me
and
said,
hey
I,
have
this
thousand
page
document
I
need
you
to
review
by
tomorrow.
I
need
you
to
find
every
little
change
that
happened.
A
Actually,
for
you,
that's
my
dream:
that's
what
I
would
like
and
then
the
the
second,
the
second
piece
of
that
is
going
to
be
that
CI
piece,
so
all
right,
little
Madge,
ination
experiment
here
and
close
your
eyes.
If
this
helps
you
but
imagine,
you're
at
your
office
and
and
you're
working
on
some
code
and
you
song
on
your
Kanban
board
or
some
issue
popped
up
in
a
bug,
tracker
and
you
say:
I'm
gonna-
go
work
on
this
I'm
gonna
create
a
pull
request.
A
I'm
gonna
create
some
commits
and
I'm
gonna
work
like
Brent
just
told
me
to
and
like
the
training
team
at
github
advises.
So
you
see
the
future
come
in.
You
start
working
on
it.
You
all
right,
your
laptop
you're
at
work
late,
you
maybe
go
home.
You
continue
to
work
at
it
and
you
spend
all
night
and
then
by
the
end
of
the
week,
or
maybe
at
the
after
a
few
days,
you
send
that
as
a
pull
request.
Yes,
I
did
it.
A
I
sent
my
first
pull
request,
or
this
is
my
15th
pull
request,
but
you
realized
someone
beat
you
to
it.
Maybe
Rachel
beat
you
to
it,
because
she
had
that
one
little
change
to
start
discussing.
Maybe
she
just
edited
some
some
text
somewhere
for
the
documentation,
change
and
then
started
building
the
feature
she
opened,
that
pull
request
right
away
and
that's
another
big
barrier.
People
have
to
sending
poor
request.
Well,
not
quite
ready
with
this
change.
Yet
they're
gonna
judge
me
on
the
way
this
looks
and
they
may
but
you're
gonna
be
better
at
it.
A
They
shouldn't
judge
you
harshly.
They
should
be
there
to
help.
You
write
your
code
better,
so
Rachel
starts
her
pull
request.
She
brings
in
Lynn
and
she
brings
in
Sam
and
she
brings
in
Matt
whoever
it
may
be
and
they
talked
to
her.
They
used
app
mentions,
they're,
collaborating
and
talking
to
each
other
about.
This
is
wrong
over
here.
I
would
change
this.
A
This
is
in
our
code
style
and
they
actually
improve
the
quality
of
code
for
not
only
that
developer
Rachel
in
this
case
or
every
single
developer
who
comes
in
after
this
maybe
Rachel
ends
up
being
a
manager
and
a
new
person
comes
on
board
is
a
little
nervous
about
sending
pull
requests
as
well.
She
can
look
back
and
say
here's
my
first
full
request.
I
got
a
lot
of
help
and
this
is
how
we
should
work.
A
A
Maybe
someone
suggests
you
make
a
change
and
now
tests
pass,
but
someone
else
suggested
you
make
another
change,
and
now
you
see
it
fail
again.
So
having
CI
run
automatically
was
one
of
the
main
parts
of
this
research
paper.
It
said
as
a
software
developer
is
accepting
pull
requests.
You
have
many
other
factors
and
they
mentioned
how
complicated
could
be.
It
could
be
an
open-source
maintainer
but
also
have
their
day
job.
So
they
only
look
at
those
pull
requests
when
they
get
home
at
about
5:00
or
6:00
p.m.
maybe
they
have
a
family.
A
Allow
you
to
actually
run
those
tests
right
away
now,
of
course,
this
allows
us
to,
or
we
had
to
have
kind
of
a
testing
first
thought
process
here
and
that's
a
that's
an
important
one
to
have
and
you'll
have
to
start
implementing
that
as
well
and
earlier
Chris
talked
about
our
integrations
directory,
so
announced
this
morning.
We
have
many
partners
who
we
can
just
plug
and
play
into
github
for
CI.
In
this
paper
they
talked
about
Travis
CI.
A
We're
gonna
talk
about
opening
a
pull
request
and
we're
going
to
see
how
do
you
just
quickly
add
Travis
to
it
so
that
it
runs
the
tests
that
are
already
inside
this
application.
This
is
just
a
real
quick
example:
Ruby
application.
It
just
has
some
simple
tests
to
it,
but
I
wanted
to
show
a
little
bit
of
what
that
looks
like
so
on
my
repository,
I
start
out
and
I
just
go
over
to
my
web
hooks
and
services.
Page
I
could
have
gone
directly
to
the
integrations
directory
and
added
that
project
as
well.
A
Then,
once
on
github
are
sorry
once
on.
Travis
I
can
actually
just
enable
the
CI
for
that
particular
repository
and
then,
when
I
go
and
actually
build
my
features,
which
I
speed
through
here
a
little
bit,
adding
an
additional
test,
of
course,
copy
and
pasting
that
in
to
see
that
that
test,
fails.
I
can
actually
see
how
the
CI
actually
runs
on
this.
A
So
the
important
part
is
I'm,
adding
a
little
test
in
there
and
I
open
my
pull
request
and
then
we'll
see
the
test
start
running
on
Travis's
infrastructure,
we'll
see
one
fails
and
then
the
next
one
fails.
But
let's
go
see
the
details
of
this.
You
start
having
people
able
to
dive
into.
Where
is
this
test?
Actually
failing?
I,
don't
have
to
actually
go
look
at
it,
myself
run
it
locally
and
comment
to
them.
I
can
link
them
to
the
Travis,
build
status
and
see
that
hey
this
failed
on
line
number
17.
A
So
I
had
this
little
variable
in
just
so
that
test
passes
kind
of
test
first
or
test-driven
development
there
I
make
that
commit,
and
once
I
commit
back
to
that
branch
and
revisit
that
pull
request
will
see
the
CI
status.
Now
kick
back
off
again,
so
you
have
a
failed
test
at
first
and
now
you
have
a
bunch
of
pending
tests
as
those
that
build
the
event
kicks
off
and
goes
over
to
Travis.
A
Now,
of
course,
I
am
actually
able
to
merge
the
pull
request.
Even
when
those
tests
are
running
or
failing,
which
we'll
look
at
here
in
just
a
minute,
so
my
test
pass
everyone
looking
back
at
this
in
the
future
or
actually,
if
you
wanted
to
go
visit
this
project
right
now,
you
could
actually
go
look
at
that
and
this
PR
is
there
just
don't
look
at
the
timestamps
of
when
this
actually
happened.
It
was
last
night.
A
Cool,
so
that's
pull
request,
so,
in
summary,
use
pull,
requests
right.
That's
a
big
piece
that
I'm
kind
of
trying
to
hammer
home
here
and
open
those
pull
requests
early.
Don't
wait
until
you
think
your
feature
is
complete,
because
what?
If
someone
else
beats
you
to
the
punch,
use
the
pull
request
right
away
so
you'd
have
something
to
talk
about
I'll,
often
open
a
pull
request
just
by
changing
documentation
or
I,
don't
want
to
just
change
whitespace
and
then,
instead
of
a
pull
request,
but
change
something
to
talk
about
and
then
send
the
pull
request.
A
A
Raise
your
hand
if
you
love
meetings,
great
couple
people
a
couple.
People
seem
to
love
meetings.
Well,
we'll
meet
after
this
to
talk
about
it,
but
I,
don't
know
too
many
developers
who
can
tell
me,
with
a
straight
face
that
they
would
rather
spend
their
time
in
a
meeting
than
actually
shipping
code.
What
are
you
doing
at
a
company
if
not
to
change
the
software
or
make
the
software
better
make
someone's
lives
better?
A
So
some
say
that
if
tests
are
failing,
you
shouldn't
be
able
to
merge
it
into
production
and-
and
there
should
be
a
gated
check-in
for
that
we
shouldn't
be
able
to
actually
merge
it,
and
that's
that's
fine.
That
is
one
way
of
code
review,
but
I
think
it
should
be
more
than
that
and
I
think
you're
done
of
all
humans,
and
if
you
can
guess
the
c-word
I'm
about
to
use
collaboration,
so
Jeff
Atwood
has
done
many
great
things,
including
being
the
co-founder
of
Stack,
Overflow
and
I.
A
In
fact,
if
you
use
atom
as
a
text,
editor
I
think
there's
a
package
that
allows
you
to
do
a
pop
up
type
in
Stack
Overflow
and
copy
to
your
clipboard
from
there
and
paste
the
code
right
in
so
we're
making
it
easier
to
share
and
collaborate
our
code
secrets,
I,
guess
on
and
co-working
there
so,
but
he
has
a
point
here:
peer
reviews
are
important
and
I'm,
not
saying
don't
do
reviews
when
I
start
talking
about.
Oh,
you
have
your
deployments
and
your
work
over
here
and
you
have
your
your
code
review
over
here.
A
All
I'm
saying
is:
don't
split
them
up
too
much
peer
review
is
important,
so
I
gotta
really
stop
doing
that.
So
peer
review
is
important
and
how
you
do
it
is
important
and
I
think
you
should
be
talking
to
your
co-workers
to
actually
do
peer
review
at
github.
This
is
how
we
do
it.
There's
a
pull
request.
Open
I
am
mention
the
appropriate
team
members
I
bring
people
into
the
discussion
and
they'll
actually
look
at
my
code
and
they'll,
say:
they'll
use
the
+1,
emoji
and
say
yep.
That
looks
good.
A
That
looks
good
or
that
looks
great,
go
ahead
and
merge
that
in
to
into
production
or
go
ahead
and
deploy
that,
and
they
usually
help
out
with
that
as
well,
and
so
here
I'm
just
going
to
open
a
pull
request
and
our
developer
reaches
out
to
the
github
teacher
account
so
again,
if
you've
ever
been
in
any
of
this
training
classes
or
may
be
familiar
with
the
teacher
account
here.
The
teachers
actually
commented
already
and
just
thanked
us
for
this
comment
for
this
method.
A
Something
really
simple
and
all
I'm
doing
is
talking
back
to
that
person,
letting
them
know.
Hey
I've
seen
your
comment
that
looks
great
I'm,
glad
you're
talking
to
me,
I,
don't
want
to
leave
you
hanging
so
I'm
just
gonna
say
this
looks
good.
Thank
you
for
reviewing
I'm
gonna
go
ahead
and
merge
this
now
I'll
go
ahead
and
merge
that
pull
request
and
clean
up
our
branches,
of
course
afterwards,
by
deleting
the
branch.
A
But
that's
really
easy
for
me
to
say
we
have
a
deep
entrenched
culture
of
don't
merge
without
anyone
reviewing
your
work
and
if
you
do,
we
kind
of
talk
to
you
and
we
get
better
at
it.
But
people
want
stronger,
see.
I
are
sorry,
then,
what
stronger
code
review
and-
and
luckily
we
came
out
with
protected
branches
just
a
short
time
ago.
How
convenient
for
this
talk
so
protected
branches?
Allow
you
to
pick
a
branch
within
your
repository
and
say:
I.
Don't
want
anyone
to
force
push
this
branch.
A
I
didn't
want
anyone
to
accidentally
delete
this
branch.
I
don't
want
anyone
to
accidentally
commit
on
the
web
side
and
in
case
instead
of
sending
a
pull
request
and
I
also
need
these
tests,
or
these
required
status
checks
to
pass
before
I.
Actually,
this
code
in
the
other
thing
that's
nice
for
me,
is
maybe
I
don't
want
to
use
a
CI
service,
or
maybe
there's
not
a
tool
out
there.
That
allows
me
to
do
more
rigorous
code
review
using
our
API.
A
You
can
actually
report
back
the
commit
status
to
fail
the
test,
so
maybe
you're
you're
into
using
the
API,
and
you
want
to
write
something
else
up
on
your
own.
You
could
actually
build
a
web
hook
on
top
of
your
repository
to
receive
some
of
that
data.
Next
time
someone
pushes
code
parse
through
all
the
comments
on
the
pull
request.
If
you
don't
see
any
+1
emojis
attached
of
failing
status
to
that
commit
then
inside
protected
branches.
A
You
could
say
this
is
one
of
the
things
that
is
required
to
pass,
and
that
sounds
great
and
I
would
have
loved
to
build
it
before
this,
but
I
didn't.
There
is
a
tool
that
an
open-source
tool
actually
there's
an
open-source
tool
out
there.
That
actually
allows
me
to
do
this
for
me.
So
we'll
take
a
look
at
that
in
a
bit,
but
first,
let's
actually
set
up
protected
branches.
So
any
repository
that
you
have
admin
access
over,
you
can
actually
go
over
to
these
settings
and
then
branches
tab
once
there
to
enable
protected
branches.
A
Now,
for
me,
I
care
about
protecting
master
and
I
need
status,
checks
to
pass
and
also
that
important
piece
right
there.
The
include
administrators,
because
I'm,
not
special
I,
don't
need
to
jump
through
I'm,
not
getting
around
this
topic
at
all.
I
don't
want
to
skip
the
required
status
checks,
so
we
need
to
make
sure
that's
added
and,
of
course,
I
sort
of
used
Travis
previously
that
popped
up
there
and
I
can
add
that
so
protected
branches
required
status
checks
as
easy
as
clicking
a
couple
checkboxes
on
your
project.
A
Once
you
have
CI
or
some
other
tool
integrated
but
I.
What
if
I
want
sign-off
right,
I
kind
of
mentioned,
building
that
with
CI
or
rather
building
out
with
the
API
and
I?
Don't
actually
want
to
do
that.
There's
a
really
nice
open-source
tool
that
I've
been
familiar
with
or
seen
for,
awhile
and
recently
integrated
into
project
a
couple
days
ago
and
actually
set
up
myself
well
I
kind
of
set
it
up.
There's
a
really
nice
deploy
to
Heroku.
A
A
Free
I
can
set
some
variables
and
have
that
running
for
myself
up
in
Heroku,
so
I
don't
actually
have
to
worry
about
taking
this
open-source
code
running
it
on
AWS
and
again
I
just
kind
of
wanted
to
do
a
quick
shout
out
if
this
is
something
you're
interested
in
looking
at
it's
at
github
comm,
/
review,
ninja,
slash,
reviewed
ninja
or
reviewed
ninja
just
on
the
Internet.
So
let's
connect
review
ninja
with
an
instance
that
I
already
have
running
on
Heroku.
A
So
all
I'm
gonna
do
is
visit
that
URL
that
I
have
running
sign
in
with
my
account
as
the
github
developer,
there
authorize
the
application.
That's
the
same
flow
you'll
see
if
you
start
using
any
of
those
integrations
that
we
have
out
there
as
well
and
once
I'm
signed
in
I
can
select
my
repository.
That
I
actually
want
to
start
using
code
review
for
and
again
looking
on
that
page
there
we'll
see
that
there's
no
pull
requests.
Currently
open
so
now,
let's
actually
look
at
opening
a
pull
request
and
make
sure
review.
A
Ninja
is
going
to
be
turned
on
for
that
protected
statuses.
So
we
see
that
pull
request
open.
We
see
required
on
Travis,
but
not
review
ninja,
so
I'm
gonna
go
into
my
settings
and
just
enable
that
just
a
simple
check
box
once
that's
connected
to
my
repository
refreshing
this
page,
so
it
says
that
that's
now
required
and
my
merge
button
has
been
disabled
so
from
here
on
out
every
single,
every
single
pull
request.
A
Turn
of
this
project
needs
review,
ninja
and
more
specifically
in
review
ninja,
which
we'll
see
in
a
moment
not
only
do
I
not
only
can
I
configure
how
many
people
need
to
give
it
a
ninja
star
or
for
the
better
or
worse,
a
+1
to
merge.
It
there's
also
a
number
of
things
inside
review,
ninja
to
mark
something
as
needing
to
be
reviewed,
or
you
need
to
fix
this
problem
that
will
also
fail
on
the
status
check,
which
I
think
is
quite
nice,
so
the
PR
has
been
open.
A
Excuse
me,
the
pier
has
been
open
and
that
teacher
can
now
actually
go
to
that
pull
request
and
rather
review
that
the
review
ninja
and
they
can.
They
can
find
the
pull
request
and
comment
on
it
maybe
find
if
there's
any
bugs.
We
see
here
that
the
markdown
for
the
teacher's
name
is
improper,
so
the
teachers
just
going
to
comment
and
say
that's
not
actually
the
link
to
my
account.
You
should
fix
this
before
you
merge
it.
A
A
This
comment
actually
appears
in
line
on
github.
So
if
your
developers
just
live
in
github
and
your
project
managers
or
your
QA
team
lives
and
review
ninja,
you
can
kind
of
the
communication
and
like
talking
between
the
two,
is
across
the
board.
So
that
comment
goes
through,
and
so
now
the
student
can
go
back
and
actually
edit
that
go
into
that
line
specifically
make
that
change.
Review.
Ninja
can
also
be
enabled
to
send
notifications
out
to
people
for
when
something
is
needing
to
be
reviewed
or
resolved
and
fixed.
A
So
the
student
comes
in
fixes
that
goes
back
to
review.
Ninja
changes
that
drop
down
to
say,
yep.
This
has
been
fixed,
that's
been
resolved,
so
we
we
see
on
that
required
status
check.
It
doesn't
say
that
there's
any
issues
for
a
review
ninja
now
and
then
this
important
part.
Yes,
there
may
be
an
email
that
goes
out
to
the
teacher,
but
you
should
talk
to
them.
Let
them
know
that
you
actually
did
this
change.
A
Don't
just
expect
them
to
receive
an
email
talk
to
them
in
github
to
actually
notify
them
of
this
change
and,
of
course,
kind
of
close.
This
this
little
piece
out
will
see
the
teacher
updates
the
student
and
tells
them
to
go
ahead
and
merge
this
change.
We
see
that
merge
button
on
review,
ninjas
actually
green.
Now,
because
not
only
see
I
passing,
they
gave
the
star
and
there's
no
resolvable
comments
left
and
the
teacher
will
just
speak
back
to
and
collaborate
back
with
the
developer,
letting
them
know
hey
cool.
That's
great.
A
Thank
you
for
talking
to
me
I'm,
going
to
just
message.
You
back
I
got
a
bug
trying
to
hit
enter
there,
so
that
looks
great,
and
the
student
then
could
are
that
starting
up
the
student,
the
developer
could
then
go
and
merge
the
pull
request,
all
right.
So
what
have
we
learned?
We
got
a
couple
things
code
review
being
a
big
piece
of
what
I
just
discussed.
A
There's
no
one
way
to
do
code
review.
If
you
have
no
code
review,
do
something
enable
a
culture
within
your
company
of
talking
to
each
other
on
these
pull
requests,
bringing
people
into
the
discussion
asking
them
to
review
your
work,
I
realize
two
people
could
kind
of
buddy
up
and
cheat
and
just
say:
oh
I'll
always
review
your
work.
You
always
review
mine,
but
if
you
see
that
happening
talk
to
them
about
it,
build
a
better
culture.
A
So
all
this
coming
down
to
the
conclusion
of
what
is
the
github
flow?
So,
as
I
mentioned
in
the
very
beginning
with
that
that
picture,
the
get'em
flow
I'm,
not
gonna,
read
the
whole
slide,
but
it
allows
us
to
work
and
be
flexible
with
the
actual
code
review
or
pull
request
or
workflow
in
general
that
we
want
to
use
the
reason
why
we
teach
it
within
getup
services.
Is
we
want
people
to
have
a
great
baseline?
They
want
to
plug
something
into
it.
A
They
can
do
so
so
code
review
and
talking
to
your
team,
assuming
it
the
things
that
work
best
for
you
and
ensuring
this
developer
czar
running
good
quality
code.
Some
people
say
well,
man
we're
doing
these
code
review
check-ins
now
and
people
have
to
+1
their
code,
it's
taking
too
long.
Well,
the
quality
of
the
what
they
write
will
actually
start
to
improve
things.
A
Will
speed
up
a
lot
faster
I've
seen
it
I'm
sure
you've
all
seen
it
as
well,
and
there
used
to
be
this
philosophy
that
I
heard
other
development
companies
or
such
as
software
departments
at
companies
say,
move
fast
and
break
things.
I
think
actually
Facebook
originally
said
that
I
think
I
saw
in
the
news
recently.
They
said
that's
not
their
motto
anymore,
but
I
like
that
idea.
So
if
traditionally,
your
customers
are
used
to
something
coming
out
every
four
to
eight
weeks.
Well,
what
happens
if
there's
a
bug
that
was
introduced
when
they
released
it?
A
Do
they
have
to
wait
four
to
eight
weeks
to
get
a
fix
on
that?
How
many
people
are
being
affected
by
that
bug?
Is
that
40,000
people?
That's
had
a
million
people
I,
don't
know
how
many
people
have
downloaded
certain
iOS
apps,
but
that's
a
lot
of
people
you
could
be
affecting.
Why
don't
you
get
that
code
out
faster
sure?
Maybe
there's
a
bug
introduced
and
maybe
now
you
need
to
do
a
retrospective
on
that
that
code
that
it
got
introduced?
Talk
to
that
developer
find
out
how
to
make
that
better.
A
But
what,
if
you
could
make
that
fix,
not
take
8
weeks
what,
if
it
took
2
days?
What
if
it
just
took
a
week,
could
you
cut
in
half
the
number
of
people
that
were
actually
affected
by
that
bug?
That'd
be
it'd,
be
quite
an
improvement.
So
maybe
you
have
something
like
this,
where
your
developers
meetings
are,
unfortunately
not
coming
through
very
clearly
but
I'll
post.
These
slides,
you
can
all
see
this
on
the
left
side
or
current.
A
You
have
a
lot
of
calendar
invites
or
a
lot
of
meetings
inside
your
calendar,
your
developers
not
spending
a
lot
of
time
coding.
You
want
them
spending
more
time
coding
so
that
they
can
actually
ship
their
software,
so
they
can
make
changes
and
actually
iterate
on
what
they're
doing
we
don't
want
them
to
actually
be
spending
time
doing
that
we
should
have
that
code
review
happening
instantly
right
when
that
pull
request
is
open.
That
should
be
part
of
your
development
cycle.
A
I
wanted
to
focus
on
the
collaboration
piece
of
this
to
actually
let
us
build
that
culture
to
then
prep
us
to
be
in
a
perfect
position
to
decide
how
we're
going
to
deploy,
and
if
you
want
to
work
a
little
bit
more
on
deploying
you
can
go
to
the
deploy
section
of
our
integrations
page
pick
from
any
number
of
these
providers
to
actually
pick
the
solution.
That's
best
for
you,
so
some
people
say
pull
requests
slow
down
their
development
flow.
Well,
I
just
want
to
commit
to
master.
A
Take
too
long,
I
don't
want
to
spend
time
doing
code
review
well,
you'll
become
a
better
developer,
as
you
do
code
review
in
one
form
or
another,
and
talk
to
your
colleagues
and
work
with
them,
and
then
lastly,
I
wanted
to
show
this
one
more
time
to
talk
about
these
steps
create
that
branch
start
making
some
work
create
a
pull
request,
talk
to
your
colleagues
and
that
collaboration
piece
after
the
pull
request.
Is
there
right
before
that
ship?
A
A
Is
there
another
set
of
eyes
looking
at
this
problem
from
a
different
way,
work
on
that
and
so,
lastly,
kind
of
with
the
github
flow
using
pull
requests
talking
to
your
teammates,
making
sure
the
code
is
well
tested,
well,
reviewed
everyone's
gonna
start
becoming
better
and,
as
JFK
I
believe
said,
a
rising
tide
lifts
all
ships
so
raise
the
quality
of
code
written
at
your
company
work
better
with
your
co-workers
work
better
with
the
open-source
community
just
make
everyone
better.
Thank
you.
A
And
just
a
quick
note
if
you'd
like
to
send
up
for
some
github
services,
kind
of
one-on-one
sessions
or
some
sit-down
sessions
with
them
right
in
front
of
the
build
stage,
the
get
up
services
team
is
sitting
there.
They
have
a
lot
of
open
slots
to
sign
up
with
take
a
look
at
that
sign
out
talk
to
them.
Maybe
do
it
over
lunch
or
whatever
is
most
convenient
for
you.
If
you
do
want
to
have
a
meeting
with
me
outside
this,
this
session,
I'll
be
around.