►
Description
Greg Lund-Chaix of Tag1 Consulting will take you through the ins and outs of simplifying your development workflows with tools and tips and tricks for git.
By the end of this talk, attendees will learn about tools like ddev to simplify your local development environment and... Git workflow best practices that includes
narrowly focused branching
push & pull often
git merge vs git pull --rebase including NEVER merging your own code
pre-commit code sniffing/linting
and more if available
Meet our speaker:
Greg Lund-Chaix is a Senior Performance and Infrastructure Engineer, with Tag1 Consulting. Greg specializes in performance, security, and devops workflows. Member of the Drupal.org infrastructure team since 2006 and Google Summer of Code mentor from 2006-2015. Greg lives in Portland ready to hit the open water or bike the open trail.
Tag1 Consulting is the 2nd all-time leading contributor to the Drupal platform. Specializing in architecting, optimizing, securing, and delivering large scale systems. We provide expert insight into configuration and infrastructure management, security, performance, HA, disaster recovery, and Drupal development services.
A
Good
afternoon
everyone
can
you
hear
me.
I
want
to
make
sure
okay
welcome
to
our
july
webinar.
I
hope
everybody
is
staying
safe
and
sane.
So
this
month
we,
our
presentation,
will
be
given
by
greg
lund
chai
on
local
development.
Best
practices
he's
he
works
at
tag,
one
consulting
as
a
senior
performance
engineer,
so
hi
greg.
I
know
you're
out
there
hi
everybody.
A
Great
so
before
we
start
your
wonderful
presentation,
I
kind
of
want
to
handle
some
housekeeping
and
kind
of
most
people
who
attend
this
know
what
we
do
drupal
for
gov.
We
are
a
community
of
open
source
advocates
and
we're
interested
in
all
things
open
source.
So,
in
addition
to
the
webinar
we
also
have,
we
have
our
yearly
conference,
drupal
govcon
and
this
year,
due
to
the
covet
pandemic,
we'll
we
will
be
having
it
virtual
september
24th
through
the
25th.
A
We
also
do
the
gov
summit
at
drupalgovcon.
That
was
last
week.
Some
of
you
may
have
attended
that
and
we
do
the
global
training
days.
So,
if
you're
interested
in
any
other
information,
please
contact
us
at
drupalforgov
gmail.com
and
we
also
are
available.
We
have
social
media
accounts
on
twitter
and
slack
and
if
you
miss
any
of
the
webinars-
and
you
are
interested
in
catching
up
on
those,
we
upload
these
immediately
to
youtube
and
we
also
they're
also
available
on
drupal
recording
initiative
and
drupal's
tv,
curated,
playlist
and,
lastly,
important
information.
A
If
you're
interested
or
your
company
is
interested
in
sponsoring
drupalgovcon,
please
sign
up
for
the
newsletter.
I
have
a
url
here,
but
you
can
also
visit
drupalgovcon
for
more
information
and
and
so
this
pandemic,
although
it
is
not
the
best,
it
is
also
provided
opportunities
to
attend
other
conferences,
so
flyover
camp
and
atlanta
drupal
camp
will
be
held
online
and
they
their
last
call
for
drupal
camp
session.
A
A
A
A
A
B
Thank
you
well,
hi,
everybody
and
yeah
welcome
to
quite
literally
the
middle
of
the
columbia
river
in
portland
oregon.
I
live
on
an
island
in
the
middle
of
the
river,
so
yeah
you
know.
Hopefully
we
won't
wash
away,
but
it's
you
know
it's
summer.
Time
probably
won't
happen.
So
thank
you
very
much
for
that
intro
and
yeah,
so
yeah
just
to
be
clear,
yeah
tag.
B
One
is
one
of
the
companies
that
kind
of
collects
drupal,
core
contributors
and
so
behind
aqua
we're
the
second
leading
contributor
in
aggregate
for
tag.
One
people
not
me
personally,
I
actually
have
very
few
because
I'm
an
infrastructure
person.
I
actually
have
very
few
bits
floating
around
in
drupal
itself.
Most
of
my
commits
you'll
find
in
the
drupal.org
infrastructure
instead,
so
thank
you
yeah.
I
I've
done
talks
similar
to
this
at
drupalgovcon
and
that's
a
conference
near
and
dear
to
my
heart.
B
So
if
you
all
can
make
it
to
that
conference,
please
do
so
because
it
is
a
wonderful,
wonderful
show
and
also
I
ask
that
if
you
have
questions
there
will
be
several
places,
because
this
talk
is
kind
of
in
three
parts.
There
will
be
several
places
where
I
can
pause
and
kind
of
talk
about
and
respond
to
questions,
and
things
like
that.
So
please
put
your
questions
in
chat.
B
It
can
help
if
you
put
a
q
colon
in
front
of
them
because
it
makes
it
a
little
easier
to
spot
in
among
the
chit
chat
and
feel
free
to
pop
in
and
speak
up.
If
you
don't
get
your
question
answered,
so
we're
gonna
talk.
Let
me
let
me
see,
and
I
got
my
screen
share
up,
and
so
we,
yes,
we
want
to
stop
that.
I
didn't
realize
that
was
still
sharing
right.
B
So
this
is
a
talk.
I
do
a
lot
in
person
and
it's
and
it's
usually
a
very
interactive
one
where
I
ask
people
to
raise
their
hands
and
things
like
that.
So
I
will
try
to
do
that,
but
you
know
obviously
it's
a
little
little
harder
to
do
here.
So,
yes,
we
are
here
to
talk
about
local
development
and
some
of
the
tools
a
little
bit
oops,
let's
get
clicked
onto
the
right
window.
There
we
go
so
as
like.
B
I
said
I
am
a
senior
performance
engineer
which
is
kind
of
one
of
those
catch-all
titles
that
we
have
here
on
our
infrastructure
team.
I
do
a
lot.
I
do
a
lot
everything
from
devops
to
to
infrastructure,
to
performance
to
security.
We
do
a
lot
of
work
with
organizations
where
maybe
they've
they've
grown
and
they're
feeling
growing
pains
things
like
you
know.
B
Maybe
they
had
a
development
team
over
one
or
two
people,
and
then
you
know
they
were
successful,
which
is
a
wonderful
thing,
but
it
meant
that
they
grew
their
team
to
five
people
or
ten
people
and
they
started
running
into
problems
where
their
workflow
didn't
scale
with
their
team.
And
so
basically
I
get
to
have
a
lot
of
fun
because
we
I
get
to
come
in
tag.
B
So
that's
a
very
important
thing,
which
is
why
I
tend
to
do
talks
like
this,
because
this
is
the
kind
of
thing
I
do
for
organizations
as
well,
so
we
are
going
to
cover
come
on.
There
goes
basically
three
basic
areas.
First,
one
is
local
development
environments.
How
to
run
your
code
and
things
like
that
locally
on
your
workstation,
rather
than
having
to
push
up
to
a
server
to
do
your
development
up
there?
I
have
something
I
call
the
four
rules
which
talk
about
some
basic
four
basic
rules,
obviously,
for.
B
Keeping
the
third
piece
of
the
talk
is
gonna,
be
some
easy
things
you
can
start
doing
right
now
with
git.
That
will
help
you
avoid
headaches
and
problems.
You
know
avoid
things
like
messy,
merge,
conflicts
and
things
like
that,
and
so
some
of
these
techniques
will
help
you
prevent
these
problems
before
they
happen
in
the
first
place
and
they're
things
that
don't
take
a
lot
of
work,
they're,
just
a
little
bit
different
way
of
doing
something.
B
So
first
things
first
and
yes,
that
is
beautiful
city
of
portland.
In
the
background,
it
looks
exactly
like
that
this
picture
from
me
use
a
few
years
ago,
but
that
it
looked
almost
exactly
like
that
last
night.
So
there
are
a
couple
of
tools
that
we
use
a
lot
right
now.
D-Dev
and
lando
are
both
excellent
tools.
They
both
have
some
nice
integrations
with
things
like
pantheon.
I
think
some
of
them,
I
think,
there's
some
awkward
integrations
as
well.
B
I
don't
have
any
current
ocular
customers,
so
I
haven't
worked
with
that
recently.
But
these
are
both
tools.
They
are
both
open
source
tools.
They
are
completely
free
to
use
that
you
can
start
using
right
now
to
spin
up
a
local
development
environment
and
you
don't
have
to
then
mess
with
things
like
map
or
running
mysql
and
apache,
and
things
like
that
under
your
on
your
own
machine
directly,
it's
nice
because
the
these
are
container
based.
B
They
they
are
generally
based
on
docker,
and
so
it's
it's
a
good
thing,
because
the
containers
are
then
professionally
managed.
They
they're
the
ones
that
manage
the
container
images
and
the
containers
look
very
much
like
what
you
would
see
in
any
production
environment
out
on
the
real
functioning
servers
and
for
me
as
a
devops
and
infrastructure
guy.
That's
a
very
important
thing,
because
for
years
we've
had
a
problem
where
something
would
be
fine
in
development,
but
because
the
versions
of
php
didn't
match
you
know.
Maybe
it
was
you
know
in
that
days.
B
You
know
it
was.
You
know,
php,
five,
four
or
five
six,
or
something
like
that.
You
know.
Maybe
a
php
version
didn't
match
or
a
php
extension
didn't
exist
or
existed
in
one
place,
but
not
in
another,
and
those
inconsistencies
always
led
to
problems
on
deployment
where
it
worked.
Fine
in
development
rollout
in
a
deployment
and
oh
gosh
everything
blows
up
when
it
gets
onto
the
server
so
tools
like
originally
vagrant,
although
vagrant
is
kind
of
passing
because
it's
cumbersome,
it
was
a
great
tool.
B
B
B
Let
me
pop
over
to
my
terminal,
okay,
so
let
me
make
that
a
little
bigger,
that's
a
little
small.
So
I
have
a
very
basic-
and
I
do
mean
very
basic
droop
composerized
drupal
8
skeleton
here.
So
this
is
a
checkout
of
a
repo
that
has
pretty
much
nothing,
but
some
placeholder
web
directories
for
putting
my
custom
code
in
a
readme
and
the
composer
file
for
actually
building
drupal.
B
So
if
I
do
a
composer
install
and
of
course
you
know-
I
can
type-
you
know
gazillion
words
a
minute
when
nobody's
watching
me,
but
as
soon
as
somebody's
watching
me,
I
typo
everywhere.
Right
isn't
the
way
it
always
works.
So
this
is
a
pretty
standard
boom.
There
we
go
it's.
You
know
we
and
we
now
have
drupal.
If
we
look
whoops.
B
We
can
see
yep
look
there,
it
is
there's
the
vendor
stuff.
There's
the
web
stuff
in
there,
that's
drupal
core
all
the
goodies,
and
I
I
will
post
a
link
to
this
repo.
If
you
really
want
it,
it's
it's
a
pretty
standard
thing.
The
only
change
I've
made
from
the
recommended
quadruple
one
is
I
added
coder
and
drush
to
it.
So
it's
a
nice,
simple
template
that
I
use
pretty
much
for
starting
up
new
drupal
projects.
B
So
now,
if
I
were
not
using
something
like
dev,
I
would
need
to
then
set
up
my
apache
and
my
sql
and
all
that
sort
of
stuff.
Just
so
that
I
could
have
a
v
host
locally,
that
I
could
point
to
this
and
have
php
writing
and
my
sql
and
that
always
breaks
that's,
always
a
pain.
It
always
takes
a
lot
of
work.
B
So
what
I'm
going
to
do
instead
is
I'm
going
to
tell
ddev
to
set
up
now
d
dibs,
pretty
smart,
it's
going
to
look
at
the
directory,
it's
in
and
say
you're
in
a
directory
named
d4g
demo.
So
I'm
betting.
This
is
the
name
of
the
project
we
want
to
use.
It
does
a
little
poking
around
and
says
it
sees
a
web
subdirectory
there.
So
I
bet
that's
your
web
subdirectory,
it's
your
doc
group
and
oh
look.
B
It
looks
like
you
have
drupal
8
in
the
side
there
do
you
want
to
do
drupal,
8,
that's
it
it's
set
up,
so
we
just
tell
ddev
to
start
up
the
containers
if
you
have
not
run
ddl
before
this
will
take
a
couple
of
minutes
because
it
has
to
actually
pull
down
the
containers.
It's
nothing
to
compare
to
what
it
was
like
than
say.
B
Vagrant
days
where
you
had
to
pull
down.
You
know
gigabytes
worth
of
image.
These
containers
are
quite
small.
In
the
you
know,
a
few
megabyte
size
and
what
you'll
see
is
you
have
a
box
up
and
running
now?
Let
me
see
if
I
can
so
if
I
click
over
I'll
just
share
over
to
this,
there
we
go
and
we
now
have
a
fully
functional
drupal
site,
ready
to
do
our
thing
so
and
that's
without
doing
any
configuration
at
all.
B
B
What
you'll
see
is
there's
a
conv,
a
d
dev
creates
a
config
file
and
this
is
get
ignored,
but
it
doesn't
have
to
be,
and
the
nice
thing
about
this
is
when
you
get
into
larger
teams
and
things
like
that,
maybe
you
have
an
infrastructure
team
or
something
more
complicated.
You
can
actually
have
you
know
your
devops
and
infra
people.
B
If
they're
separate
from
the
developers
that
are
working
on
this
to
come
in
and
customize
this
to
say,
oh
hey,
you
know
we
actually
need
to
be
running
php
73
in
these
containers
so
that
the
local
ddiv
environment
will
match.
What's
up
on
your
staging
and
production
servers,
so
here's
an
opportunity
where
we
can
do
a
whole
bunch
of
stuff
a
whole
bunch
of
customization
again.
This
is
this
is
a
bit
of
a
deep
dive.
B
I
don't
want
to
necessarily
go
all
the
way
into,
but
we
can
check
in
this
configural
and
then,
when
anybody
on
the
development
team
or
the
devops
team
who
checks
out
this
repo
to
work
on
it,
they
don't
even
have
to
do
the
ddf
config,
because
it's
already
all
pre-configured
and
it's
pre-configured
to
match
the
say,
mariadb
version,
you
know
my
sql
version
that
you're
using
in
production.
So
therefore
all
they
have
to
do
is
clone
the
repo
run,
dweb
start
and
they
have
the
boxes
up
and
running.
B
So
this
is
a.
This
is
a
huge
headache,
saver
for
a
lot
of
people
and
I'm
gonna.
I
realize
I
can
talk
really
fast
and
I
just
covered
a
whole
bunch
of
stuff.
So
I'm
gonna
pause
for
a
moment
and
see
yes,
there's
would
it
would
it
be
require
what
would
be
required
to
set
up
a
second
database
for
migration
purposes?
B
There
are
a
couple
of
ways
to
do
it
and
it
depends
on
whether
you
need
to
codify
the
database
setup
in
that
there
is.
There
is
a
full-on
docker
container
that
is
running
mysql
or
actually
it's
mariadb.
In
this
particular
case,
but
whatever
database
you
have
root
on
that,
so
you
can
create
other
databases
and
do
whatever
you
need
to
do
so
it's
a
little
more
complicated.
Yes,
you
can
do
it
in
the
configs,
because
we
also
have
let
me
pop
up
here.
There's
also
a.
B
There's
a
full
docker
compose
in
here.
So
if
you
have
somebody
who
has
the
the
docker
chops,
you
can
go
ahead
and
set
this
up
and
have
you
know
a
second
database
container,
even
if
you
really
wanted
to,
but
it's
entirely
possible
to
set
up
multiple
databases
under
this
structure
and
have
them
automatically
provisioned.
B
Oh,
how
do
you
move
into
production?
Oh
okay,
boy!
That's
that's!
So
much
more
complicated!
So
generally,
we
would
probably
be
doing
that
in
something
like
ansible
or
chef,
or
maybe
puppet
salt
stack.
You
know
and
some
sort
of
config
management
tool,
so
that
one
is
a
much
more
complicated
thing,
but
it
is
entirely
possible
to
have
ansible
an
ansible.
B
For
example.
I
use
ansible
most
so
I'll
use
that
one
as
an
example,
but
it
should
work
in
any
of
them,
have
an
ansible
role
that
would
set
up
the
database
and
then
you
could
have
an
inventory.
That
is
both
your
look
for
both
your
local
and
your
upstream
dev
stage,
prod
servers
and
then
apply
those
changes
to
both
locations.
When
you
run
the
config
management
tool,
it's
probably
possible
to
do
this
in
this.
I
wouldn't
necessarily
recommend
it,
because
this
would
apply
only
to
the
local
environment.
B
B
B
And
then
you
know
in
the
cycles,
we
can
use
the
container
images
that
we're
pushing
up
to
production
here
as
well.
It
gets
a
little
bit
complicated
because
you're
a
little
bit
of
a
chicken
and
egg
thing,
because
the
build
is
based
on
the
code.
You're
writing,
but
the
base
container
images
can
be
the
same
base.
Container
images
that
you're
using
up
on
your
servers
can
also
be
used
in
the
ddev
config
locally.
B
B
That's
a
very
rare
situation
and
almost
every
platform
we
work
with,
discourages
that
because
that's
a
very
dangerous
thing
to
do,
because
you
can
accidentally
overwrite
production
with
your
local
things
like
that.
So
generally,
what
we
see
is
are
kind
of
two
one-way
streets.
We
have
a
one-way
street
of
code
going
from
local
two-row,
remote
and
a
one-way
street
for
data
being
the
database
and
files
coming
only
down
from
remote
to
local
and
never
the
other
way
around
it's
possible,
but
definitely
not
recommended.
B
So
it
really
depends
to
get
back
to
your
question
as
far
as
syncing
content
and
database,
okay
yeah.
So
on
on
acquia.
Yes,
I
I
haven't
had
a
chance
to
really
work
on
ddev
with
aquaria.
Recently
but
the
the
dw
team
is
very
supportive,
they're
very
open
and
they
are
an
open
source
team
and
they
are
very
much
a
drupal
organization.
There
are
some
drupal
core
committers
working
for
them
and
they
have
a
excellent
documentation
and
an
excellent
slack
channel.
B
B
B
Okay,
I'd
like
to
talk
about
the
four
rules
and
the
four
rules
are
pretty
simple
things
and
this
kind
of
harkens
back
to
a
process
called
git
flow
or
github
flow.
There
are,
there
are
a
few
other
names
for
it.
What
I've
done
over
the
years
in
working
with
organizations
is
I've
kind
of
distilled
it
down
even
more,
because
even
github
flow
can
be
kind
of
heavyweight
on
a
small
team.
B
When
you
only
have
a
team
of
say
three
or
four
people,
it
works
great
in
large
teams,
where
you
have
dozens
of
developers
working
on.
You
know
multiple
things
all
at
once,
but
a
streamlined,
simplified
version
is
probably
much
better
for
a
smaller
team
because
it
githubflow.
Has
you
go
through
a
lot
of
processes?
B
This
will
save
you
uncounted
headaches
when
you're
dealing
with
merge
conflicts
and
things
like
that
when
you
have
multiple
people
working
on
a
repo,
because
if
everybody's
working
in
a
branch
there,
they
don't
have
the
ability
to
affect
what
you're
working
on
until
we
reach
the
point
of
doing
a
pull
requested,
merge
the
there
are
other
reasons
that
I'll
get
to
get
into
in
a
minute.
But
this
is
kind
of
you
know
it
it.
B
It
may
seem
like
really
basic
stuff
that
a
lot
of
people
think
well
yeah,
of
course,
but
you'd
be
surprised
how
many
organizations
I
work
with
where
we
have
five
or
six
or
seven
or
ten
developers,
all
working
directly
on
main
or
master
or
the
the
primary
development
branch
rather
than
a
task
specific
branch,
one
that
is
just
for
the
particular
feature
or
issue
or
whatever
that
you're
working
on,
and
invariably
we
get
conflicts.
We
get.
B
B
So
let
me
just
go
ahead
and
merge
my
you
know
my
my
develop
whatever
development
branch
into
master
and
move
on,
but
this
more
than
any
other
thing,
even
if
it's
just
two
minutes
for
some
for
asking
a
colleague
to
say,
hey,
look
at
this
is
this
okay.
If
it's
okay,
merge,
it
builds
that
habit
of
code
review
reviewing
of
openness
and
of
having
more
than
one
set
of
eyes.
B
Looking
at
everything,
it's
saved
me
so
many
times
I
mean
I've,
been
I've
been
doing
work
on
on
stuff
for
on
this
kind
of
stuff
for
25
years,
and
even
last
week
I
had
one
of
my
interns
review
some
code
that
I
was
working
on.
That
was,
there
was
some
config.
You
know
some
answer
code
for
config
management
on
some
production
servers
and
he
caught
a
typo.
B
It
seemed
to
work
fine,
but
there
was
a
typo
in
there
that
would
have
applied
a
change
that
was
meant
for
development
to
get
pushed
to
production
and
my
intern
caught
that.
So
you
know
I
don't
care,
you
know
whether
you're
brand
new
you
haven't.
You
know
only
been
developing
six
months
or
I've
been
doing
this
for
decades.
This
will
save
your
butt.
I
swear
to
you
so
always
have
somebody
else
on
your
team.
Just
take
two
minutes
to
look
at
what
you're
doing
and
merge
it.
B
The
only
time
changes
are
made
on
a
server
should
be
when,
via
version
control,
so
you
know
you
push
your
changes
to
get
and
then
whatever
deployment
tool
you
have,
whether
it's
you
know,
logging
in
manually
and
doing
a
get
pull
on
the
server
or
you
know
using
jenkins
or
whether
you're
using
a
ci
or
whatever,
whatever
those
tool
is.
Your
tools
should
be
pulling
the
code
onto
the
server
and
updating
the
codes
on
the
server,
not
a
person
going
in
and
manually
touching
it.
B
It's
gotten
to
the
point
where
I
rarely
actually
touch
servers
and
I'm
the
one
that
actually
is
managing
these
servers,
but
I
never
log
into
them
directly.
I'm
always
logging
into
them
doing
doing
whatever
tasks.
I
need
to
do
whether
it's
deploy
new
code,
whether
it's
deploy
new
configuration,
whatever
I'm
always
doing
that
through
another
tool
and
that
tool
is
always
codified
and
that
code
itself
is
being
reviewed
and
poll
request.
B
B
Rule
4
the
main
branch,
whatever
you
call
it
master
main,
whatever
I've
been
migrating
to
maine
I'm,
given
the
connotations
of
the
term
master,
so
always
always
deployable,
just
assume
that
at
any
given,
second,
whatever
it
mean,
could
be
deployed
to
the
server
without
warning
and
that's
a
good
thing
to
keep
in
your
head
one,
because
that
makes
things
like
continuous
integration,
continuous
deployment,
much
easier.
It
reduces
that
friction
getting
code
from
dev
and
test
into
production,
because
everybody.
B
B
I'm
not
dying
here
when
you're
reviewing
code,
that's
in
a
pull
request
or
a
merge
request
assume
that
as
soon
as
you
hit
that
merge
button
some
trigger
and
push
that
to
production,
even
if
it
isn't
actually
going
to
do
that
and
having
that
mindset
means
that
the
that
sort
of
quality
control
mindset
starts
to
spread
and
looks,
is
more
into
it
or
into
the
process.
And
it
will
save
you
from
headaches
down
there
again.
B
You
know
you
don't
ever
want
to
say,
merge
something
and
then
like
send
out
an
email
to
everybody.
Saying
don't
deploy
this
until
this
already,
because
yeah
you're
going
to
get
yourself
in
trouble.
So
you
want
to
make
sure
that
when
you
have,
you
know,
say
multi-dependent
things
and
maybe
they're
all
in
separate
branches.
B
B
Otherwise
yeah
you're
going
to
come
out
with
inconsistent
deployments
and
things
are
going
to
break.
So
those
are
the
four
rules
they
have
aged
remarkably.
Well,
considering
I
wrote
them
the
first
time
about
15
years
ago,
but-
and
you
know,
some
of
things
have
changed
a
little
bit,
especially
the
the
editing
on
servers,
but
for
the
most
part,
these
four
rules
just
kind
of
keeping
them
in
your
head,
as
you
go
through
your
day-to-day
workflow
make
the
lives
of
everybody,
especially
the
infrastructure
people,
because
I
admit
this
is
very
self-serving.
B
On
my
part.
In
for
people,
when
these
rules
aren't
followed,
our
jobs
become
exponentially
harder
because
we
have
unexpected
outages.
We
have
you
know
we
have
reversions,
we
have
you
know
all
sorts
of.
We
have
merged
conflicts,
we
have
all
sorts
of
problems
when
stuff
gets
pushed
out
to
product
to
stage
or
production
and
goes
from
the
private
development
environment
to
a
more
public
environment
that
is
shared.
B
I
don't
know:
what's
going
on
here:
okay,
sniffing
and
linting,
yes,
okay!
Well,
let's,
let's
move
on
then
I'm
going
to
get
on
to
my
next
bit
and
which
will
include
some
of
that
and
then
we
can
circle
back
to
this
at
the
end
for
q.
A
if
we
need
to
here
are
some
simple
things
you
can
do
right
now.
That's
so,
let's
say
I'm
working
on
a
feature
and
I've
got
a
module
that
I'm
working
on.
Okay-
and
this
might
be
what
my
workflow
every
day
would
look
like.
B
Thank
you,
so
I
prefer
rebasing
to
merging.
For
a
couple
of
reasons.
A
git
merge
adds
a
a
merge
commit,
so
it
closes
up
your
history,
which
oh
am
I
breaking
up:
yeah,
okay,
hopefully
that's
a
minor
thing.
Hopefully
it'll
come
back.
Am
I
okay
now
all
right?
So
hopefully
it
was
an
intermittent
thing.
So
the
reason
I
prefer
pull
to
or
I'll
pull
rebased
is
the
pole.
Rebase
does
not
make
a
merge
commit.
B
What
a
pull
rebase
technically
does
is
rewinds
back
to
the
point
where
you
diverged
from
main
pulls
it
forward
apply.
You
know
in
sequentially,
applying
all
of
the
commits
that
have
made
since
you
broke
away
and
then
reapplying
your
changes
on
top
okay,
hopefully,
to
stick
to
this,
the
joys
of
living
in
an
island
there's
only
one
cable
going
out.
B
Let's
hope
it
sticks
with
us
here.
So
the
rebase
basically
forwarding
your
start
point
to
the
point
of
where
maine
is
right
now
and
because
it
doesn't
clutter
up,
it
makes
things
a
lot
easier.
The
other
nice
thing
about
it
is
when
you
do
it.
If
the
rebase
runs
into
a
problem,
you
get
to
fix
it
internally
locally,
which
means
more
than
likely
you're
going
to
fix
any
sort
of
merge
conflicts
that
you
that
you're
likely
to
see
before
they
ever
even
get
seen
by
anybody
else.
So
it
make
good
right.
B
It
means
every
time
if
you
do
a
rebase
all
if
you
regularly
rebase
your
your
feature,
branch
or
your
issue,
branch
from
oh,
I
just
realized.
I
typed
something
there
anyway,
if
you're
regularly
pulling
from
main
and
rebasing,
your
pull
requests
are
going
to
look
much
cleaner
and
you're,
going
to
look
good
to
your
co-workers,
because
you're
going
to
have
a
nice
clean
and
you're
never
going
to
get
well.
Never
okay!
B
So
one
of
the
other
things
you'll
notice
here
is
okay,
you
know
I've.
So
every
morning,
when
I
sit
down
on
my
desk,
I
check
out
the
branch
I'm
working
on.
I
immediately
do
a
rebase
origin,
main
or
origin,
whatever
to
pull
in
everything.
Everybody
else
has
done
in
the
last
couple
of
days,
then
I
go
ahead
and
do
my
work
for
the
day,
because
99.9
percent
of
the
time
that
poll
does
absolutely
nothing
because
they're
all
working
on
other
stuff
other
than
what
I'm
working
on.
B
B
B
You
would
be
amazed
how
much
and
how
many
headaches
this
prompt
has
saved
me.
There
are
a
couple
of
things
here
and
the
links
here
are
are
to
a
git
focus.
Prompt
that
is
actually
was
is
actually
part
of
git,
so
it's
available
in
in
the
git
source.
It
was
actually
written
by
a
friend
of
mine
at
google
named
sean
pierce,
who,
sadly,
is
no
longer
with
us,
but
that
first
link
creates
that
little
main
in
parentheses.
B
At
the
end
of
my
prompt-
and
that
tells
me
a
number
of
things
that
are
incredibly
useful
one.
It
tells
me
what
branch
I'm
on
so
right
now,
as
you
can
see
on
on
the
little
screen
snap
there
I'm
working
on
main,
which
means
of
course.
Yes,
I
just
roll
number
one.
The
second
thing
it
does.
Is
you
see
the
little
red
percent
sign
on
there?
That
means
my
my
repo
is
dirty.
B
There
are
untracked
changes
in
the
repo
actually,
more
importantly,
there
are
untracked
files
in
the
repo,
so
that
percent
sign
means
there's
something
in
my
repo
that
is
not
has
not
been
added
to
git
yet
so
then,
as
you
see
as
I
step
through
these,
you
know,
so
I
made
a
change
to
the
readme
after
I
made
it
change
the
readme.
The
prompt,
updated
shows
me
a
little
red
asterisk.
B
B
It
okay,
so
by
doing
a
git,
add
that
asterisk
changed
to
a
plus
the
little
green
plus
is
telling
me.
I
have
staged
changes
that
have
not
yet
been
committed
and
when
I
do
a
git
commit
that
little
plus
goes
away
now
in
one
way.
This
is
not.
You
know
this.
This
little
example
is
isn't
the
best,
because,
ideally
I
should
just
see
maine
with
nothing
in
red
after
it,
because
that
little
red
is
telling
me.
I
have
a
dirty
repo
there's.
B
There
are
things
floating
around
in
my
repo
that
aren't
tracked,
which
means
there's
a
potential
that
either
I
forgot
to
add
a
file,
maybe
there's
a
dependency
that
exists
in
my
local
that
doesn't
exist
upstream,
something
like
that.
So,
whenever
you're,
you
know
one
of
the
real
benefits
of
having
a
prompt
like
this,
is
that
whenever
you're
working
and
you
see
a
you
know,
you're
a
red
or
you
know
a
red
percent
or
a
red
asterisk
or
a
green
plus.
That
means
there's
stuff
still
needed
to
be
done.
B
The
ideal
state,
when
you
do
a
git
push
should
be.
You
should
see
nothing,
but
you
know
your
your
branch
name
in
green
and
nothing
else,
and
so
that
that
will
save
you
some
headaches,
because
it
is
a
nice
visual
indicator
of
hey.
You
sure
you
haven't
forgotten
something
there
or
hey.
You
realize
you're
working
on
maine,
you
probably
shouldn't
be
there.
You
should
probably
be
over
somewhere
else.
B
I'm
going
to
pause
for
a
second,
because
I
see
a
couple
of
questions:
is
it
possible
for
some
team
members
to
do
a
rebase
and
others
merge?
Yes,
it's
best
to
be
consistent,
so
everybody
uses
the
same
one,
but
the
only
real
difference
from
a
workflow
standpoint
for
people
for
people
other
than
the
person
doing
say
emerge
is
they'll
see
the
merge
commits.
So
it's
entirely
possible
that
if
somebody
prefers
doing
a
merge,
that's
fine.
They
may
hear
a
little
grumbling.
B
B
Yep
we
got
the
answer:
okay,
excellent,
so
any
other
questions,
real
quick.
I
mean
this
one
is
you
know
this
is
pretty
simple.
The
links
are
here:
you're
welcome
to
use
either
of
them.
If
you
want
or
don't
laugh
in
my
face,
I
don't
really
care
okay
code
sniffing,
so
it
helps
that
I'm
a
fan
of
the
coder
module,
doug
green,
who
wrote
it
tag
one.
He
is
a
great
guy
he's
the
one
that
originally
came
up
with
coder
years
and
years
ago.
B
I
think
he
did
it
for
drupal
5.
Originally,
I
want
to
say-
and
coder
is
a
great
way
so
coder
is
designed
to
work
with
phpcs
for
code
sniffing,
and
the
nice
thing
about
that
is.
That
makes
it
very
easy
to
integrate
with
things
like
continuous
integration,
so
we
can
very
quickly
have
a
ci
run
on
every
pull
request
say
that
does
a
coding
standards
review
and
the
nice
thing
is
phpcs,
of
course.
Does
the
standards
index
checking
everything
like
that?
B
But
then
it
will
also
apply
the
drupal
coding
standards
which
are
at
this
point
rather
extensive.
So
this
is
and
that
link
right
there.
The
first
link
on
the
drupal.org
is
a
great
tutorial
on
exactly
how
to
get
that
installed
again.
I
could
probably
do
a
whole
talk
on
this,
so
I
don't
want
to
go
too
deeply
into
it.
B
Given
that
we're
you
know
what
15
minutes
from
the
end,
I
want
to
make
sure
I
have
enough
time
to
talk
to
folks,
but
just
by
doing
a
composer
choir,
coder
and
com
and
the
dealer
direct
php
code,
sniffer
and
composer
installer.
What
that
does
is
that
actually
just
does
some
of
the
back
end
stuff
needed
in
order
to
integrate
phpcs
with
coder
to
make
it
yes,
we
yeah
we
can.
We
can
consider
doing
that.
B
B
So,
even
if
you
do
nothing
else
other
than
phpcs
and
then
using
the
command
lines
that
are
giving
you
there
on
the
on
the
drupal.org
tutorial
link,
you
can
just
run
that
at
any
time
it
will
scan
you
know
whatever
files
you
tell
it
to
scan
and
it
will
tell
you
whether
they
comply.
You
know
whether
they
have
any
syntax
errors,
whether
they
comply
with
triple
coding
standards,
all
those
goodies.
So
just
doing
that
alone,
a
major
level
up
that
again
will
make
you
look
very
good.
A
B
B
B
B
So
it's
a
super
super
nice
thing
and
it's
it
really.
It
basically
involves
dropping
a
file
into
a
certain
spot
in
the
dot
get
directory
of
your
local
repo.
It's
a
little
fidgety
because
you
do
have
to
put
ground
in
the
git
directory
and
put
it
in
the
right
place,
and
you
will
probably
need
to
change
some
paths
and
things
like
that
to
fit
your
local
environment.
B
Yes,
I
will
post
the
link
to
the
starter
files.
Yes,
and
I
will
also
post
a
link
to
all
of
these
slides,
so
you
have
every
url
in
them,
and
I
think
everything
I
talk
about
here
is
is
in
is
has
a
link
and
if
it
doesn't,
I
have
my
contact
into
it
at
the
end,
and
you
can
get
a
hold
of
me
and
I
will
share
it
with
you.
B
Pre-Commit
is
a
framework
that
is
kind
of
it's
a
kind
of
a
generic
framework
that
allows
you
to
add
arbitrary,
commit
hooks
by,
but
just
by
adding
them
to
a
yaml
config
file
that
says:
hey
go
grab.
This
commit
hook
from
here,
go
grab
this
command
hook
from
there
and
run
them
all
before
before
a
pre-commit.
B
This
is
what
I
personally
use
when
I
work
on
my
ansible
repos
for
infrastructure,
because
it's
infrastructure,
paranoid
and
anybody
who's
been
to
one
of
my
talks
before
knows
that
infrastructure
people
are
two
things:
we're
lazy
and
we're
paranoid,
and
so
this
does
both
for
me
right
because
it
does
all
the
linting
and
work
for
me
and
I'm
paranoid.
I
don't
want
to
accidentally
push
something
up
into
my
infrastructure,
repo,
that's
going
to
break
a
server
or
20..
B
So
what
so?
What
I've
done?
In
my
pre-commit
for
my
ansible
stuff
is
I
use
ansible
lint
for
linting.
My
ansible
funny
thing
it's
great
tool
by
the
way.
If
anybody
works
with
ansible
ansible
lint
is
good
stuff.
It
automatically
runs
an
ansible
lint
with
a
free
set
group
of
rules
against
every
commit
that
I
make
against
my
against
my
ansible
repo.
B
B
B
Tig
is
a
graphical
viewer,
it's
a
text-based
viewer
for
forget
and
it
shows
you
the
git
log,
so
you
can
go
through
and
look
at
things.
The
really
nice
thing,
okay,
so
and
it's
nice,
because
I
don't
have
it
here
on
this
repo-
and
I
I
didn't-
I
don't
have
a
repo
that
has
a
lot
of
mergers
and
poles
in
it
that
I
can
really
show
publicly,
but
it
will
actually
show
you
the
tree
of
you
know
how
all
the
various
branches
interrelate
to
each
other.
B
So
it's
a
sweet
little
tool,
it's
open
source.
You
can
install
it
from
any
number
of
package
managers
for
whatever
platform
you're
on
and
it
just
works,
and
it
saved
me
so
much
work
and
the
nice
thing
is
you
can
do
stuff.
You
can
also
do
things
that
a
lot
like
what
you
can
do
in
git,
so
you
can
do
things
like.
I
take
blame
which
works
a
lot
like
a
get
blind,
except
when
it
gives
you
a
nice
interface
and
two
you
can
do
things
like
it
will
give
you.
B
B
The
second
thing
is,
I
I
acknowledge
not,
everybody
is
a
command
line
die
hard
like
I
am
you
know
I
I
I
came
out
of
the
old
unix
days
in
the
late
90s
or
the
early
90s,
so
yeah
we
didn't
have
gooeys
back
then,
and
so
I
got
used
to
working
in
vim
and
things
like
that.
But
I
acknowledge
that
not
everybody
works
that
way,
and
so
you
know,
if
you're,
finding
the
get
command
line.
Frustrating
there
are
a
ton
of
guise
out
there
forget
and
a
lot
of
them
are
very
good.
B
If
you
use
github
the
github
one
is
actually
excellent,
but
even
the
ones
just
for
straight
git
work
pretty
good,
so
I
wanted
to
be
sure
to
post
a
link
to
that.
In
case
there
are
people
who
are
struggling
with
the
git
command
line
work
and
so
then
yeah
the
rest
of
these
links,
I
think,
are
all
things
that
are
pretty
much
talked
about.
Github
flow
there
you'll
see,
so
that's
a
much
deeper
dive
into
what
github
flow
is.
B
As
far
as
workflow
goes,
it's
absolutely
worth
a
read:
it's
not
very
long,
and
even
if
you
don't
adopt
it
entirely,
the
techniques
that
scott
talks
about
in
there
are
very,
very
good
to
learn
and
yeah.
I
think
that
are
that's
all
the
stuff.
I
wanted
to
talk
about.
Yes,
ansible
changes.
Oh
okay,
I'll
try
not
to
diverge
too
often
because
now
you're
into
my
world
generally.
This
is
one
of
the
applications
where
we
still
use
vagrant.
I
I
on
all
my
ansible
stuff.
B
So
it's
similar
in
that
way
in
that
I
do
test
on
a
local
virtual
environment.
The
other
thing
I
can
do,
fortunately,
is
ansible.
Has
a
lovely
dash
dash
check,
which
is
a
no
op,
and
it
will
run
the
particular
role
against
whatever
inventory
you
provided
and
tell
you,
you
know
in
a
no-op
situation
whether
it
would
actually
error
or
not,
let's
see
anything
else.
Oh
I
do
need
to.
Yes,
I
will
post
a
link
to
the
chat
here
for
the
repo.
B
B
So
that
is
the
that
is
my
starter,
repo,
that
I've
been
that
I
was
using
here
for
this
particular
demo
and
you
can
play
around
with
it.
Oh
look
at
that.
Oh
sorry,
about
that.
Somebody
sent
me
a
private
message
and
now
there
we
go.
I
really
gotta
watch
that
okay,
so
we
have
let's
see
where
we
have
about
what
two
minutes
left.