►
From YouTube: Git for Static Websites, Ryan Hodson - Git Merge 2016
Description
Streamlining your static website development workflow is easy with Git. Learn the benefits of “going static” for everything from simple Jekyll blogs hosted on GitHub Pages to prime-time commercial marketing websites. We’ll survey the static website landscape, including Jekyll, Gulp, and automated deployment with Git and Heroku. We’ll also explore practical use cases like automatically purging your CDN’s cache with GitHub hooks and containerizing your static site with a backend API.
Ryan Hodson is a marketer, writer, and web developer at CloudFlare. He's written extensively about Git on both his own website, RyPress.com, and as a consultant for technology companies including Atlassian and Syncfusion. Ryan is also a Mac app developer and author of comprehensive Objective-C, Cocoa development, and MathML tutorials.
About Git Merge:
Git Merge is the pre-eminent Git-focused conference: a full-day offering technical content, user case studies and training workshops for Git users of all levels.
Visit: http://git-merge.com/
A
So
today,
I'm
gonna
be
talking
a
little
bit
about
static
websites,
but
most
of
this
talk
is
actually
about
a
new
category
of
content
management
systems
that
I'll
be
presenting
here
for
the
first
time
ever
so
when
I
first
joined
CloudFlare
last
August,
our
marketing
site
deployment
flow
looked
something
like
this.
The
marketing
site
was
completely
integrated
into
the
product
dashboard.
So
whenever
we
wanted
to
publish
content,
we
had
to
publish
the
entire
product,
and
this
only
happened
about
once
a
week.
A
Few
months
later,
we
migrated
our
entire
marketing
site
to
Jekyll
and
separated
entirely
from
our
product
infrastructures.
So
having
a
static,
marketing
site
was
a
great
option
for
us,
because
it
didn't
require
a
whole
lot
of
complicated
CMS
configuration
or
content
migration
or
security
considerations.
A
So
immediately
after
we
went
static,
our
marketing
metrics
improved
dramatically.
Now.
Obviously,
this
spike
in
organic
traffic
isn't
just
due
to
having
a
static
website,
but
this
did
allow
our
velocity
of
change
to
explode.
So,
instead
of
publishing
once
a
week,
we
could
publish
whenever
we
wanted.
We
started
pushing
a
ton
of
content
and
doing
all
sorts
of
a
B
tests
and
creating
dedicated
landing
pages
for
a
bunch
of
different
marketing
campaigns.
A
Me
and
other
marketing
engineer
loved.
This
set
up,
since
all
we
were
dealing
with
was
static,
HTML
and
CSS
and
JavaScript
files.
There
was
almost
nothing
that
could
break
and,
of
course,
this
meant
that
our
InfoSec
team
was
very
happy
because
there
were
fewer
endpoints
that
people
could
attack.
We
also
enjoyed
the
flexibility
of
not
being
tied
to
a
monolithic
framework
like
WordPress
or
Magnolia,
and
finally,
as
a
content
producer.
My
rule
of
thumb
is
that
a
Content
doesn't
exist
in
a
git.
A
So
right
now
we're
in
the
middle
of
a
complete
website,
redesign
for
CloudFlare
comm
and
even
with
a
ridiculous
hockey,
stick
graph
of
organic
traffic.
We've
still
been
questioning
whether
or
not
a
static
website
was
the
right
choice
for
our
new
website
and
the
sole
cause
for
this
uncertainty
was
the
question
of
how
non
developers
would
contribute
content
to
our
website,
so
meet
Lauren
Laurens,
a
marketer
on
our
team,
McCloud,
Flair
and
she's
a
great
strategist
and
has
a
deep
understanding
of
our
product,
but
she's
not
a
developer.
A
So
how
does
somebody
like
Lauren,
edit
our
static
website
when
we
switch
to
Jekyll?
She
took
the
time
to
learn
how
to
do
just
that,
and
it
looks
something
like
this.
So
first
she
had
to
open
up
a
command
prompt
and
I'd
switched
into
her
marketing
site
that
we
cloned
for
her
and
then
check
out
the
master
branch
make
sure
that
branch
was
up-to-date
check
out
a
new
branch
to
store
our
changes
open
up.
A
Now,
that's
a
lot
to
remember
for
somebody
who's,
never
even
seen
a
command
prompt
before
come
on,
captain
that
was
13,
distinct
steps
to
publish
a
web
page
now
most
of
us
here
are
developers.
So
all
of
those
steps
are
already
ingrained
into
our
fingertips.
That's
how
we
write
and
ship
code
every
day
all
day,
but
this
process
just
isn't
fair
to
people
like
Lauren,
and
it's
worth
noting
that
the
hard
part
wasn't
learning
markdown
or
editing
text
files.
It
was
everything
else.
A
So
a
lot
of
static
site
generators
say
that
is
just
a
bunch
of
text
files,
but
that's
actually
never
the
case.
It's
also
understanding
the
command,
prompt
and
get
and
SSH
keys
and
how
to
compile
your
site
and
what
localhost
4000
means.
As
an
industry,
we've
come
full-circle
with
static
sites,
so
used
to
be
that
static
was
it
all
you
could
do
was
write
straight
HTML
CSS
and
maybe
a
little
bit
of
JavaScript.
A
So
if
you
were
a
author
who
didn't
want
to
write
straight
HTML,
that
was
just
too
bad
and
then
WordPress
came
along
and
revolutionized
how
we
made
websites.
It
opened
up
Internet
publishing
to
authors
who
weren't
developers,
which
was
amazing,
but
the
trade-off
was
developers
now
to
set
up
these
kind
of
clunky
systems
of
application
code
and
databases.
So
if
you
were
a
web
developer
that
didn't
want
to
deal
with
PHP
templates
and
sequel
queries
that
was
just
too
bad.
A
So
eventually
developers
went
back
to
building
static
websites,
but
this
time
around
they
use
modern
tools
like
git
and
grunt
and
gulp,
or
the
plethora
of
other
build
systems
floating
around
out
there.
And
once
again,
authors
were
left
out
in
the
cold.
If
you
didn't
want
to
learn
HTML
and
a
bunch
of
git
commands,
so
I
was
just
too
bad,
and
that
brings
us
to
our
current
state
of
affairs,
so
content
services
like
contentful,
comm
and
many
others.
A
Let
otters
edit
content
in
a
friendly
web
interface
and
make
that
content
available
to
static
sites
via
an
API.
Now
this
subtracts
away
the
infrastructure
of
traditional
content
management
systems,
which
is
great,
but
it
means
that
the
burden
is
once
again
shifting
back
onto
the
developer,
needs
to
integrate
these
api's
into
their
build
systems.
So
how
do
we
break
the
cycle
of
trade-offs
between
developers
and
authors?
A
What
if
we
built
a
friendly
GUI
for
all
of
the
developer,
things
that
lauren
had
to
do
to
use
jekyll
and
we
shipped
it
as
a
desktop
application?
Instead
of
as
a
service,
we
get
a
brand
new
kind
of
content
management
system,
so
this
would
be
a
kind
of
tool
that,
instead
of
just
facilitating
authors,
it
actually
turns
authors
into
web
developers,
at
least
from
the
perspective
of
a
git
repository.
A
This
allows
somebody
like
Lauren
to
interact
with
our
static
site
codebase
without
having
to
run
a
bunch
of
commands,
so
I
put
together
a
proof-of-concept
for
what
this
app
might
look
like
I
call
it
Inc
CMS,
because
it's
not
actually
a
content
management
system
at
all.
It's
a
desktop
application
that
allows
non
developers
to
interact
with
the
git
repository
in
the
exact
same
way
that
developers
do
so.
You
can
think
of
it
as
a
text
editor
with
some
buttons
that
run
git,
commands
and
static
websites.
This
might
sound
simple,
but
having
a
friendly
interface.
A
That
is
a
desktop
application
for
all
of
this
makes
it
much
much
easier
for
authors
to
work
with
static
sites.
So
what's
it
look
like
on
first
run,
the
user
is
prompted
for
their
github
credentials
and
the
repository
URL
containing
the
static
site
that
they
want
to
edit.
So
when
you
click
start
editing,
the
app
automatically
clones,
the
origin,
repo
onto
the
user's
local
machine
and
it
solves
any
dependencies
so
like
npm,
install
and
all
this
happens
behind
the
scenes
so
to
the
user,
all
they
saw
was
I
clicked
a
button.
A
And
then
the
user
can
edit
the
contents
of
the
file
they
selected
so
right
now
this
is
just
a
plain
text
editor,
but
stick
a
wysiwyg
on
this
page
and
you've
got
a
WordPress
style
workflow,
that's
actually
running
entirely
on
the
user's
local
machine.
So
after
they've
made
their
changes,
they
can
click
preview
and
the
app
will
automatically
save
those
changes
to
disk,
compile
the
site
using
the
build
tool
of
choice
and
open
up
the
compiled
web
page
in
a
new
browser.
A
So
we
just
saw
how
an
author
can
edit
a
static
website
without
having
to
run
a
single
command
and
just
as
important
this
didn't
require
any
changes
to
web
developers.
Ideal
static,
site
workflows,
there
are
no
extra
components
to
set
up
the
databases
or
application
code,
so
summarize
in
CMS
is
makes
it
easy
for
authors
to
edit
static
sites
by
making
them
look
like
web
developers.
A
This
results
in
simplified,
build
systems
for
developers
which
is
great,
and
it's
also
a
secure
and
reliable
as
git
is
because
all
of
your
code
and
content
is
now
managed
entirely
by
get
and
since
content
is
version
controlled.
People
like
me,
don't
need
to
worry
that
content
is
gonna
disappear
or
be
overwritten
in
a
database
somewhere
and
finally,
in
CMS,
happens
to
be
language
framework
and
vendor
agnostic,
since
all
it's
really
doing
is
moving
text
files
around
with
git.