►
Description
Presented by Belén Barros Pena, Interaction Designer, Open Source Design
While I was working as the only designer of the Yocto Project, the embedded Linux engineers in my office did something remarkable. They mustered the patience and the energy to teach Git to yours truly. They did it in stages: they started by how to clone a repository and how to check out its branches, taught me about remotes and how to create my own branches, how to commit my changes, and the etiquette of good commit messages. One glorious day, they decided I was ready to push to a remote repository. By golly I felt powerful. I had mastered Git's mysteries!
Becoming familiar with Git's basic concepts and commands took the best part of 2 years, but it was worth every minute. As a designer, learning Git made me more resilient, more independent and more useful to my development team. Learning Git made me a better designer.
In this talk, I will try to convince developers that they should invest time and effort in teaching Git to the designers they work with, what they have to gain from it, and how to go about it.
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
A
Gotta
tell
you:
it
is
really
scary
from
here
hello.
Thank
you
very
much
for
sticking
around
for
this
talk,
which
is
called
the
art
of
patience
or
why
bother
teaching
it
to
a
designer?
My
name
is
Belen
and
I
love
it
when
they
schedule
my
talks
right
after
lunch,
when
everybody's
getting
nice
and
sleepy
I
will
do
my
best
to
keep
you
awake,
but
I
can't
promise
a
nickname,
I.
Also
gotta
tell
you-
and
this
is
a
bit
of
a
funny
talk
or
a
strange
talk.
You
see.
This
is
a
conference
about
gate.
A
Gate
is
a
version
control
system
that
is
used
mostly
for
a
software
engineering
software
development
purposes,
but
I
am
NOT
a
software
developer.
I
am
an
interaction
designer
and
displayed
to
you.
What
an
interaction
design
and
what
are.what
interaction,
design
ease.
I
have
to
introduce
you
to
someone
this
venerable
looking
man
was
sadly
Bill.
Moggridge
Bill
Moggridge
was
an
industrial
designer.
A
He
was
one
of
the
founders
of
a
very
famous
in
a
design
company
coal
idea
and
he's
credited
with
another
bill
bill
Verplank
with
coining
the
term
interaction
design
back
in
the
1980s
and
what
baby
laws
meant
by
interaction
design
was
quite
simple:
it
was
the
application
of
principles
and
techniques
of
industrial
design
to
software
you
see
when
industrial
designers
go
and
start
designing
a
new
physical
product.
The
first
thing
they
think
about
is
who
is
going
to
use
this
product?
A
What
people
are
going
to
use
it
for
why
they
would
want
to
use
it
and
where,
in
which
context-
and
it's
the
same
with
interaction
design,
which
means
that
interaction
designers
looks
look
at
software
from
the
outside
in
from
the
users
perspective,
because
as
interaction
designers,
we
are
not
responsible
for
building
software
that
works.
That
is
the
rest
possibility
of
software
engineers,
but
we
are
responsible
for
building
software
that
makes
sense
to
the
people
who
use
it.
Now.
You
may
have
noticed
that
I
said
I
didn't,
say
software
that
is
easy
to
use.
A
A
A
It
doesn't
mean
that
it's
gonna
work
for
everybody:
I,
don't
have
a
bag
full
of
magical
tricks
for
you,
I,
don't
even
have
a
list
of
best
practices
or
anything
I
just
have
my
personal
experience
to
share
no
more
and
no
less,
and
the
reason
why
I'm
here
it's
because
I
really
want
to
convince
you
all
to
teach
get
to
all
designers.
You
know
and
if
I
succeed,
if
I
manage
to
convince
you,
all
of
you
will
be
in
the
position
of
having
the
teach
get
to
a
designer's
turn
designer.
A
So
brace
yourselves
because
it
ain't
easy-
and
this
is
a
story
in
three
parts-
I'm
gonna
start
by
telling
you
how
I
learned
get
then
I'm
gonna
tell
you
why
I
think
designers
should
learn
it
and
then
I'm
gonna,
totally
embarrass
myself
by
confessing
to
you
all
how
long
it
took
me
to
learn
it.
You
ready
yeah.
A
So
how
did
I
learn
it?
I
first
came
across
skied
about
seven
years
ago,
when
I
joined
something
called
the
doctor
project.
The
jock.
The
project
is
a
Linux
Foundation
initiative
that
provides
a
set
of
tools
for
creating
and
maintaining
customized
Linux
distributions
for
embedded
devices
between
them
a
build
system.
The
first
time
I
heard
the
sentence.
I,
don't
think
I
understood
any
of
the
words
not
a
single
one
of
them.
Maybe
the
prepositions
and
the
articles
and
stuff
I
didn't
know
what
Linux
was
I
didn't
know
what
a
distribution
was.
A
I
didn't
know
what
an
embedded
device
was
build
system,
no
idea,
so
imagine
the
situation.
Middle
manager
in
big
multinational
tech,
corporation
approaches,
Linux,
engineer
and
says
to
him.
Hey
here
is
this
designer.
She
knows
nothing
about
what
you
do,
but
she's
here
to
help
you
yeah
all
right,
whatever
that's
what
I
would
have
thought,
but
luckily
for
me
that
linux
engineer
didn't
think
that
at
all
his
name
was
Paul,
Eggleton
and
he's
a
very
particular
man.
He
didn't
think
yeah
I
whatever
he
thought
that
the
doctor
project
could
do
with
any
help.
A
In
the
doctor
project.
Say
people
worked
off
the
master
branch
and
they
created
from
it
their
own
working
projects,
imprint
Progress
branches
that
they
could
commit
to
a
work-in-progress
repository
if
they
wanted
and
when
the
work
was
more
or
less
ready.
The
boo
creator
part
said:
send
it
to
a
mailing
list
where
the
contributors
to
the
project
could
review
it,
and
once
they
were
deemed
okay,
they
would
be
merged
back
into
the
master
branch,
I'm
sure
you're,
all
familiar
with
this
kind
of
thing,
and
so
before
I
learned
it
every
time.
A
I
wanted
to
keep
track
of
the
progress
of
they.
We
were
making
in
building
the
web
interface.
I
had
designed
I
had
to
ask
the
developers
to
update
the
application
instance
they
kept
for
me.
So
I
had
to
go
and
say
hey,
but
you
mind
applying
this
changes
because
I
like
to
look
at
them.
That
was
a
real
pain
in
the
ass
for
me,
mostly
because
I
knew
he
was
an
even
bigger
pain
in
the
ass
for
the
developers.
I
was
working
with
you.
A
A
B
A
So
they
taught
me
whatever
I
needed
to
know
they
did
not
organize
a
big
worship
but
a
big
training
session
about
gate.
They
just
stole
me,
whatever
I
needed,
to
know
at
a
certain
point
in
time
to
do
my
job
better
and
I.
Think
this
really
helped.
So
at
that
point,
this
is
what
they
told
me
so
Belen.
We
have
this
a
special
place
where
we
keep
all
our
work
in
progress.
Do
you
need
to
make
a
local
copy
of
that
a
special
place
in
your
computer
and
to
do
that?
A
Do
you
need
to
type
that
on
a
terminal
window,
the
laying
in
that
special
place?
We
have
this
thing
is
called
branches.
They
work
you
want
to
check.
It's
gonna
be
one
of
those
branches.
We
will
tell
you
which
one
and
then
you're
gonna
need
to
select
our
branch
in
your
local
copy
of
the
special
place,
and
to
do
that,
you
have
to
type
this
in
a
terminal
window,
and
then
you
run
the
application.
This
way,
I
obviously
was
cloning,
a
repo
and
checking
out
a
branch,
but
they
didn't
tell
me
any
of
that.
A
They
didn't
use
those
words.
They
just
explained
things
to
me
in
a
way:
I
could
understand
and
I
find
interesting
that
they
did
this
all
the
time
they
continuously
avoided.
The
geek
jargon
kid
has
all
this
jargon
that
is
completely
incomprehensible
to
all
known
gate
people.
It
is
very
off-putting
to
sum
up,
it
scares
the
bejesus
out
of
you
right
so
avoid
it,
avoid
it
like
the
plague
and
just
try
and
explain
things
to
people
in
ways
in
terms
they
can
understand.
A
So
after
I
did
this
and
I
had
to
learn
how
to
update
the
work-in-progress
branches
because
they
were
working
progress
branches,
so
the
developers
were
pushing
changes
to
them
all
the
time
so
I.
If
I
wanted
to
check
those
changes,
I
needed
to
update
the
branch,
so
they
told
me
that
to
do
that,
I
need
to
use
git
pull
and
then
a
few
months
later
they
changed
their
mind
and
they
told
me
that
I
had
to
do
git
fetch.
Instead,
you
know
what
they
didn't
explain
to
me.
A
Why
and
to
be
honest
with
you,
I
didn't
ask
either.
Why?
Because
I
don't
really
care,
you
see,
I,
don't
really
care
about
all
the
intricacies
of
version
control.
Are
you
skipped
on
I
need
to
know
basis,
ok
until
this
day,
and
not
even
very
sure,
what's
the
difference
between
the
tree-
and
this
is
another
good
lesson.
They
didn't
really
bother
that
much
with
the
concepts,
particularly
at
the
beginning.
A
They
didn't
bore
me
with
long-winded
explanations,
about
what
you
know,
pool
wars
or
fetch
Wars
and
say
yep,
and
you
know
I
think
this
is
a
good
thing,
because
these
concepts
are
really
really
abstract
and
they're
really
really
hard
to
grasp.
So
instead
of
grasping,
then,
theoretically,
it
is
better
if
you
just
learn
them
progressively
through
Octus
and
that's
what
happened
to
me
and
it
takes
longer
to
learn.
But
it's
a
more
resilient
where
to
learn
is
a
way
to
learn.
The
sticks.
A
Okay,
after
I
did
that
I
really
wanted
to
start
helping
the
developers
to
change
little
things
in
the
interface
and
to
do
that.
I
had
to
learn
a
whole
bunch
of
new
stuff.
I
need
to
learn
how
to
create
a
branch.
I
need
to
learn
how
to
commit
my
changes.
Some
very
importantly,
how
to
write
good,
commit
messages.
A
This
was
a
lot
of
a
staff
to
learn
so
every
time
that
I
need
something
new,
pulled,
calm
and
sit
down
with
me
and
do
it
with
me,
but
he
didn't
do
it
for
me.
He
would
sit
down
next
to
me,
tell
me
what
to
do
and
I
will
have
to
type
everything
and
do
all
this
stuff,
and
that's
one
of
the
things
that
I
think
really
helped.
They
never
did
things
for
me.
They
things
they
did
things
with
me,
because
Gabe
is
just
too
hard
to
learn
by
observation.
A
You
need
to
develop
muscle
memory
almost,
and
the
only
way
to
develop
muscle
memory
is
typing
the
commands
over
and
over
again.
So
never
do
they
do
things
for
your
designers.
Do
things
with
your
designers
now,
if
you
are
investing
the
time
on
the
effort
to
sitting
in
sitting
with
your
designers,
to
do
things
with
them.
A
What
you're
aiming
for
here
is
to
having
to
do
that
only
once
for
every
new
thing
that
your
designers
are
learning,
so
you
need
to
make
sure
that
your
designers
are
putting
the
best
of
themselves
to
learn
on
the
first
go.
Okay,
that
means
taking
notes.
So
if
your
designer
doesn't
have
a
note
pair
know,
part
with
them
on
a
pen
tell
them
to
go,
get
one
and
encourage
them
to
type
those
notes
and
keep
a
cheat
sheet.
You
know-
and
this
was
mine
that
very
originally
was
called
useful
things.
A
So,
yeah
you
know
make
sure
that
they're
paying
attention
make
sure
that
they
are
taking
notes,
make
sure
that
they
keep
a
kid
cheat
sheet,
so
they
can
go
back
to
it.
Instead
of
annoying
you,
okay,
say:
I
learned
loads
of
other
things.
After
that,
I
learned
how
to
initialize
a
local
directory
to
get
repository.
How
do
how
to
handle
remotes
I,
learn
how
to
generate
patches,
how
to
apply
patches,
how
to
use
cat
eats
and
email
to
send
those
patches
or
mailing
lists.
A
I
learned
how
to
rebase
and
I
even
learned
how
to
fix
conflicts,
my
god,
but
by
then
something
had
changed
because
I
had
grasped
the
basic
concepts
of
get
through
practice.
I
was
spending
less
and
less
time
asking
my
developers
for
advice,
I
had
become
an
independent
learner
of
get
I
had
reached
the
point
where
I
was
able
to
go
to
the
Internet
or
find
out
stuff
by
myself.
A
Whilst
you
reach
that
point,
you
know
you
can
sit
down
and
relax.
Congratulations,
you've
managed
the
pitch
get
to
a
designer.
Well
done.
You
may
have
noticed
something
as
I
was
telling
you
this
a
story.
The
developers
taught
me
how
to
do
everything
from
command
line.
They
didn't
teach
me
how
to
use
one
of
the
many
graphical
user
interfaces
that
exist.
A
Forget
I'm
not
sure
why
they
did
that,
but
I'm
very
grateful
to
them
for
doing
so,
because
before
I
learned
it
with
them,
I
had
tried
to
use
one
of
those
graphical
user
interfaces
and
I
couldn't
understand
a
thing.
They
made
no
sense
whatsoever
and
the
reason
why
they
don't
make
sense
whatsoever
is
because
all
the
graphical
user
interfaces
forget
they
all
expose
its
system
model.
Okay,
and
let
me
explain
to
you
what
I
mean.
A
If
you
took
talk
to
usability
people,
they
will
tell
you
that
a
graphical
user
interface
should
not
reflect
the
way
the
system
works.
What
they
call
the
system
model.
It
should
reflect
the
way
people
think
the
system
works.
What
is
called
the
mental
model
mental
model.
Our
mental
models
are
offered
are
often
inaccurate
and
incomplete
by,
but
they
work
they
work
in
the
sense
that
they
allow
us
to
get
a
staff
bond
without
having
to
know
everything
about
everything,
and
so
our
user
interfaces
should
always
match
the
mental
model.
A
A
Why
would
they
they
never
use
it
for
anything,
and
the
software
developers
do
not
really
have
a
mental
model
for
need
either
because
it
is
part
of
their
job
to
learn
about
the
system
model
itself
and
therefore
there
is
no
mental
model
that
graphical
user
interfaces
come
follow
and
if
you
look
at
them,
they
all
expose
the
way
it
works.
They
will
expose,
they
get
concepts,
they
all
organize
their
content
in
repose
and
they
all
talk
about
branches,
some
patches
and
clones
and
so
on
and
so
forth.
A
If
you
don't
know
what
those
things
are,
these
interfaces
do
not
not
make
sense
to
you.
They
just
are
unusable,
so
teach
your
designers
come
on
lying
it
because
that
will
enable
them
to
use
any
graphical
user
interface
they
want
later
on,
and
it
doesn't
matter
how
much
they
complain
or
moan
about
it.
You
still
teach
them
to
use
command
line,
get
okay.
A
You
see
I'm
a
Fred
that
very
often
doll
laughs
before
you
can
even
start
teaching
it
to
a
designer
you're
gonna
have
to
convince
them
to
learn.
There
are
quite
a
lot
of
designers
out
there
that
do
truly
believe
that
learning
things
like
it
are
not
part
of
their
jobs.
Okay,
I
humbly
nicely,
disagree,
I,
don't
think
the
signers
need
to
know
absolutely
everything
there
is
to
know
about
version
control.
A
This
is
the
same
as
with
product
designers,
private
designers,
the
people
who
design
physical
products
have
a
lot
of
materials
at
their
disposal.
There
are
boots
and
plastics
and
throughout
ceramics-
and
there
is
class
of
fabrics
and
so
on
and
so
forth.
Product
designers
don't
need
to
know
everything
there
is
to
know
about
those
materials.
A
A
The
second
reason
why
I
think
designers
should
learn
get
it's,
because
it
enables
better
collaboration
between
them
and
you
between
designers
and
developers,
and
this
is
Paul
talking
about
collaboration
and
participation,
because
the
idea
is
that
designers
should
beat
your
partners
in
building
ok.
So
this
is
how
it's.
B
Really
about
being
able
to
participate
in
the
development
process,
if
you
have
access
to
the
git
repository
and
know
how
to
make
use
of
it
to
get
your
work
done,
then
you're
able
to
directly
influence
the
thing
that
we're
working
on
and
we're
able
to
work
together
as
well,
because
that's
one
of
the
things
that
get
does
really
well.
It
helps
people
to
if
they
take
advantage
of
it
to
work
together
to
collaborate
as
opposed
but
yeah.
A
A
Are
the
developers
designers
on
their
side
of
the
wall
designed
their
stuff
and
when
their
dog,
they
throw
it
over
the
wall
to
the
developers,
and
then
they
forget
all
about
it
and
the
developers
to
grab
it
and
they
try
to
build
it
as
best
they
can,
but
it
never
occurs
to
them
to
go
to
the
other
side
of
the
wall
and
ask
any
questions
they
may
have.
Some
people
think
that,
just
by
working
or
not
being
in
an
agile
way,
the
wall
go
away.
It
doesn't.
A
This
is
because
the
wall
is
really
not
made
of
bricks.
The
world
is
made
of
attitudes.
Okay,
in
my
opinion,
learning
gift
is
one
of
the
best
way
or
ways
of
attacking
this
wall,
so
by
teaching
it
to
your
designers,
you're,
not
really
trying
to
knock
down
the
wall,
it's
more
like
digging
a
tunnel
under
the
wall.
It's
like
this
sneaky
way
of
undermining
the
wall
and,
in
my
experience,
is
very
very
effective
which
are
aiming
for
is
turning
designers
into
your
partners
during
the
development
process.
B
A
Having
influence
right,
that's
what
you're
aiming
for,
and
the
way
happened
with
with
me
in
the
doctor
project
is
what
is
that
once
I
learned
it
I
was
able
to
impose
this
idea
of
the
scientist
in
the
mailing
list
in
the
same
way
that
when
you
send
patches
from
mailing
list
the
contributors
review
the
code
I
give
you
feedback.
People
have
to
become
used
to
the
fact
that
I
would
take
their
patches
review
their
impact
on
the
design
and
give
them
feedback
and
I
formalize
this,
and
they
just
had
to
live
with
it
influence.
A
Okay,
there
is
one
more
reason
why
I
think
and
think
it
is
really
important
learning.
It
is
very
important.
This
one
is
particularly
interesting
for
you
see
five
years
ago
at
FOSDEM,
and
they
very
very
few
interaction
designers
who
are
involved
in
free
software
got
together
for
the
first
time,
and
none
of
that
meeting
came
something
called
open.
Source
design,
open
source
design
is
a
group
of
people
who
are
advocating
for
the
importance
of
humans,
certain
Design
Center
design
processes
in
free
software
and
also
are
advocating
the
importance
of
free
software
to
mainstream
designers.
A
One
of
them
is
that
they
do
not
understand
many
of
the
tools
that
free
software
projects
use
to
organize
themselves
between
them,
get
okay,
so
by
teaching
them
get
you're
helping
designers
to
get
involved
in
free
software.
To
finish,
how
long
is
it
gonna
take
to
teach
get
to
a
designer
I,
don't
know.
I
can
only
tell
you
how
long
it
took
for
me-
and
this
is
very
embarrassing,
because
this
leap
took
two
four
years
two
years,
but
believe
me
was
worth
every
single
minute
of
it.
So
yeah,
it's
gonna,
be
a
very
long
process.
A
Is
gonna.
Take
a
lot
of
effort.
It's
gonna
take
a
long
time,
but
on
the
other
side
of
the
process,
you're
gonna
have
designers
that
are
very
equipped
to
make
design
decisions
for
your
software
designers,
who
know
how
to
collaborate
better
with
you,
designers
that
can
influencing
meaningful
ways,
the
development
process
and
how
things
are
built
and
designers
who
can
contribute
to
free
software
if
they
want
to,
and
most
importantly,
you
will
have
designers
that
will
be
forever
grateful
to
you
for
teaching
them
get.
Thank
you
very
much
for
listening
people.