►
From YouTube: The GitHub Flow - GitHub Universe 2016
Description
Join Matt Desmond and Eric Hollenberry, trainers at GitHub, for a discussion on pull requests and the GitHub Flow.
If pull requests are 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. We'll start out by looking at what makes a great pull request, and what barriers people have with sending and receiving them. Next, we'll remove some of those barriers by discussing some code review best practices to ensure the code we're writing is well written and well tested. Lastly, we'll see how and why these pieces are a crucial part of a proper workflow, and what advantages the GitHub Flow has.
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
Let's
get
started,
my
name
is
Eric.
This
is
Matt,
we're
both
trainers
at
github
and
that's
about
the
most
interesting
thing
about
us.
So
we'll
just
skip
that
and
get
started.
How
many
of
you
are
coming
to
the
stock
with
a
good
grasp
of
git
and
github
concepts.
Raise
your
hand
if
so,
okay,
okay,
so
if
we
pretend
half
of
you
didn't
raise
your
hands,
then
we're
perfect
when
I
say
that
when
I
say
have
a
good
grasp,
it's
kind
of
hard
to
tether,
so
I
want
to
actually
ask
you
a
question
with
a
picture.
A
This
is
one
of
our
shirts
and
people.
Wear
it
and
I'm
like
eh.
Do
you
know
it
nope,
that's
fine!
Okay!
So
if
you
walked
in
today
and
you
registered
at
the
booth,
you
saw
these
actually
on
the
ground,
and
since
this
is
a
universe,
I'm
sure
that
some
of
you
probably
thought
oh
cool,
like
alien
science.
These
are
great.
They
say
it
has
to
do
with
our
theme.
It
has
to
do
with
universe.
A
I
know,
I
thought
that,
because
I
saw
this
fit,
I
actually
ran
out
and
took
this
picture
just
now
and
I'm,
just
like
wow
Pacman's
having
a
bad
day
today.
Aliens
I
actually
did
another
fun
story.
With
this
before
I
came
in
here
and
made
that
joke
I
was
like
wait.
Is
this
a
startup
because
I
don't
want
to
offend
anybody,
and
that
looks
like
a
very
startup
II
image
right
there?
A
So
we're
actually
going
to
be
talking
about
these
things
through
today,
so
there
were
more
hesitant
hands
that
went
up
and
we
want
at
the
end
of
this
talk
when
we
show
this
image
again,
we
want
everyone's
hands
to
go
up
because
they
understand
what
this
is,
what
each
symbol
means
and
they
have
a
deeper
understanding
of
of
all
of
those
items.
So
that's
our
goal,
that's
what
we're
tethering
to
before
that
some
expectations.
A
Let's
talk
about
where
you're
at
regardless
of
your
proficiency
level.
No,
this
Matt
myself
and
all
of
the
trainers
for
github
go
to
every
single
client
site
that
we
teach
enterprise
to
and
we
start
with
the
github
flow.
The
github
flow
is,
oh,
I
wrote
this
down.
This
is
a
very
good
sentence.
It
is
the
simplest
combination
of
git
and
github
that
exists,
while
still
creating
a
robust
workflow
for
your
teams,
and
that's
that's
why
we
do
it.
We
always
start
with
this,
because
it
is
the
simplest
way
for
people
to
start
coding.
A
So
where
are
we
going
disclaimer?
That
said,
this
workflow
might
not
be
the
one
that
your
team
follows.
A
development
workflow
might
use
something
like
git
flow
or
whatever
your
team's
use.
So
we're
not
going
to
be
advising
you
specifically
on
how
to
change
your
whole
workflow
and
go
back
to
your
team
and
be
that
person
who
went
to
that
thing
last
week.
A
Who
has
ideas
because
that
happens,
but
your
team
might
have
your
own
flows
so
wherever
you
go,
we
just
want
you
to
have
a
deeper
grasp
of
all
of
these
items
that
are
incorporated
into
each
of
those
things.
If
you
do
have
questions
about
specific
flows,
we
haven't
asked
services
booth,
that
you
can
go
to
set
an
appointment
for
free
and
have
very
in-depth
conversations
about
your
team
and
where
they're
at
so,
let's
get
started.
A
If
you
were
a
training
day
yesterday,
you
know
I
love
metaphors,
so
obviously
I'm
gonna
start
with
a
metaphor,
but
that'll
be
the
first
thing
we
do.
Then
matt
is
gonna,
come
up
and
he's
gonna
go
in-depth
on
everything.
So
I'm
gonna
give
you
the
overview
here.
Matt's
gonna
go
in
detail
and
then
at
the
end
we're
gonna
have
time
for
your
questions
and
if
you
have
questions
that
you
don't
want
to
ask
here,
we'll
have
another
hour,
I
believe
between
1:00
and
2:00
over
at
the
speaker
office
hours
area.
A
This
isn't
gonna
be
tied
to
code,
yet
so,
if
you're
like,
why
is
he
talking
about
restaurants?
I'll
get
there
trust
me.
Let's
follow
along
okay,
so
I
own,
a
restaurant
start
imagining
that
I
own
a
restaurant
and
it's
awesome.
It
has
all
the
best
food,
whatever
your
favorite
is
I.
Have
it
good
drinks,
whatever
everything
that
I'm
doing
is
perfect
and
Matt
is
my
friend
and
he
comes
to
me
and
to
bring
this
the
github
terms.
We
open
an
issue
to
start
a
discussion
and
he
says
to
me:
hey
your
restaurants.
A
Awesome
I
would
like
to
also
do
the
same
exact
thing
as
you
eventually,
I'm
gonna
won't
want
to
make
changes,
but
to
start
I
want
to
do
the
exact
same
thing
that
you're
doing
I'm
like
okay.
Let's
try
that,
let's
see
how
that
works,
let's
see
how
that
happens.
So
he
makes
his
own
branch,
but
then
he
starts
getting
ideas.
He
gets
really
ambitious.
He's
like
okay,
so
I
had
this
copy
of
your
restaurant
and
everybody
loves
it,
but
we
can
make
it
better.
A
So
he
creates
this
idea
of
burger
of
the
day
and
on
Monday
he
releases
a
new
burger
and
he
tests
it
out.
He
tries
to
see
how
it's
gonna
work
with
this
with
his
clients
and
how
it
can
be
deployed.
He
does
another
one
because
he's
getting
really
excited
he's
he's
got
good
ideas.
They're
taking
off
everybody
likes
the
burgers
of
the
day.
He
does
two
at
once.
He
does
two
burgers
in
one
day:
it's
nobody
does
that
he's
a
transcending.
A
Then
we
start
a
discussion
about
it.
So
he
comes
to
me
and
he
says:
okay,
everybody
loved
this
burger
and
this
burger
and
this
burger,
but
maybe
not
this
burger.
So
what
do
you
think
about
that?
What
do
you
think
about
these
changes
that
I
have
made?
Meanwhile,
we
observe
my
restaurant
is
unchanged:
I've
done
nothing
new
we're
just
working
as
we
always
have
with
no
changes,
I'm,
not
trying
anything
ambitious
at
my
restaurant
I'm,
letting
that
be
my
guinea
pig.
A
So
we
have
that
discussion
and
I
say:
okay,
I,
like
this
burger
I
didn't
like
this
burger.
Let's
add
another
one:
let's
do
these
things
and
then
I
bring
it
back,
and
this
is
where
the
for
dice,
because
Matt
did
a
great
job,
and
now
your
restaurants,
dead
and
mines
gonna
continue
with
all
your
changes
excellent.
A
So
we
continue
on
and
now
his
restaurants,
ideas
are
part
of
my
restaurant
and
his
doesn't
exist.
So
let's
bring
that
back.
Let's
apply
the
actual
terms
that
we
use
to
that,
and
let's
look
at
those
images
so
that
when
you
see
that
picture
at
the
end,
you
know
what
they
are.
You
know
what
they
relate
to.
So
the
first
thing
we
did
and
I
said
this
verbally
was
we
opened
an
issue
and
that's
just
our
workflow
on
at
github
everything
we
do.
A
We
actually
communicate
through
issues
and
pull
requests,
but
then
we
created
a
branch
so
that
item
on
the
left,
that
little
branch
II
flow
thing
is
creating
a
branch
we
started
with
that.
Then
we
added
changes.
We
added
commits
so
every
burger
that
he
added
every
new
idea
was
a
commit
and
that's
what
that
symbol
means.
A
We
have
those
we
have
that
communication,
which
is
that
middle
symbol.
We
open
that
pull
request
and
then
we
go
and
we
discuss,
we
go
back
and
forth.
We
communicate
about
the
changes
that
we've
made.
We
make
new
commits,
we
make
more
discussions.
Sometimes
it
takes
a
while
for
your
items
to
be
merged
because
everybody's
coming
in
and
it's
actually
really
awesome,
because
so
many
opinions
can
be
met
and
and
discussed.
A
A
These
ideas
can
feel
kind
of
daunting,
especially
if
you're
newer
to
this,
but
it
is
all
based
on
the
extension
of
the
idea
that
you
are
making
branches
where
you
can
test
things
in
a
safe
place
where
you
are
starting
discussions
and
where
you
are
eventually
merging
those
items
back.
It
is
a
place
where
you
can
make
mistakes
in
a
nice
easy
convenient
way,
and
it
doesn't
hurt
to
you
later
so.
Matt
is
gonna.
Go
in
detail
on
all
of
that,
starting
with
the
two-stage
commit.
B
There
we
go
alright,
so
so
we
just
kind
of
covered
the
quick
workflow.
So
now,
I'm
gonna
talk
about
what
we're
doing
when
we're
doing
when
we're
working
locally
and
we're
gonna
start
by
talking
about
the
two-stage
commit
and
the
different
say,
working
areas
that
you
have.
Unfortunately,
the
first
part
is
actually
called
the
working
directory.
So
it's
kind
of
difficult
to
say
like
this
is
how
you
work,
but
here's
the
working
directory.
B
B
So
in
this
example,
we're
gonna
use
git,
add
to
add
a
couple
of
files
to
our
staging
area,
so
using
some
keynote
magic,
we're
gonna,
move
some
things
over
and
so
using
git.
Add
we've
add
these
three
files
to
the
staging
area
and
from
there.
What
we're
able
to
do
is
kind
of
identify,
okay,
I'm
kind
of
ready
to
commit
these
to
my
repository
as
a
change.
Maybe
you've
made
some
modifications
to
a
website,
so
your
HTML
with
CSS
file
or
I'll,
pretend
like
I
code.
B
So
you
made
some
changes
to
your
Ruby
project
and
now
you've
staged
it
right.
That's
terms
so
now
that
we've
staged
it,
we
can
say:
okay,
like
we,
we
like
the
files
that
we've
modeled
or
that
we
modified
and
that
we've
added
to
our
staging
area,
but
one
of
the
files
that
we
changed
isn't
necessarily
ready
and
we
can
actually
remove
that
from
the
staging
area
and
send
it
back
to
our
working
directory
so
that
when
we
make
our
commits
it's
not
submitted
to
our
history.
B
But
when
we're
making
commits,
we
have
to
make
commit
messages.
So
just
like
every
Tech
Talk,
there's,
always
an
xkcd
that
kind
of
works
and
relates
to
what
we're
talking
about
so
I
found
this
one,
and
this
is
where,
as
you're
making
a
bunch
of
changes
to
your
project,
your
commit
messages
probably
start
to
get
really
really
bad
because
you're,
just
tired
of
explaining
what
you're
doing
I'm
notorious
for
bad
commit
messages.
B
So
it's,
it
is
what
it
is,
but
I'm
I
typically
actually
start
at
the
here,
have
code
and
down
I,
don't
even
bother
with
the
first
stuff.
That
being
said,
there
are
some
suggestions
on
making
commit
messages
that
aren't
terrible.
It's
online
Chris
beams
made
it
it's
not
necessarily
rules
that
you
live
or
die
by,
but
it's
definitely
it
definitely
gives
you
some
ideas
for
how
to
make
commit
messages
that
are
much
better
than
what
you're
probably
already
doing,
and
he
definitely
defines
some
of
the
things
that
like
why
you
need
to
do
certain
things.
B
B
Don't
use
your
subject
line
as
the
end-all
be-all
way
to
describe
the
change
that
you've
made
kind
of
treatment
messages
like
an
email,
you
have
a
subject
and
you
have
a
body.
You
use
your
body
to
really
describe
and
go
into
detail.
Why
you
made
this
change.
You
don't
necessarily
have
to
go
into
what
you
changed
unless
it
it's
going
to
be
beneficial
later
down
the
line,
but
the.
B
If
you
can
finish
the
sentence,
adding
this
commit
will
blank.
That's
that
blank
is
what
your
commit
message
should
be
saying.
Things
like
fixed
fix,
the
index.html
file.
Isn't
necessarily
what
you
need
to
say.
You
know.
Adding
this
commit
will
fix
the
HTML
file.
It
just
makes
it
easier
to
read.
He
definitely
goes
into
the
the
nitty-gritty
details
of
it
makes
for
a
much
cleaner,
commit
history,
especially
when
you
start
looking
at
something.
B
That's
a
lot
longer
moving
from
commit
messages,
so
we've
made
some
commits
right
and
now
we
have
to
make
a
pull
request
and
when
we
make
a
pull
request,
we
kind
of
have
to
follow
the
same
ideas
behind
your
commit
messages,
so
I'm
going
to
show
you
a
pull
request
that
I
made
two
months
ago.
So
this
is
me
this
is
real.
I
made
this
in
July.
B
This
was
a
PR
that
I
made.
So
this
was
terrible.
My
commit
message
or
subject
was
at
an
idea:
I
didn't
provide
any
description
as
to
what
I
was
trying
to
do
with
this
change,
or
this
pull
request.
I
didn't
at
mention
anyone
I
didn't
ask
for
people
to
look
at
what
I
was
doing
or
why
I
was
changing
this
stuff
and
I
didn't
use
any
of
the
other
features
that
github
provides
in
terms
of
collaboration,
especially
when
it
comes
to
reviewing
a
PR
that
I'm
trying
to
merge.
B
So
if
we
look
at
some
of
the
areas
that
we
I
could
have
used
to
make,
this
pull
request
a
lot
better
or
at
least
useful.
So
the
first
thing
that
I
should
have
done
was
made
a
subject
line
that
actually
provided
more
detail,
or
at
least
an
idea
of
what
I
was
working
on,
as
opposed
to
saying
add
an
idea.
B
The
other
thing
that
I
definitely
should
have
done
was
really
gone
into
a
description,
identify
what
I
had
changed,
what
or
why
I
was
changing
what
I
did
and
made
it
easier
for
anyone
that
I
add
mentioned
within
the
UI
as
like
what
I
actually
needed
them
to
do
like
a
call
to
action
like
I.
Need
you
to
look
at
this
because
it
works
locally.
For
me,
I
want
to
make
sure
that
when
we
push
it
out,
it's
not
going
to
break-
or
this
is
a
really
quick
bug
fix
to
something
on
master.
B
We
need
to
push
this.
How
quickly
can
I
get
to
thumbs
up
and
let's
push
it
out,
we're
huge
on
using
emoticons
or
emoji
to
kind
of
give
you
the
thumbs-up
or
huge
on
the
thumbs-up,
shipit
squirrels?
Basically
anything
and
the
ship
itself,
just
to
you
know,
maybe
identify
with
two
thumbs
up.
This
is
good
to
go.
I'm
gonna
push
it
out,
but
again
no
one's
gonna.
Do
that
for
me
because
I
haven't
at
mentioned
them,
I
haven't
called
them
out
and
said,
like
I.
B
Need
you
to
help
me
some
other
things:
I
could
have
put
a
label
on
it,
so
these
are
just
some
examples
of
some
of
the
labels
that
we
actually
have
within
our
services,
training,
department
or
team.
So
this
is
just
a
way
to
identify
what
this
issue
or
pull
request
actually
relates
to,
and
it's
super
helpful.
B
We
sometimes
see
this
in
open
source
projects
where
you
use
a
label
to
say
like
this
might
be
a
beginner
project
or
a
beginner
problem
that
you
need
help
with,
and
it's
kind
of
like
a
stepping
stone
as
to
how
to
get
someone
to
jump
into
your
project
from
an
from
say,
an
enterprise
level.
You
can
use
these
things
to
either
prioritize
items,
identify
them
as
something
for
an
upcoming
release
or
something
that's
like
slated
way
way
out
into
the
future.
B
But
it's
just
a
really
really
quick
visual
tool
to
look
at
an
issue
or
PR
and
see
what
this
is
actually
related
to.
So,
for
example,
we
use
book
club
because
we
try
and
read
a
book
once
a
month,
and
we
have
an
issue
that
we
use
to
like
describe
or
discuss
like
the
book
and
like
a
term
of
notes,
and
that
just
makes
it
easier
for
us
to
like
find
the
book.
B
The
book
of
the
month
that
we're
reading
within
our
issues
milestones
are
something
else
that
you
can
do
milestones
kind
of
Act,
especially
with
this
new
update
for
projects
which
is
just
got
announced
like
a
half-hour
ago.
So
milestones
kind
of
allow
you
to
identify
like
a
project
timeline
for,
say,
a
specific
new
release.
So
in
this
example,
this
was
for
yesterday's
training
day
curriculum
which
we
were
late
on,
but
you
can
identify,
say
version
2.0
is
coming
up.
B
You
need
to
assign
some
certain
issues,
certain
pr's
to
it
and
then,
as
those
issues
and
PRS
are
closed,
your
timeline
or
your
your
your
completion
limit,
our
rate
is
kind
of
checked
off
and
you
eventually
will
hit
a
hundred
percent.
It's
definitely
a
really
really
quick
and
dirty
way
to
manage
your
project.
It's
definitely
not
like
the
only
solution,
but
it
gives
you
a
really
quick
visual
as
to
where
a
project
is
especially
when
you
get
that
email
or
a
phone
call
that
says
what's
going
on
with
2.0.
B
Where
are
we
at
who
what's
happening
just
by
like
quickly
being
able
to
say,
like
oh
we're
at
85%?
These
are
the
issues
or
these
are
the
PRS
that
we
need
to
finish.
Maybe
we
have
to
push
them
out,
it's
just
something
that
you
can
do
to
kind
of
make
your
PR
better
and
your
project
might
be
a
little
bit
better
because
of
it
and
then
finally,
you
can
obviously
add
mention
people,
but
you
can
also
assign
people
so
we're
able
to
assign
up
to
10
people
onto
a
pull
request.
B
These
are
the
three
people
that
were
involved
in
yesterday's
get
cozy
at
training
day,
so
here
I
was
able
to
assign
these
three
people
a
alerts
them
that
they've
been
assigned
to
a
project
it
gives
some.
It
gives
a
visual
to
other
people
that
are
within
the
project.
Who
are
this?
Who
are
the
major
stakeholders?
B
So
if
someone
came
into
this
pull
request
or
an
issue
or
this
pull
request
and
said,
hey
I
want
to
provide
some
help
or
I
have
some
questions
about
what
you
guys
are
doing,
or
something
that
you
said
is
completely
wrong.
How
this
would
allow
them
to
know
who
they
should
actually
be
reaching
out
to,
as
opposed
to
say,
maybe
anyone
that
was
in
the
discussion
tab.
B
This
actually
gives
them
like
the
primary
stakeholders,
and
this
is
a
little
bit
different
than
in
the
@mention,
because
this
actually
like
assigns
them
to
the
project
as
opposed
to
an
app
mentioned
where
you're
just
asking
someone
to
like
jump
in,
maybe
weigh
in
on
something
it
just
it's
a
it
was
kind
of
subtly
divides
them
between
stakeholders
and
just
people
assisting
the
project,
and
then
then
that
then
we
would
merge
it
right.
So
we
have
our
files
and
all
of
the
the
content
that
we
worked
on.
B
We
used
our
pull
request
where
we
actually
use
like
a
correct
subject
line
and
maybe
added
a
body
that
actually
asked
people
to
do
certain
things.
People
gave
us
a
thumbs
up,
maybe
the
ship
it
squirrel,
whatever
emoji
you're
into,
and
then
we're
able
to
merge
and
that's
why
that
big
green
button
allows
it.
So
this
big
green
button
allows
us
to
merge,
because
everything's
hunky-dory,
if
we
were
running
to
merge
people,
are
like
merge,
conflicts.
We'd
obviously
have
to
fix
those,
but
for
the
sake
of
this
example,
I
said
that
merge.
B
A
A
So
we
branch
we
make
changes
and
branching.
So
let's
go
through
this
one
more
time.
Branching
is
so
safe,
there's,
so
much
fear
people
have
when
first
starting
when
they
first
work
with
get
that
they're
going
to
do
something
and
everybody's
gonna
see
it
because
it's
all
public
and
they're
gonna
break
it.
If
you
make
your
own
branch,
you're
gonna
be
okay.
A
If
you
make
a
branch,
you
are
basically
creating
a
divergence
of
one
specific
point
in
time,
so
you
almost
have
an
exact
clone
of
the
repository
that
you
started
with
and
whatever
contributions
you
make
whatever
testing
you
do
if
it
burns.
If
it
fails,
that's
fine!
If
he
burned
down,
my
restaurant
would
be
a
bummer
for
him
and
then
I
could
keep
going
making
changes
who's
to
say
that
your
changes
are
actually
going
to
be
applied.
That's
why
he
says:
use
that
imperative
mood.
This
commit
exists.
A
If
or
if,
if
I
merge
this,
it
will
add
the
change.
If
I
choose
not
to
merge
this,
it
will
not
add
the
change.
So
you
write
your
commits
with
the
very
idea
that
what
you
do
is
impermanent,
that
it
can
be
adjusted
that
your
team
can
communicate
when
you
start
that
pull
requests.
The
third
one.
It's
a
pull
request.
We're
learning
these
so
every
time
that
you
communicate
every
time
that
you
collaborate,
you
go
through
these
principles
and
it
will
make
your
team
stronger.
A
It
will
make
your
team
basically
have
more
autonomy
and,
at
the
same
time,
have
a
closer
collaborative
community,
because
everyone
gets
to
see
everything
that
happens
at
github.
Basically,
everything
we
do
in
the
whole
company
we
can
go
read
so
we
have
almost
our
entire
I.
Don't
know
if
I'm
allowed
to
say
this
sorry
Chris,
we
have
everything
on
github
and
we
communicate
in
that
way.
We
are
very
productive.
We
work
across
departments
because
we
are
able
to
have
pull
requests
and
because
we
use
these
this
flow
so
extensively.
A
We
end
with
a
commit
and
then
we
merge
when
everyone
we
get
that
thumbs
up.
That
matt
said
so
we
have
about
15
minutes
left.
We
know
we
that
you
started
late,
so
everyone's
probably
super
hungry
and
we're
not
trying
to
keep
you
from
that.
So
anyone
who
wants
to
leave
you
may,
if
you
want
like
to
ask
questions,
come
on
up.
We
have
15
minutes
for
you
and
we
also
have
that
extra
hour
later.
Thank
you
for
coming.
A
A
A
B
I
didn't
hear
most,
so
the
question
just
was:
to
paraphrase
it
so
where
does
rebase
fit
in
this
workflow
and
why
ohyes
rebase,
always
the
answer
on
Stack
Overflow
give
or
take.
That
was
the
question:
yeah,
okay,
so
alright,
so
I'm
gonna
take
some
of
this
and
then
I'll
I'm
sure
Eric
will
throw
in
his
ideas.
So
a
lot
of
the
times
on
open
source
projects.
A
If
you
rebase,
you
will
avoid
the
merge
commit,
and
so
it's
an
easier
tidier
history,
so
people
would
choose
to
instead
of
merging,
they
would
choose
to
rebase
so
that
they
would
avoid
a
cluttered
history
and
that's
generally,
when
it's
used
on
open
source.
Does
that
address
your
question
about
where
rebase
fits
in
to
the
flow.
A
C
D
D
D
When
you
do
a
pull
request,
is
that
a
just
I'm
conceptualizing
that
as
a
description
about
who
I
want
to
work
on
this
feature,
or
maybe
I
want
to
do
something
really
big
that
is
outside
of
our
weekly
deploy
cycle,
and
that
kind
of
thing
is?
Is
that
what
can
you
use?
Pull
requests
outside
of
the
flow,
or
do
you
have
to
be
on
on
get
flow.
A
A
A
Can
happen
in
any
workflow
that
you
use
just
maybe
in
a
different
order?
It's
whenever
you
want
to
incorporate
changes
into
your
codebase,
so
pull
requests
when
we
did
when
we
explained
it
by
definition,
is
a
conversation
around
a
change
right,
so
you
create
that
conversation
at
whatever
point
you
would
use
in
your
workflow,
okay,.
D
A
D
D
D
A
D
A
D
B
Yeah,
so
it's
kind
of
so
it's
obviously
a
discussion
tool,
but
it's
also
allowing
you
to
make
the
proposed
change
so,
for
instance,
I
made
like
a
really
really
quick
dirty
crap
example.
So
here
we
have
two
branches
right.
We
have
our
master,
we'll
call
that
our
deployment
and
then
I
made
this
new
branch
called
BR.
Okay,.
D
B
In
my
on
my
BR
branch,
I
made
a
change
and
I
hope
I'm
getting
your
question
right
and,
if
I'm
wrong,
I'm.
Sorry
so
on
on
my
BR
branch,
I
made
changes
to
the
readme
dmt
file,
and
so
when
I
make
my
pull
request,
I
can
assign
my
base
or,
like
the
branch
that
I
want
to
compare
my
changes
to
so
here
we
have
our
master
and
er
and
then
I'm
going
to
quickly
make
this.
B
So
now
we
ever
are
again
with
my
terrible
description,
school
skills.
So
here
we
have
our
pull
request.
Where
I
can,
you
know
start
having
a
conversation
about
the
changes
that
I've
made
and
when
we
use
this
merge,
pull
request
that
files
that
I
made
changes
to
actually
change?
So
when
I
do
this
merge
if
I
go
back
to
the
code
tab,
the
readme
file
now
has
the
changes
that
I
made
based
on
that
new
branch,
but.
A
B
D
A
You
could
add
mentioned
specific
people,
which
is
what
we
do
when
we
want
to
incorporate
a
change
to
our
curriculums.
So
hey
Matt
can
I
get
your
thumb
on.
This,
can
I
get
four
thumbs
up
and
then
I
will
merge.
So
part
of
our
workflow
is
whoever
opens
the
pull
request,
merges
the
pull
requests
at
the
end.
Okay,.
B
There's
a
there's
a
couple
things
that
can
happen
one,
maybe
the
poor
request,
doesn't
maybe
the
files
that
are
being
changed.
It's
just
something
that
doesn't
want
to
need
to
happen.
So
maybe
you're
adding
a
feature
that
long-term
doesn't
need
to
happen
or
needs
to
get
pushed
off
for
a
long
time.
I
mean
you
can
essentially
delete
your
pull
request
and
but
keep
your
branch.
So
maybe
that
pull
request
doesn't
need
to
be
exist
for
a
while.
B
D
D
B
B
B
E
E
B
E
Online
at
all
questions
so
I
know
that
you
guys
had
it
flow
you're,
trying
to
tell
us
that
it's
good
practice
to
develop
in
another
branch
and
not
master,
but
there's
a
there's.
Companies
like
Google
that
that
everybody
is
just
committing
on
one
master
branch
and
although
it's,
although
it
might
not
be
having
the
most
stable
release,
they
have
release
branches
and
that's
a
completely
different
paradigm.
So
there
are
cases
where
one's
better
is
it
because
of
the
type
of
projects
they
do
in
small
teams?