►
Description
2:08 - Program start
3:58 - Branching strategies. What is a branch?
6:12 - GitHub flow, a great place to start
8:32 - Git Flow and where it works well
10:15 - Demo
12:59 - Hands on with the GitHub flow
18:42 - Hands on with the Git flow
30:28 - Best practices
Alex Augustin @aaugustine takes us through the fundamentals of branching strategies and when you would pick one strategy over the other. Alex also gives us some best practices around branching strategies and ways to keep your developer velocity as fast and efficient as possible.
https://github.community/t/30-minutes-to-merge-git-branching-strategy/156899
A
A
A
A
Hello,
hello,
I
think
we're
live
so
yeah,
hey,
hello,
everyone.
My
name
is
matt
desmond.
I
go
by
beer
to
vdu
at
github
and
today
I'm
introducing
a
new
segment
that
we
call
30
minutes
to
merge,
which
is
based
on
questions
that
we
find
in
our
github
community
forum,
and
today
I
am
super
pleased
to
introduce
alex
who's,
an
implementation
engineer
on
the
professional
services
team,
she's
going
to
be
walking
us
through
some
github
flow
or
branching
strategies
using
github
flow
and
git
flow.
A
Just
a
quick
intro
on
alex
she
has
seven
animals,
she's
got
three
cats
and
four
dogs.
Her
current
favorite
is
simon,
the
cat,
but
we're
not
gonna.
Let
the
rest
of
the
boot
magnets
know
who's
the
favorite
her
recent
purchase
on
amazon
is
a
a
purple
and
green
pair
of
asics
running
shoes,
she'd
like
to
be
more
involved
in
open
source
projects
and
if
she's,
looking
she's,
also
looking
for
a
project
to
start
working
on.
A
So
if
you
have
any
open
source
projects
that
need
a
little
bit
of
help
feel
free
to
drop
those
in
the
twitch
chat.
And
then
I
like
to
ask
people
what
their
ideal
gift
of
action
would
be,
and
hers
would
be
to
troll
her
teenage
daughter
on
social
media
to
do
their
chores.
So
with
that,
thank
you
very
much
for
joining
us
alex
and
let's
rock
and
roll.
B
B
Looking
good
so
I'm
coming
from
raleigh
north
carolina
today
to
talk
about
to
talk
about
branching
strategies,
it's
a
concept,
that's
near
and
dear
to
many
people's
hearts,
and
so
the
things
we're
gonna
cover
today
is
what
is
a
branch?
What
are
branching
strategies?
Why
are
they
even
important
and
then
we're
going
to
cover
two
of
the
most
popular
well,
two
of
the
popular
branch
strategies,
the
github
flow
and
then
the
git
flow
as
well.
B
We'll
also
speak
a
little
bit
about
best
practices
and
such
too
so
the
first
thing
I
want
to
jump
into
is:
what
is
a
branch?
A
branch
under
the
hood
is
just
a
lightweight
movable
pointer
that
points
to
a
specific,
commit,
or
another
way
you
could
think
of.
It
is
just
sort
of
like
an
isolated
sandbox
that
it's
not
gonna
affect
any
other
branch
on
your
repository.
It's
just
that
one
specific
area
in
time,
so
you
can
think
about
it
like
that.
B
So
what
is
a
branching
strategy
we
get?
You
know
we
start
making
branches.
You
start
getting
a
little
bit
of
wackiness
everywhere,
like
a
wackiness
run
it
all
around,
and
so
you
want
a
convention
or
some
type
of
naming
practice
to
take
care
of
that,
and
so
that's
when
branching
strategies
come
in
so
so
think
of
it
as
a
set
of
rules
or
convention
or
named
guidelines
about
how
branches
are
going
to
be
used
and
how
they
should
be
interacted
with.
B
One
thing
is
to
keep
in
mind
is
that
there
are
a
lot
of
branching
strategies
out
there
and
some
hybrids
of
ones
as
well.
It's
important
that
you
choose
what's
going
to
work
for
your
team
oftentimes
when
you
come
in,
it
might
be
best
to
start
out
somewhere
simple,
maybe
with
the
git
flow
and
begin
to
add
things
as
your
team
needs
it
or
as
your
automations
need
it
and
then
moving
forward
in
that
way.
B
Instead
of
just
going
and
finding
some
branching
strategy
and
then
trying
to
make
it
fit
your
situation
or
your
situation
fit
it
instead
start
small
and
create
the
branching
strategy
that
works
for
you
in
your
team.
Another
thing
to
keep
in
mind
is
making
sure
that
everybody
is
on
board
with
it
too.
B
That's
the
best
way
to
make
sure
it
all
works
out
is
if
everybody's
on
board,
so
the
first
one
I
want
to
talk
about
is
the
github
flow,
so
the
github
flow
sort
of
a
lightweight
branch-based
workflow,
and
it
supports
teams
and
projects
where
deployments
are
regularly
made
and
fast
some
things
you
can
keep
in
mind
about
the
github
flow.
It's
simple
and
easy,
it
kind
of
is
fast
and
you
can
deploy
early
and
often
works
well
in
ci
cd
strategies.
B
It's
good
for
continuous
release,
one
thing
that
where
it
might
not
be
so
strong
is
it
doesn't
support
multiple
versions.
So
if
you
have
to
support
multiple
versions
of
a
code
base,
that
might
be
a
little
bit
of
a
struggle
there.
So,
let's
dip
in
real,
quick
and
talk
about
what
the
github
flow
is.
B
And
how
it
begins,
so
the
github
flow
you're
going
to
start
out
by
creating
a
branch
off
of
your
main
project
and
then,
after
you
create
that
branch
you're
going
to
go
in
and
make
some
changes
to
that
branch.
So
you're
going
to
add,
add
some
things,
remove
some
things
and
begin
making
changes
for
whatever
feature
you
might
need,
and
then
the
next
step's
going
to
be
is
to
create
that
pull
request.
B
Sometimes
you
can
even
create
draft
pull
requests
early
and
get
a
good
conversation
going
about
the
changes
you're
wanting
to
make
to
the
code.
So
the
next
step
there
would
be
to
just
open
that
pull
request
start
collaborating
with
your
colleagues
there.
B
So
opening
that
pull
request
facilitates
more
conversation
and
a
review
on
that
code.
So
you
can
discuss
those
changes.
Maybe
you
know
improve
upon
them,
add
new
changes,
but
get
everything
ready
to
go
and
get
that
final
review
out
of
the
way.
So
after
that
final
reviews,
out
of
the
way
we
can
go
ahead
and
deploy,
we
can
go
ahead
and
go
through
any
processes
you
need
for
deployment.
B
At
that
point,
the
code
is
ready
to
go,
and
then
the
final
step
in
a
github
flow
is
going
to
be
that
merge
back
in
so
no
matter
what
branching
strategy
you
subscribe
to,
you're
still
sort
of
following
that
branching
off
and
then
coming
back
into
that
single
main
line
here,
this
single
don't
break
production
main
line.
So
it's
good
to
keep
that
in
mind
as
well,
so
that
is
just
sort
of
a
quick
github
flow.
Quick,
we'll
talk
about
the
get
flow
next,
so
the
get
flows
a
little
bit
heavier.
B
It
assigns
specific
roles
to
specific
branches
and
you
have
longer
lived
branches
that
you're
working
with
and
defines
how
and
when
we
should
interact
with
them
and
so
what
that's
going
to
look
like
it's
a
little
bit
bigger
of
a
beast
to
manage
and
it
works
really
well
in
a
slow
development
cycle
or
a
development
flow.
It's
better
suited
for
longer
cycles
as
well.
B
B
It
is
a
more
methodical
process
and
it's
considered
a
little
bit
heavier
heavyweight
or
you
know
it's
a
little
bit
more
overhead
and
you
have
to
make
sure
that
everybody's
involved
in
and
understands
the
process.
So
you
can
see
where
this
might
be
a
little
bit
harder
for
newer
developers
to
come
into.
But
what's
going
on
here
is
we
have
some
short-lived
feature
branches
and
that
are
these
blue
dots
right
here
and
we
have
the
develop
branch,
which
is
a
longer
lift
branch.
B
We
have
a
release
branch
and
we
have
a
main
branch
as
well.
So
the
main
branch
is
where
we're
going
to
be
cutting
our
releases
off
of
in
a
situation
like
this,
the
developers
would
come
and
they
would
pull
from
the
develop
branch
open
it
up
there
and
then
add
their
commits
for
their
feature.
Branches
and
those
feature
branches
would
merge
back
into
develop
or
develop
moves
to
release.
Maybe
there's
some
testing
there.
It
goes
to
qa
and
then
from
there
we
go
up
into
main
or
we
cut
our
release.
B
So
after
that,
let's
see
what
this
looks
like
in
action,
we
have
a
repository
set
up,
and
that
is
this
30
minutes
to
merge
repository
and
what
I'm
going
to
do
with
this
repository.
Is
I'm
going
to
go
ahead
and
fork
that,
down
to
my
personal
github
here.
B
C
B
Now
we
can
get
get
working
here
so
in
this
30
minutes
to
merge
repository,
and
this
is
something
that
you
can
fork
as
well.
We
have
instructions
here
how
to
follow
each
flow
and
that's
what
we're
going
to
get
ready
to
step
through
now.
B
So,
let's
see,
the
first
thing
we
want
to
do
is
do
some
initial
repo
setup.
The
thing
we
want
to
do
is
turn
on
github
pages,
so
we
can
host
this
game.
It
is
a
tetris
game.
I
hope
you
like
tetris
and
in
order
to
do
that,
we
need
to
turn
on
github
pages.
So
let
me
go
ahead
up
here
into
the
settings.
B
B
B
B
C
B
I've
got
a
little
bit
of
a.
How
are
we
working
there?
Is
that
good
zoom
in
a
bit
there
we
go
and
just
go
ahead
and
enable
those
actions
so
release.
Drafter
is
what
we'll
be
using
today
and
release.
Drafter
is
going
to
collect
all
the
commits
that
were
made
and
then,
when
the
pull
request
happens,
we'll
have
a
draft
of
a
release
ready.
B
All
right,
the
next
thing
we're
going
to
do
is
we're
going
to
step
through
the
github
flow.
So
the
first
thing
we
have
is:
we
need
to
go
ahead
and
create
a
branch
right.
We
need
to
make
that
that
sandbox,
so
we
can
fix
the
readme.
So
what
our
pro
our
issue
here
is
and
funny
that
I
use
the
word
issue
is
we
actually
would
start
from
an
issue
in
this
repository?
B
Maybe
somebody
reported
a
bug
that
our
readme
doesn't
contain
the
proper
link
and
where
that
is,
is
right
here,
this
link,
you
can
play
the
game
at
if
you
were
to
click
that
that
is
not
going
to
work.
That
link
we
got
when
we
turned
on
github
pages
will
be
the
one
that
will
want
to
replace
this
with.
C
B
B
B
B
B
So
I
notice
here
I
can
add
any
other
extended
descriptions.
If
I
wanted
to
get
a
little
bit
more
verbose,
I
absolutely
could
and
save
that
off,
I'm
going
to
commit
directly
to
my
update,
readme
branch,
so
that
is
the
branch
that
made
that
safe,
sandbox
and
then
commit
changes
all
right.
So
we
see
that
we're
in
the
update
readme
branch.
That
looks
good
and
we
see
that
we
have
changed
the
url
here,
awesome
all
right,
let's
just
scroll
on
down
here,
so
we
created
the
branch
we
edited
the
readme
fixed
the
url.
B
So
one
thing
to
keep
in
mind
here
is
that
we
want
to
switch
this
to
actually
be
in
our
repository,
so
we're
not
making
a
pull
request
to
the
forked
repository.
I'm
doing
it
within
my
local
here
so
definitely
want
to
hit
that
drop
down
and
make
sure
that
works
out.
Okay,
all
right.
We
see
that
main.
I'm
requesting
this
little
arrow
is
really
helpful.
B
We
can
take
a
look
and
see
what
we're
moving
in
here.
So
we
see
that
we
have
pulled
out
the
github
school
and
my
personal
account
has
been
made.
So
that's
great
go
ahead
and
head
back
to
the
pull
request
here,
everything
looks
good,
let's
go
ahead
and
merge
that
pull
request
in
so
here.
If
we
wanted
to
have
more
of
a
conversation,
we
absolutely
could
by
using
this
comment
box
down
here.
I'm
just
going
to
go
ahead
and
confirm
that
merge
all
right
and
one
thing
to
keep
in
mind-
is
stale
branches.
B
B
Coming
back
to
our
main
branch.
Now
we
know
because
we're
clicking
on
main
scroll
on
down
check
out
our
readme
here.
It
does,
in
fact,
have
the
change
I
made
from
my
last
branch
in
it,
and
that
is
it
that
completes
the
github
flow.
It's
just
that
branching,
creating
a
pull
request
to
merge
back
in
and
that's
it
so
easy.
B
The
next
thing
we
want
to
look
at
is
going
to
be
the
get
flow.
So
we've
created
some
branches
when
you
forked,
the
repository,
you
may
have
already
seen
them
that
we've
have
a
develop
working.
We
also
have
a
couple
example
branches.
So
if
you
don't
want
to
follow
along
here
with
the
changes
we're
getting
ready
to
make
for
the
example
branches,
you
can
easily
just
merge
those
in
so
down
here,
all
right
so
for
the
hands-on
activity
portion
here,
we're
going
to
create
a
feature,
branch
called
feature,
change,
speed.
B
B
So
the
first
thing
I
want
to
do
is
make
a
change
to
this
game
here
and
that's
going
to
be
in
this
index.html
file
and
we'll
scroll
on
down
to
making
sure
we're
still
in
that
feature,
branch
scroll
on
down
about
line
78,
that's
where
the
speed
controls
are,
and
we
can
go
ahead
and
switch
it
up
here.
B
C
Right
we'll
just
commit.
B
B
B
To
okay,
so
if
we
just
make
sure
that
we
are
point
both
those
to
our
local
repository
that
we're
making
a
pull
request
into
our
own
repository
change,
speed
of
the
game,
we
can
go
ahead
and
create
a
pull
request.
There.
B
B
C
C
B
B
So
from
there
what
we
want
to
do
is
actually
we
want
to
create
a
pull
request
into
develop.
Now
I
know
you
saw
in
the
beginning
here
when
we
did
this
pull
request.
Here
we
were
asking
to
merge
into
main
right.
Well
one
cool
thing
you
can
do
when
you
make
a
mistake
like
this.
It's
no
problem
at
all
to
just
go
ahead
and
close
that
pull
request
and
you
don't
even
have
to
continue
to
use
it.
So
maybe
that's
not
the
right.
B
Maybe
someone
just
made
a
mistake
and
and
went
to
try
to
merge
to
the
wrong
branch.
Well,
as
long
as
that,
pull
request
is
still
open.
We
can
just
close
it
without
doing
anything
and
then
what
we
can
do
is
we
can
go
back
to
pull
requests
and
then
we
can
open
a
new
pull
request
from
there.
So
all
we
have
to
do
then,
is
go
to
this
new
pull
request
and,
let's
take
a
look,
so
we
definitely
want
to
pay
attention
to
where
we're
going.
We
don't
want
to
go
into
github
school.
B
So
I'm
saying
I
want
to
take
feature
change,
speed
to
develop
it's
ready
to
go
to
our
long
live,
develop
brand,
for
maybe
my
qa
team
is
going
to
give
it
a
test
there.
Okay,
so
we'll
go
ahead
and
create
the
pull
request,
change,
speed
of
the
game.
Everything
looks
good
there.
Let's
go
ahead
and
create
that
full
request.
B
B
And
a
conversation
can
happen
through
that
pull
request
and
be
tracked,
so
that
will
also
be
a
part
of
history
as
well.
So
let's
go
ahead
and
take
a
moment
go
back
to
pull
requests.
We
also
need
to
ch
merge
our
feature
of
change
color
into
develop,
so
make
sure
that
we.
C
B
In
mine
here
all
right,
so
since
we're
merging
into
develop
first
we're
sending
it
off
to
our
qa
team,
we
want
to
merge
the
feature
change
color
into
develop.
That
looks
good
there.
We're
going
to
leave
that
create
that
pull
request.
B
B
Awesome
work
looks
good,
keep
it
clean,
delete
that
branch
and
then
we're
going
to
come
back
to
the
code
tab.
So
we
see
that
github's
trying
to
help
us
along
being
like
oh
I've,
detected
some
pushes
here.
You
want
to
create
a
pull
request.
Not
yet,
let's
just
go
ahead
peek
around
into
develop,
and
we
see
that
if
we
scroll
around
in
our
index.html,
we
can
actually
see
that
the
merge
request,
merge,
pull
request
is
there
in
the
history
and
we
can
actually
see
that
line
78.
B
We
do
have
our
changes
so
that
worked
out
perfectly.
The
next
step
of
the
git
flow
is
we're
ready
to
go
to
production.
Qa
team
has
come
back
says,
develop
branch
is
great.
There
are
no
bugs,
no
mistakes,
imagine
that
and
then
we
are
going
to
go,
compare
pull
request
into
maine
now.
This
is
where
you
could
set
up
some
branch
protections
around
maine
to
enforce
that
a
review
is
done.
You
could
do
all
sorts
of
other
great
things
with
branch
protection
here,
but
we're
not
worrying
with
that
today.
B
We
could
be
a
little
bit
more
specific.
We
could
say,
merge
develop
into
main
or
whatever
you
want
to
do,
or
your
message
there.
So
then
we're
going
to
go
ahead
and
create
that
pull
request.
B
Awesome
we're
ready
to
go.
We
are
so
close
to
getting
a
production.
Now
we
can
see
all
the
changes
here
that
we've
made
in
this
pull
request.
So,
even
though
these
changes
existed
in
different
branches,
we
can
still
see
when
they
were
merged
in
and
still
clock
those
changes
right
and
then
also
the
merge
commits
that
were
made
for
that
as
well.
B
B
B
Now,
we've
made
it
all
the
way
through.
The
next
thing
I
want
to
show
is
that
release
draft
or
action.
So
when
we
turned
on
actions
earlier,
we
went
ahead
and
had
this
action
running
in
the
background
called
release,
drafter
and
what
it
did
is.
It
went
ahead
and
drafted
all
of
our
changes.
So
we
see
that
where
we
added
the
correct
url
for
the
game,
we
can
see
the
change
that
was
made
where
we
changed
the
speed
of
the
game
and
the
feature
and
then
went
ahead
and
merged.
B
So
we
can
see
all
these
pull
requests
and
what
they
changed
within
the
draft.
If
we
wanted
to
edit
and
create
add
some
more
information
about,
what's
changed,
we
absolutely
do
that
and
cut
the
release
there.
So
that's
one
really
great
thing
about
that
action.
Release
drafter!
B
So
that's
a
pretty
great
one
for
use
there.
So
with
that,
I'd
like
to
take
a
moment
to
talk
about
some
of
the
best
practices
when
it
comes
to
branching
strategies,
and
one
of
the
things
you
really
have
to
do
is
make
sure
you
have
everybody
on
board.
B
It
is
really
tough
to
to
implement
some
type
of
strategy
where
not
everybody's,
on
board
or
branches
are
just
coming
out
of
every
direction
and
you're
trying
to
rein
that
in
so
setting
that
precedent
first
and
then
getting
everybody
on
board
is
a
really
great
start
there
and
again,
starting
small
with
something
like
the
git
flow
and
then
building
out
things
as
you
need.
Them
is
probably
the
best
way
to
go
about
enacting
a
branch
strategy
there.
So
with
those.
B
Best
practices
and
again
cleaning
up
your
branches
as
you're,
creating
them,
especially
those
short,
lived
ones,
feature
branches,
not
letting
them
hang
out,
because
you
don't
need
them
very
long.
They
don't
need
them
around
mucking
up
the
place,
go
ahead
and
cleaning
those
up
as
you
go
is
a
really
great
practice
to
get
in
the
habit
of
and
cleaning
that
up
and
then,
of
course,
in
the
in
the
git
flow.
B
What
you're
going
to
do
is
you're
going
to
go
ahead
and
pull
all
those
changes
that
got
pushed
into
production
back
into
develop
and
then
continue
on
with
your
practice
there.
Those
are
definitely
some
things
to
keep
in
mind
there.
So
with
that,
I
guess
we
can
open
up
for
any
questions.
C
B
B
So
some
of
the
things
that
I've
seen
all
sorts
of
with
with
branching
strategies
is
sort
of
hybrids
of
ones
where
you
take,
maybe
some
a
little
bit
of
the
git
flow
and
a
little
bit
of
the
git
hub
flow
and
mix
them
together
by
using
those
feature,
branches,
hey,
there's
beard
what's
up,
then.
A
I'm
out
of
the
beach
purgatory,
it's
great,
so
you
asked
you
asked
me
earlier
what
my
favorite
color
is.
I
prefer
green
sorry
about
that.
A
And
then
yeah,
so
I
just
wanted
to
say
first
and
foremost
thank
you
very
much
for
all
your
help.
Today,
it's
been
a
great
demo
of
like
the
two
different
workflows
that
we
covered
today
and
then
also
to
chat.
There
were
some
helpful
links
that,
through
that
were
thrown
out,
that
envy
link
for
the
git
flow
is
a
good
read.
Both
talks
about
the
github
flow
as
probably
a
solution
for
a
lot
of
flows,
but
then
it
also
dives
deeper
into
like
the
github
or
the
git
flow.
A
So
thanks
for
sharing
that
earlier
and
then
just
kind
of
wrap
up
some
things,
we
also
are
going
to
be
having
a
q
a
session
going
on
in
the
community
page,
which
I
think
has
been
linked
a
couple
of
times
there.
It
goes
so
if
you
do
have
questions
feel
free
to
jump
in
there.
Just
a
reminder.
A
This
entire
session
was
brought
to
you
by
questions
that
were
asked
in
that
community
forum,
so
keep
asking
your
github
related
or
get
related
questions
there,
and
you
might
see
your
question
turn
into
a
quick,
30
minute
segment
with
another
implementation
engineer
that
I
can
rope
into
a
session
like
this.
Outside
of
that,
there's
also
gonna
be
some
swag
giveaways.
I
I
hear
so
get
yourself.
Some
gets
github
swag,
maybe
maybe
they're
throwing
out
hoodies.
A
I
don't
know,
I
don't
know
what
they're
giving
away,
but
I
would
I
would
hope,
for
a
hoodie
myself,
maybe
some
stickers
at
the
least
outside
of
that.
I
don't
think
I
have
anything
else
to
kind
of
point
you
in
that
direction
for
but
yeah
thanks
so
much
for
joining
us
today
and
have
a
great
one
and
thank
you
very
much
alex
for
all
your.