►
From YouTube: Git for Pair Programming - Git Merge 2017
Description
Cornelius Schumacher works for SUSE Linux as a senior software developer and engineering manager, and has been an open source contributor for more than a decade.
Though git doesn't support pair programming natively, there are workarounds and best practices around how to do productive pair programming with git. This presentation will give an overview of how this works, with practical insights from one of the biggest open source projects using pair programming as its primary means of development. It will include a sketch and discussion about how git could get native support for pair programming.
About GitMerge
Git Merge is the pre-eminent Git-focused conference: a full-day offering technical content and user case studies, plus a day of workshops for Git users of all levels. Git Merge is dedicated to amplifying new voices in the Git community and to showcasing the most thought-provoking projects from contributors, maintainers and community managers around the world. Find out more at git-merge.com
A
Great
to
be
here,
I
want
to
talk
about
get
four
pair
programming,
so
how
did
I
get
there?
Identically
wants
a
child.
Tell
you
two
stories
which
are
related,
so
the
first
one
is
how
we
are
using
gates
by
working
on
Cloud
Foundry,
in
my
case,
to
do
pair
programming
and
the
others.
How
I
worked
on
gates
to
improve
the
situation,
how
to
make
it
easier
to
work
with
kids
for
pair
programming.
A
So-
and
this
is
something
yeah
I
came
to
from
the
crowd
for
new
product
and
that's
the
first
time
actually
started
to
use
a
programming,
and
then
I
started
with
that
last
year.
So,
let's
start
with
explaining
limit
what
a
program
is
and
I
would
be
interested
in
who
asked
you
is
actually
doing
pair
programming
right,
raise
your
hands.
If
you
are
doing
that,
that's
quite
a
number
of
people-
that's
that's
great!
So
what?
What
is
pair
programming
I
want
to
start
with?
A
Basically
the
procedure,
how
you
do
that
it
means
that
you
have
two
people
working
on
one
computer
and
that's
important
that
it's
really
only
one
computer,
so
you're
not
collaborating.
Why
are
poor
requests
or
by
sending
patches
around,
but
you're,
actually
working
physically
on
the
same
computer,
so
both
people
have
control
of
the
mouse?
Both
people
see
exactly
the
same
on
the
screen.
Both
people
can
type
at
the
same
time,
so
they
have
to
talk
to
each
other.
A
They
have
to
coordinate
and
do
what
what
is
necessary
to
be
able
to
work
together
on
one
computer.
What
you
usually
do
there
is
two
separate
roads,
so
one
is
the
driver
that
lets
the
person,
has
the
keyboard
and
just
doing
the
actual
typing,
and
the
other
person
is
the
Navigator
with
more
looking
into
a
little
bit
longer
term
thing.
So
how
are
things
evolving,
commenting
on
what
what
the
drivers
doing,
helping
him,
avoiding
mistakes
and
stuff
like
that,
so
and
there's
this
I'm
talking
here
about
doing
really
working
on
one
physical
computer?
A
You
can
also
do
that
remotely.
That's
a
bit
more
challenging
challenging!
That's
the
topic
on
its
own,
so
I
don't
want
to
touch
this
that
much.
What
does
it
take
to
do
pair
programming?
How
does
it
look
like
so
if
you're
really
doing
it?
Consequently-
and
you
are
doing
it
for
a
day,
that
requires
quite
some
rhythm,
obviously,
if
you're
working
together
with
a
person
at
the
same
computer,
you
have
to
be
physically
there,
so
you
need
a
schedule
where
you
can
start
and
end
at
the
same
time.
A
So
you
work
together
with
the
same
person
for
one
day
for
maybe
two
days,
but
then
you
often
rotate
and
work
with
somebody
else.
So
it's
not
like
one
person
would
work
with
another
person
for
four
weeks
or
even
months
or
something
like
that.
It
is
really
about
frequent
rotation
and
also
sometimes
new
people
joining
the
team
or
maybe
sometimes
a
person
is
on
vacation
or
sick
or
whatever
is
getting
in
the
way
there.
So
you
have
a
frequent
rotation
working
with
other
people
working
on
yeah,
new
stuffs
and
new
code.
A
Whatever
you
work
on
and
to
make
that
happen
in
a
nice
way
of
the
physical
setup-
and
this
really
is
further
for
the
physical
in-person
case
there,
there
you
have
workstations,
which
are
prepared
for
pair
programming.
So
what
you
often
have
is
non-personalized
workstations
so
that
you
don't
use
your
own
desktop
or
your
own
laptop
working
for
workstation,
which
is
only
there
for
pair
programming,
and
it's
set
up
for
the
project
you
work
on.
But
you
don't
take
your
personal
account
there.
You
don't
have
your
email
there
or
something
like
that.
A
It's
only
for
for
developing
on
the
project,
and
then
you
have,
if
you
have
a
nice,
set
up
a
nice
table
where
there's
enough
enough
space
to
sit
there
conveniently
and
work
together
to
keyboard
to
mirrored
monitors
so
that
both
people
see
the
same
thing
and
that's
all
connected
to
this
one
computer,
where
you
do
the
extra
code,
as
this
is
coming
from
the
extreme
programming
environment,
that
that's
where
a
programming
has
a
really
huge
role.
What
is
also
important
are
a
couple
of
techniques
which
which
are
used
there.
A
So
test-driven
development
is
one
thing
which,
which
is
generally
useful,
of
course,
but
when
pairing
it
becomes
quite
interesting
and
new
dimension
there,
because
you
can
actually
work
together
in
pairs
and
one
person
can
write
the
test.
The
other
can
write
implementation,
so
this
pairing
set
up
facilitates
test-driven
development
quite
well.
Continuous
integration
also
is
an
important
part
there,
and
that
also
helps
those
pairing.
I
mentioned
the
frequent
rotation.
A
So
when
you
know
that
there
is
good
CI
in
place
which
makes
sure
that
if
you
commit
something
which
breaks
the
test,
you
see
it
immediately
and
it's
not
going
out
of
production,
then
you
can
much
more
easy
work
in
a
way
where
you
can
bring
in
new
people
and
where
you
can
rely
on
the
CI
to
catch
these.
These
mistake,
which
which
might
happen
if
you
rotate-
and
maybe
you
don't
know
the
code
so
well-
that
you
don't
do
any
mistakes
anymore.
A
So
this
all
these
techniques
work
very
well
together
in
in
extreme
programming,
but
if
those
pair
programming
is
not
limited
to
this
giving
form
in
XP,
but
you
can
use
it
in
your
project
in
different
ways
as
well.
So
how
does
it
look
like
if
an
extra
pair
programming
session
is
happening,
so
that
would
be
a
typical
conversation
which
is
happening
why
you
are
doing
pair
programming,
so
one
developer
met
start
with
with
the
test.
So,
let's,
let's
write
a
test
write.
It
write
the
test
case
which
specifies
the
feature
we
want
to
implement.
A
A
Oh
there's
another
place
in
the
code,
which
looks
very
similar,
so
maybe
we
can
also
move
move
that
to
to
a
common
function
or
something
like
that,
so
that
would
be
typical,
Navigator
role,
so
I
see
that
some
other
application.
So
let's
have
the
other
developer.
Oh,
why?
Why
don't
we
remove
that
as
well?
Okay
and
the
other
developer
implements
that
Tesla
means
the
green.
Everything
is
fine
coat
of
clean
functionality.
Is
there
so
we're
done
with
one
small
step
and
we
can
move
on
to
the
next
feature
or
the
next
small
part
of
functionality?
A
So
let's
give
the
controller
to
the
next
develop
I
again
and
we
start
again
with
the
same
cycle,
and
this
kind
of
cycle
is
something
which
can
take
half
an
hour,
but
this
can
also
take
five
minutes.
Sometimes
you
also
switch
keyboard
control.
Much
more
often,
and
sometimes
maybe
even
while
you
are
writing
the
commit
message.
Somebody
else,
the
other
developer
has
a
better
idea
how
to
formulate
that,
instead
of
trying
to
tell
the
other
person
how
to
do
it,
the
other
person
just
takes
over
the
keyboard,
and
so
now
again,
let's
write
it.
A
A
So
this
is
all
nice,
but
you
might
ask
yourself
the
question:
why
would
I
want
to
work?
This
way
does?
Does
this
even
make
sense?
So
isn't
this
just
a
waste
of
time
or
a
waste
of
resources,
putting
two
people
on
the
same
problem
and
I
found
this
nice
tweet
where
it
says
yeah,
but
your
programmers
are
pairing,
wouldn't
they
write
half
as
much
code
as
if
they
wouldn't
pair,
and
the
answer
is
no,
hopefully
they
will
write
even
less
code
and
that's
that
the
thing
programming
is
not
about
creating
as
much
code
as
possible.
A
A
So
this
creates
a
very,
very
short
feedback
cycle
and
this
feedback
cycle
that's
very
important
for
code
quality.
You
all
know
that
from
programming
review
helps
feedback,
helps
that
makes
a
code
better.
That
makes
the
program
better
and
with
that
programming
you
get
the
earliest
possible
code
review
to
really
increase
the
quality,
and
that
is
what
what
you
you
see
when,
when
people
are
pairing
that
the
code
quality
is
actually
quite
high
and
the
productivity
there
are
studies
about
that.
It's
actually
about
the
same.
A
Another
part
is
learning.
So
if
you
do
something
on
your
own,
you
can
learn
things
as
well,
but
if
you
are
doing
it
together
with
somebody
you
have
to
partner,
you
have
to
you
can
ask
questions.
You
can
see
how
your
partner
is
using
commands,
how
how
they
are
using
different
utilities.
We
are
not
about
how
to
learn
get
today,
and
this
actually
is
a
great
way
when
you're
pairing
just
watching
somebody
else
operating
it.
They
might
know
different
options
like
you
do
they
might
have
a
different
experience,
more
knowledge
there.
A
So
in
so
you
learn
that,
just
by
watching
and
then
by
doing
it
yourself
by
the
other
person
sitting
there
and
and
watching
over
your
shoulder
and
helping
you
if
you
do
something
wrong.
So
that's
that's
again
with
the
short
feedback
loop,
a
great
way
how
to
learn-
and
it's
not
only
a
great
way-
to
learn
for
new
people,
but
also
for
people
who
have
more
experience
and
because
programming
problems
are
usually
new
problems.
A
Pairing,
of
course,
is
a
social
environment.
You
you
are
working
together
with
another
other
person,
so
sometimes
we
give
our
set
to
not
be
very
social
or
we
might
have
trouble
with
creating
social
interactions.
Starting
a
conversation
or
something
like
that
and
that's
true
I
mean
there
are
introverts
which
words
for
them.
It
might
be
more
energy
to
start
a
conversation
or
to
ask
somebody
a
questions
and
then
follow
us.
The
great
thing
about
programming
is
that
this
is
very
controlled
environment.
A
A
A
You
know
the
suprotec
method,
which
is
in
philosophy
a
structured
way
how
to
solve
problems
or
how
to
find
the
truth
by
asking
questions
by
questioning
assumptions
and
that's
what
what
is
happening
when,
when
you
are
pairing,
because
you
ask
the
other
partner,
yes
questions,
why
are
you
doing
it
this
way?
Why
do
you
think
that's
a
better
solution,
and
this
way
you
quickly
get
into
better
solutions,
and
even
if
you
don't
have
enough
experience,
don't
have
a
lot
of
experience.
You
find
answers
to
difficult
questions
together.
A
So
that's
kind
of
the
the
nice
theory
behind
that
the
practical
challenges
when
working
with
a
programming
and
working
with
kids
are
there
as
well
and
I'm,
working
on
Cloud
Foundry,
which
is
a
big
open
source
project
and
platform-as-a-service,
and
this
is
one
of
the
few
projects
which
actually
systematically
does
air
programming
even
in
an
open
source
project.
So
it's
actually
in
the
governance
documents
where
it
says.
Ok
code
has
to
be
written
with
another
development
pairing.
So
this
is
the
governance,
and
most
teams
actually
follow
this.
A
There
are
options
to
that,
but
most
teams
actually
do
that
and
do
pair
program
or
day,
and
that
poses
a
couple
of
challenges.
So
a
typical
commit
line
would
look
like
this,
and
the
problem
is
if
I'm
working
as
a
pair.
How
do
I
reflect
that
in
get
so
get
up
nicely?
Those
pictures
of
the
people
who
worked
on
some
something-
and
they
luckily
show
committers
and
authors
as
to
pictures.
A
So
this
is
a
way
where
we
kind
of
worked
around
this
limitation
by
using
the
committers
and
the
authors
to
reflect
who
is
working
on
on
a
page,
so
we
can
put
in
two
people
which
are
shown
on
github,
for
example,
and
because,
let's
not
reuse,
the
metric,
we
are
alternating
and
one
person
is
the
author
with
Lancome
is
and
then
in
the
next
commits.
We
just
switch
roles,
so
this
is
not
ideal,
but
that
this
is
at
least
workaround
to
reflect
the
shares
authorship
and
in
the
git
commit
looks.
A
It
would
show
up
like
this,
so
it's
a
way
of
the
also
we
commit
and
we
switch
between
that
so
doing
this
with
playing.
It
is
quite
annoying
because
you
have
to
change
the
author
configuration
all
the
time
and
you
have
to
put
in
commands
and
options
to
set
the
committer
info
and
whatever
so
so.
This
is
not
really
convenient.
So
luckily,
there
is
a
nice
tool
called
get
duet,
which
is
used
by
lots
of
people
doing
pair
programming,
and
this
encapsulates
that
it's
a
wrapper
socket.
A
Basically,
so
you
set
the
authors
which
are
currently
working
on
something
let's
get
to
s,
and
then
you
have
some
initials
which
you
put
from
a
configuration
file
and
then
you
can
use
it
to
add
commits,
and
this
will
make
sure
that
also
in
committer
are
set
and
alternated
when,
when
you're
working
on
different
commits,
you
also
have
other
wrappers
for
revert
on
formula
for
merge.
But
it's
not
native.
It's
a
wrapper,
and
this
is
where
it
becomes
more
ugly.
A
So
for
a
rebase,
for
example,
you
have
to
do
use
a
quite
complex
line
because
it
somehow
has
to
sneak
in
the
2's,
commit
there
and-
and
that's
what's
called
something
where
were.
You
are
lacking
this
native
support
of
it
for
multiple
authors,
because
it
doesn't
know
about
the
fact
that
there
are
two
people
working
on
the
same
thing.
A
There
are
lots
of
other
challenges.
Most
of
them
are
actually
pretty
small,
so
you
can
work
quite
productively,
but
back
trekkers
issue,
trackers
project
management
tools
that
they
all
have
challenges
there,
and
even
if
github
is
showing
two
pictures
for
for
the
commits.
When
you're
writing
a
comment
that
does
not
there,
you
only
have
one
one
person,
whether
it's
locked
in
and
as
when
you're
doing
a
problem.
You
often
type
in
a
command
and
you
ought
to
switch
roads
there.
So
it's
really
also
collaborative
work,
not
something
from
a
single
author.
A
So
even
though
you
wouldn't
actually
need
two
pictures
of
two
people
to
reflect
that
so
for
something
like
assigning
back
to
signing
issues,
let's
often
there
so
you
can
put
into
two
keeper
but
for
comments,
for
example,
that
that's
that's
not
possible,
and
another
issue
with
that
is
especially
if
you
are
using
these.
These
non
personalized
workstations
is
that
somebody
has
to
lock
in
so.
If
you
are
on
one
shared
machine,
you
might
not
want
to
provide
audio
your
authorization
information
there.
So
what
what
we
often
do
is
if
it's
possible,
we
use
two-factor
authentication.
A
So
at
least
you
have
a
second
factor
where
I
can
safely
log
in
without
compromising
your
security
too
much.
One
challenge
with
that
with
it
also
is
that
you
need
to
commit
to
repository.
You
need
to
have
access
to
that,
for
you
usually
have
an
SSH
key.
We
work
around
this
problem
that
that
you
don't
want
to
put
your
private
key
on
a
shared
machine
by
putting
it
on
a
USB
stick.
So
so,
if
we
just
put
the
private
key
on
the
USB
stick
and
then
use
SSH
agent
to
temporarily
activate
the
key.
A
So
during
the
session
you
can
just
say
okay
at
this,
but
let
it
expire
after
a
a
few
hours,
and
then
you
can
work
with
it
while
you
are
sitting
together
so
that
lets
you
share
the
session.
But
after
that
it's
gone
again
and
you
don't
have
to
share
you
your
secrets,
but
you
just
share
your
with
your
work.
A
So
these
are
the
kind
of
practical
challenges
we
and,
of
course
it
would
be
nice
to
improve
on
that.
How
can
we
do
that?
How
can
we
become
better
there
and
make
our
to
is
better
adapt
to
this
workflow
of
pair
programming?
There
are
three
kind
of
categories
there,
so
the
first
category
is
tools
which
already
work.
Email
is
such
a
tool.
It
provides
support
for
multiple
authors,
let's
in
the
specification,
so
you
can
have
more
than
one
from
address.
A
If
you
do
that,
you
have
to
add
to
sender
address,
but
then
you
have
that
already
so
email,
it's
not
a
problem.
I,
don't
think
it's
very
commonly
used,
but
you
can
reflect
this.
The
other
tools
which
which
do
that
so
in
terms
of
wording,
control
systems.
Bizarre,
for
example,
has
the
notion
of
multiple
authors.
So
you
can
do
it.
So
that's
nice,
but
not
all
too.
It's
do
it,
and
how
can
we
improve
the
others?
A
There's
another
class
of
tools
such
as
github,
which
are
proprietary.
We
can't
really
change.
We
can,
of
course,
create
feature
requests.
We
can
ask
people
to
improve
them.
We
can
provide
ideas
there,
but
then
we
are
kind
of
yeah.
We
as
a
community
can't
really
fix
that
problem
other
than
hoping
that
the
people
who
control
these
tools
do
that,
and
we
can
make
a
good
case
and
hope
that
they
they
help
there
and
then
there's
the
other
category
of
open-source
tools
where
we
actually
can
do
changes
ourselves,
and
we
can
propose
improvements
and
do
that.
A
A
Yeah
and
I
submitted
that
as
a
request
for
comment
upstream.
So
this
slide
is
just
for
reference.
There
are
previous
discussions.
There
will
be
future
discussions
and
this
patch
adjusted
for
in
astray
ssin,
so
as
a
disclaimer.
What
I'm
talking
now
about
that's
unlikely
to
end
in
gates
as
it
is,
but
maybe
it's
a
starting
point
for
an
implementation.
We
can
finish
in
the
future,
which
actually
adds
as
much
of
an
author
support
and
helps
do
it
people
doing
pair
programming
doing
that
in
a
better
way
than
when
we
are
doing
it
now.
A
How
does
it
look
like
it's
modeled
after
the
model
of
get
to
it?
So
we
have
file
which
defines
the
authors
and
the
initials,
so
you
can
easily
use
them,
as
you
are
switching
quite
frequently
between
authors
when
you're
doing
pair
programming,
it's
convenient
if
every
command,
where
you
can
do
that
without
having
to
type
in
email,
addresses
with
all
the
fragility.
This
brings
the
potential
for
typos,
but
you
can
just
say:
okay,
I
have
some
initials,
which
identify
an
author
and
and
the
tool
checks
that
they
are
there
and
set
in
the
correct
data.
A
So
we
have
a
file
which,
which
does
that
so
you
define
it
there
and
get
authors,
has
a
list
of
can
show
a
list
of
the
author
authors.
It
knows,
reading
from
the
file
showing
errors.
If
something
is
longer
so
then,
when
you
are
doing
a
pair
programming
session,
the
first
thing
you
do
you
get
together
with
your
your
partner
and
then
you
run
get
authors
with
the
two
initials
you
off
with
working
on
it,
and
this
sets
then
configuration
and
gates.
Also
that
give
knows
about
it,
you
can
show
it
with
get
authors.
A
It
also
shows
the
expansion.
So
if
there's
something
wrong,
you
can
see
it
and
in
the
configuration
set,
a
new
section
authors
which
just
lets
list
the
current
authors,
which
which
are
working
on
a
piece
of
course
now
when
this
is
registered,
I
can
actually
do
comments
or
all
the
other
commands
and
if
I
commit
something,
then
I,
then
with
my
patch
again,
would
record
this
information
in
in
the
head.
So
when
you
do
get
locked,
you
actually
see
the
two
authors
there
and
they
are
listed
there
in
the
header.
A
In
the
pretty
view,
if
you
look
at
the
raw
header,
the
option
I
experimented
with
at
try,
it
is
adding
a
new
header
there,
a
new
optional
header
authors,
which
lists
the
two
authors
or
multiple
authors,
even
which
have
also
this
this
particular
commit,
and
this
is
actually
backwards
compatible
to
probably
quite
a
number
of
tools.
I,
don't
know
exactly
because
I
can't
try
all
of
them.
I
try
to
get
up.
For
example,
if
you
push
a
repository
with
this
kind
of
data
to
github,
it
actually
still
works.
A
So,
as
I
said,
you
could
also
add
three
authors,
or
only
one
author.
When
you
are
soloing,
you
could
also
clean
the
author,
so
that's
kind
of
heads
or
commands
are
implemented,
and
this
is
the
scope
of
the
the
patch
I
did
and
the
to
start.
The
discussions
how
to
do
that
so
one
result
of
this
discussion
actually
was
that
adding
this
as
a
header
is
quite
intrusive
and
it's
difficult
to
tell
what
it
breaks.
A
So
we
can
of
course,
check
all
the
tools
which
are
entry
and
gates,
but
there
are
many
other
implementations
alternative
implementations,
let's
actually
area
where
we
would
appreciate
feedback.
So
if
you
are
working
on
something
which
doesn't
use
the
get
tool
itself
to
interpret
commit
headers
I
would
really
like
to
know
how
to
change
like
this
would
break
your
tool.
Would
it
break
implementation
or
not?
Would
it's
a
work?
A
But
it
would
be
much
nicer
if
there
would
be
better
support
so
that
that
you
can
use
the
shortcuts
to
set
this
and
get
automatically
adverse,
and
you
don't
have
to
manually
edit,
and
also
that
that's
with
all
the
commands
with
which
much
and
cherry
pick
and
use
commits
in
different
ways
that
they
preserve
the
automate
this
information
in
some
some
automated
in
structured
way.
So
this
is
kind
of
where
we
are
where
I
am
with
this
idea.
This
concept,
this
implementation
and
where
do
we
go
from
from
there?
A
So
I
see
a
hopeful
future
there
and
I'm
calling
it
hopeful
on
one
hand,
because
I'm
optimistic
that
things
can
be
changed,
that
there
are
better
ways
to
work
with
kids
as
a
programmer,
but
also
because
we
need
some
hope
that
this
actually
works
out,
because
it's
a
lot
of
to
is
not
everything
is
open-source.
We
don't
have
control
about
everything,
so
it's
something
it's
a
journey.
I
would
say
to
to
add
this.
A
So
what
what
I
really
would
like
to
see?
It's
that
we
get
native
supporting
it.
So
this
would
be
amazing
for
for
doing
pepra
gramming,
because
this
would
help
us
work
around
the
issues.
I
showed
this
difficult
commands
or
not
not
correct
or
not
accurate
authorship
information,
so
negative,
supporting
it
would
be
a
great
step
and
I
tend
to
spend
more
time
on
this
experiment
with
with
other
ways
how
to
represent
the
information.
Anybody
is
interested
in
helping
with
that
or
joining
me
in
this.
This
effort
I'm
more
than
happy
to
you
to
collaborate.
A
There
I
mean
it's
it's
about
collaboration,
so
collaborating
on
this
kind
of
features
makes
a
lot
of
sense.
The
other
thing
is
then
support
in
other
open
source
to
its
stuff,
like
it
K
or
other
tools
which
are
around
kids,
which
show
information.
Also,
there
I
think
they're
better
ways
how
to
reflect
this
information,
because
it's
quite
essential
authorship
information
is
at
the
core
of
a
commit
so
or
improving.