►
From YouTube: Git and GitHub Secrets - GitHub Universe 2015
Description
In teaching others how to use Git and GitHub, we have found certain useful, well-documented features remain under-appreciated and under-used. In building GitHub, we have developed a few techniques for using the platform with maximum efficiency. This session, hosted by Patrick McKenna, aims to cover both "types" of secrets, with a bias for the practical over the esoteric.
About GitHub Universe:
Great software is more than code. GitHub Universe serves as a showcase for how people work together to solve the hard problems of developing software.
For more information on GitHub Universe, check the website:
http://githubuniverse.com
A
Okay,
welcome
everybody,
I
assume
everyone
in
the
back
end
hear
me
all
right.
Raise
your
hand
if
you
can't
hear
me
in
the
back
rows,
please
fantastic.
So
welcome
to
this
talk
on
git
and
github
secrets.
My
name
is
Patrick.
Mckenna
I
realized
the
handles
actually
tucked
away
in
the
bottom
right
hand
corner
where
most
of
you
probably
can't
see
it
I
apologize
for
that.
It's
just
my
name,
concatenated
Patrick
McKenna.
A
So
that's
me
on
the
github
x',
I'm
a
trainer
at
github,
so
I
spend
a
lot
of
time
teaching
online
going
and
visiting
with
people
in
person,
teaching
them
how
to
get
and
github.
So
today's
talk
is
is
billed
as
git
and
github
secrets.
Secrets
is,
of
course,
a
pretty
subjective
term
right.
It
means
a
lot
of
different
things
to
different
people
and
especially
when
we
talk
about
git,
there's
all
manner
of
esoteric
stuff
that
we
could
get
into,
and
most
people
would
probably
define
as
close
to
secret.
A
But
I
don't
want
this
talk
to
be
about
that,
because
that's
only
interesting
to
a
tiny
subset
of
the
audience.
So
the
goal
here
is
to
cover
getting
github
features
that
may
be
very
well
documented,
but
which
we
have
found
and
going
out
and
doing
training
and
speaking
with
customers
and
users
are
pretty
underappreciated
and
underused.
So
that's
one
category
of
things
that
we
want
to
cover
today
and
then
the
other
mixed
in
is
some
ways
that
we
at
github
have
actually
come
to
use
the
product
as
we
build
the
product.
A
So
I
see
secret
in
the
sense
that
you
probably
don't
know
about
this
unless
you
happen
to
have
worked
at
github,
but
many
of
you
may
already
be
using
some
of
these.
These
tricks
already,
but
those
are,
broadly
speaking,
the
two
categories
that
we
want
to
cover.
So
the
first
thing
I
know
just
for
you,
people
out
there
I
will
be
posting.
A
So
the
first
thing
I
want
to
say
is:
okay,
assume
that
you're
coming
into
a
new
project,
maybe
you're
a
team
you've
been
assigned
to
take
it
over,
but
you
want
to
figure
out
who's
been
contributing.
What
you
can,
of
course,
do
you
can
filter
for
commits
by
commit
author
on
the
command
line,
but
it's
also
something
you
can
do
in
the
web,
UI,
so
replace
user
and
repo,
of
course,
with
the
appropriate
individual
user
or
organization
account.
Then
the
repo
name.
A
And
then,
if
you
add
this
question
mark
author
equals
followed
by
the
get
up
handle,
you
can
go
ahead
and
get
a
list
just
of
commits
by
users.
So
I've
taken
as
the
example
actually
a
techno
weenie,
who
some
of
you
may
have
seen.
I
was
giving
a
talk
about
git
LFS,
which
most
of
you
probably
know
hit
one
dotto
just
yesterday,
but
the
idea
here
is
yeah
it's
so
hopefully
that
has
a
lot
of
you
excited
we're
pretty
stoked
about
getting
elephants
out
to
a
1.0
state.
A
So
another
useful
thing
that
a
lot
of
people
don't
know
about
is
what
we
like
to
call
our
compare
view.
Alright.
So
if
you
you're
jumping
into
a
new
project
or
you're,
looking
at
a
repo
that
you've
been
working
on
sometime,
you
want
to
be
able
to
compare
the
state
of
different
branches.
Let's
say
so.
If
you
just
hit
this
URL,
you
will
get
a
interface
that
looks
something
like
this
gives
you
two
drop-down
menus
and
lets.
You
pick
all
right
what
two
states?
What
two
revisions
of
your
project
do
you
want
to
compare?
A
So
that's
useful
if
you
want
to
be
able
to
browse
through
the
the
actual
drop
down
menus,
you're,
not
sure
what
you're
looking
for,
but
you
can
also
just
go
ahead
and
again
just
type
the
URL
in
directly
so
user.
Repo
compare
committees
here
is
get
lingo
really.
What
it
means
is
a
commit,
sha,
a
branch,
a
tag
or
actually
a
point
in
time.
A
So
there's
another
thing,
and
that
would
go
ahead
and
and
give
you
an
output.
A
lot
like
this,
so
when
we
type
into
the
URL
bar
master,
dot
fetch
deleted
files.
What
you're
gonna
see
on
this
output
right
here
is
a
list
of
commits
that
are
not
on
master
but
are
on
fetch
deleted
files,
so
really
handy.
If
you
don't
want
to
jump
back
and
forth
between
the
command
line
and
the
web
interface
and
want
to
be
able
to
get
a
sense
of
where
your
project
is
according
to
different
branches,.
A
So
another
thing,
that's
really
handy
is
to
be
able
to
actually
suppress
white
Spade
whitespace
errors.
This
happens
a
lot
people
will
forget
to
set
up
their
good
environments
properly.
That's
common,
especially
when
people
are
working
cross-platform.
If
you
have
some
people
on
Windows
machines
and
and
others
on
linux
or
OS
10,
those
two
systems
treat
line
endings
differently,
and
so
you
reach
a
state
fairly
frequently
where
people
forget
to
set
get
up
properly
and
you
get
whitespace
errors.
A
Another
really
useful
thing
to
be
able
to
do
with
just
a
little
URL
hacking
as
we
like
to
call
it
is
to
be
able
to
highlight
specific
lines
so
soon,
again,
you're
coming
into
a
project.
You
found
some
file,
that
includes
say
a
function
definition
or
that
you
really
like,
or
an
implementation
of,
an
algorithm
that
you
find
especially
clever
or
maybe
even
problematic,
and
you
want
to
point
this
out
to
your
teammates.
A
Well,
you
don't
want
to
just
send
them
the
URL
for
the
file
itself,
because
then
they
have
to
go
hunt
down
what
the
the
actual
lines
are.
So
if
you
can
just
add
pound
l1
l2,
where
you
should
sub
in
for
l1
and
l2,
whatever
the
line
numbers
are,
you
can
go
ahead
and
highlight
the
lines
directly.
So,
instead
of
something
like
this,
you
go
to
that
right
there
and
if
you
don't
know
ahead
of
time
what
lines
you
actually
want
to
have
highlighted,
you
can
actually
do
this.
A
So
there's
one
thing
you
want
to
note
here:
this
works
for
plain
text
files
so
that
Travis
config
file
right
there.
The
mo
file
I,
does
not
work
for
text
that
gets
rendered
some
markdown,
for
example,
markdown
we
render
for
you
on
get
up.
That's
that's
one
of
the
things
that
we
think
it's
quite
nice
about
it,
but
you
don't
get
the
highlighting
for
stuff
like
that.
A
Another
just
kind
of
light-hearted
one
is:
is
the
shortcut
to
get
to
your
avatar?
Actually,
so,
if
you
just
go
to
github.com
slashed
your
username
Gangi,
you
will
actually
get
a
the
the
avatar,
so
you
don't
have
to
go
right,
click
and
figure
out
what
the
actual
official
URL
is.
We'll
just
go
ahead
and
forward
you
onto
that,
so
it's
really
handy.
If
you
need
to
be
able
to
include
an
image
easily
like
say
you
want
to
give
a
shout
out
to
somebody
and
the
readme.
Alright,
that's
it's
really
nice.
A
A
Another
really
handy
thing
that
a
lot
of
people
I
think
don't
know
about
is
one
of
these
other
special
files
on
github.
Most
everybody
knows
about
the
readme
yeah.
If
you
don't,
please
make
sure
to
include
a
readme,
the
top
level
of
all
your
repositories.
It's
a
great
way
to
let
people
know
what
the
projects
all
about.
We
will
render
the
readme
on
the
home
page
protip.
A
You
can
actually
include
readme
xin
sub
directories
and
those
will
also
render
as
well
so
you're
not
limited
to
just
one
per
repository,
but
we
also
have
this
other
special
file.
I
say
special,
because
git
has
no
notion
of
a
readme
or
contributing
MD
file.
In
this
case,
if
you
write
this
file,
what
gonna
happen
is
we
will
display
a
little
banner
when
everybody
whenever,
whenever
anyone
tries
to
open
a
pull
request.
A
So
if
this
is
your
default
view
right
here
for
opening
a
new
pull
request,
if
I
have
added
a
contributing
MD
file,
you'll
see
this
banner
actually
pop
up
the
yellow
banner
right
there.
So
it's
not
a
hard
enforcement
you're,
not
forcing
anybody.
It's
a
go
through
and
say:
alright,
look
I'm
going
to
read
the
guidelines,
I'm
gonna
check
things
off
and
so
on
and
so
forth.
But
it's
a
nice
simple
reminder
right
there,
something
that's
a
little
more
lightweight
to
help.
You
encourage
a
culture
of
obeying
whatever
practices.
Your
team's
decided
our
best.
A
Some
other
handy
things
that
people
will
overlook
often
times.
Even
though
markdown
syntax
is
pretty
straightforward.
To
go
look
up,
you
can
actually
do
internal
links.
So
not
only
can
you
do
outbound
links,
but
if
you
want
to
link
to
different
sections
within
a
single
markdown
document,
that's
the
syntax
for
you
not
all
that
sexy
I
understand,
but
very
useful
and
underappreciated.
A
A
Alright,
so
oftentimes
people
are
coming
to
two
projects
and
they
see
new
threads
new
issues
posted
and
they
have
a
lot
of
different
conventions.
You
want
them
to
include
a
lot
of
the
same
information.
So
how
do
you
template
eyes
issues?
How
do
you
get
people
to
actually
fill
in
some
relatively
consistent
information?
Each
time
they
open
a
new
one?
Well,
one
way
is
to
construct
URLs
like
this.
So
obviously
you
don't
want
to
include
the
line
breaks.
A
That's
just
for
legibility,
on
this
slide
right
here
and
it's
relatively
straightforward
use
a
reboot
issues,
new
title:
whatever
you
want
there
ampersand
so
on
and
so
forth,
and
this
will
let
you
construct
a
link
for
people.
They
can
go
ahead
and
click
on
so
that
if
you
had
this
particular
link
in
your
say,
readme
or
contributing,
you
would
get
something
like
this.
A
wonderfully
descriptive,
informative.
A
Your
title
here,
your
text
here
your
label
here
just
a
side
note
if
you
happen
to
include
in
this
URL
a
label
that
your
repository
doesn't
have
it's
just
like
I
know
up
nothing
happens.
We
don't
make
up
a
new
label
for
you,
but
incredibly
useful.
We
use
it
internally
at
github
a
lot
because
there
are
more
and
more
people
at
github
and
we
certainly
don't
know
how
all
the
different
teams
like
to
work,
especially
if
we're
not
working
with
each
other
on
a
day
to
day
basis.
A
So
to
make
things
simple,
we'll
include
a
readme
of
course,
and
then
in
that
readme
say
hey.
If
you
want
to
ping
this
team
go
ahead
and
click
on
this
link
and
just
fill
in
the
blanks
right
there.
So
it's
a
way
to
enforce
some
more
consistency
as
more
and
more
people
collaborate
across
projects
keyboard
shortcuts.
This
is
something
of
a
revelation,
I
think
for
most
people,
the
first
time
they
see
it.
It
certainly
was
for
me
and
most
people
that
I
speak
to
you,
don't
like
to
work
with
the
trackpad
shift.
A
Question
mark
is
your
friend:
it
will
bring
up
a
context-sensitive
menu
of
keyboard,
shortcuts,
context-sensitive,
meaning,
what's
actually
going
to
show
up
here,
will
depend
on
what
page
you're
looking
at
so,
if
you're
at
the
top
level
page
for
a
repository.
This
is
what
you'll
get
I've
got
a
different
set
of
options
if
you're
in
the
issues
page.
Likewise
for
pull
requests.
There
is
no
keyboard
shortcut
to
show
all
keyboard
shortcuts.
A
Unfortunately,
so
you
do
have
to
click
show
all,
and
then
you
get
the
full
list,
at
least
as
it
shows
up
on
a
repository
homepage.
This
gets
to
be
incredibly
useful,
especially
for
people
like
myself
who
do
not
like
to
keep
moving
our
hands
off
the
keyboard.
There's
a
lot
of
stuff.
There
don't
expect
yourself
to
memorize
at
all.
There's
no
need
to
it's
like
trying
to
memorize
all
the
flags
for
a
given
git
command.
A
Fuzzy
file.
Finder
is
one
of
those
six
to
ten
that
most
people
will
be
using.
We
got
it.
We
got
a
chuckle
back
here
from
but
from
Brandt
who
who
loves
the
fuzzy
file
finder,
so
you're.
Looking
at
the
code
for
your
repository-
and
you
don't
remember
what
file
it
is
you're
looking
for
exactly
so
just
go
ahead
and
hit
T
and
you
pull
up
this
dialog
right
here.
That's
exactly
what
it
sounds
like.
So
the
fuzzy
part
of
things,
meaning
you
don't
need
to
spell
a
name
exactly
as
it
is.
A
So
if
it's
node
version,
for
example,
you
could
just
start
typing
version
and
it
will
start
filtering
down
and
node
version
will
may
remain
among
your
options.
You
also
want
to
take
note
of
the
keyboard
navigation
right
there
within
the
fuzzy
file
finder.
So
it's
really
nice.
It's
a
text
editor
like
feature
that
shows
up
in
the
web
UI.
A
So
imagine
you're
looking
for
a
particular
file,
but
you
can't
exactly
remember
the
file
name
and
and
fuzzy
file.
Finder
hasn't
worked
for
you.
Another
option,
though
a
lot
of
us
use
internally
is
all
right.
Well,
let
me
try
to
find
the
associated
issue
or
pull
request
that
I.
That
way,
I
can
that
maybe
that'll
leave
me
there
remember
what
the
general
discussion
was
I
remember,
maybe,
who
was
who
was
talking
about
things
in
this
pull
request?
A
One
of
them
that
we
think
is
particularly
helpful
is
something
like
this,
so
this
will
actually
show
you
all
all
issues
or
pull
requests
depending
on
where
you're
searching
that
have
the
ship
it
squirrel
somewhere
in
one
of
the
comments,
so,
for
example,
if
I
did
that
search
and
the
Adam
repo
you'll
see,
there's
one
open,
pull
request
that
says
ship
it,
so
somebody
probably
should
ship
it
and
31
that
had
been
closed.
Incidentally,
that
works
for
any
emoji.
A
Another
just
a
an
example
search
here
that
you
might
want
to
do
when
you're
looking
through
pull
requests.
Looking
for
that
particular
file,
all
right
I
want
to
find
everything
that
is
gonna
be
merged
into
master,
but
it
hasn't
been
merged
yet
and
has
been
updated
since
yesterday.
There's
the
page
that
you
actually
get
linked
to
from
that
drop-down
menu
for
new
advanced
search
will
tell
you
about
all
the
different
formats
you
can
use
for
that
date,
but
yeah
the
ISO
standards
or
one
easy
one,
so
yeah
this
would
be
every
every
pull
request.
A
A
Notice,
the
the
bottom
of
this
screen
actually
also
shows
our
little
pro
tip
that
will
pop
up.
If
you
want
to
just
find
a
particular
thread
that
mentions
a
user,
you
can
use
that
mentions
:,
github,
username
syntax,
all
right,
so
imagine
that
you
can't
find
something
in
the
fuzzy
file,
finder
you're,
having
trouble
finding
the
associated
issue
or
pull
request,
and
you
need
to
actually
just
get
down
to
the
command
line.
A
lot
of
people
don't
know
about
this
particular
option
for
the
git
log
command.
A
So
what
this
is
going
to,
let
you
do
is
actually
output
all
commits
that
touch
a
given
function
in
a
given
file
so
obviously
gets
gonna.
Do
some
guesswork
here
and
so
forth,
but
it's
usually
pretty
good.
So
it's
it's
pretty
straightforward.
The
output
you'll
get
is
something
like
this
right
here,
so
we're
searching
for
all
commits
that
are
going
to
touch
the
atom,
initialize
ICU
and
start
node
function
in
the
atom
library
main
header
file
right
there,
and
you
can
see
the
beginnings
of
the
output
for
that.
A
What,
if
you
don't
know
the
exact
function?
Name,
you
just
want
to
search
for
a
more
general
string.
You
can
use
this
syntax
right
here.
Log
cap
s
followed
by
a
string,
there's
a
there's,
a
similar
switch.
If
you
want
to
actually
use
a
regex
and
but
if
you
know
the
string
itself
and
you
don't
need
to
be
using
reg
X's,
this
is
the
format
for
you
fairly
straightforward.
So
show
me
everything
in
the
electron
repo.
That
includes
of
the
word
selenium
is
this
example
right
here.
A
Finally,
you
can
also
get
just
a
little
bit
of
a
side.
You
can
get
the
history
of
given
lines
of
a
file
on
the
command
line,
so
again,
fairly
straightforward,
syntax
here
so
l1
and
l2,
or
the
beginning
and
anding
lines
that
you
care
about
:
the
file
name,
and
this
would
be
an
example
again
so
of
this.
So
give
me
the
history
of
lines
11
through
20
in
the
atom
main
delegate,
header
file,
so
really
handy
to
be
able
to
find
things
quickly
to
really
use
good
effectively.
A
You
need
to
be
able
to
search
through
history
with
some
degree
of
ease.
I
mean
it's
it's
great
to
know
that
everything
is
saved
in
history.
That's
that's
wonderful!
Maybe
that
provides
you
some
peace
of
mind,
but
if
you
can't
find
this
stuff,
it's
gonna
not
be
all
that
useful
for
you.
So
commands
like
this
are
really
great
to
play
around
with,
and
you
probably
want
to
include
in
your
repertoire,
because
that's
what's
gonna,
actually
let
you
find
all
those
different
versions
of
things
through
history
and
make
maximum
use
of
get.
A
Alright,
so
imagine
you've
found
a
particular
file
now
be
the
buzzie
file
finder
or
using
the
command-line
options
we
just
found
or
through
some
other
method,
and
you
want
to
open
a
new
poor
request.
So
say
you
need
to
do
some
refactoring
of
food
right.
You
know
it
needs
to
be
refactored,
but
you
don't
have
the
expertise,
so
you
don't
have
the
time,
but
you
want
to
open
this
pull
request.
A
You
want
to
get
the
pull
request
open
early,
because
you
want
to
start
the
conversation
early
and
make
sure
it's
all
captured
in
a
single
place.
So
one
thing
in
order
to
open
a
pull
request.
You
of
course
need
a
new
branch
and
in
order
to
you,
also
need
a
unique
commit.
So
if
you
want
to
merge
into
master,
you
need
some
non
master
branch
and
that
non
master
branch
has
to
have
at
least
one
commit
that
does
not
live
on
master.
A
So
what
do
you
do
in
the
case
of
wanting
to
open
the
pour
request?
But
you
have
no
idea
what
changes
you
actually
want
to
make?
Well,
there's
this
little
pack
of
sorts
you
can
make
an
empty
commit
on
the
command
line
and
then
go
ahead.
That
will
be
unique,
commits
push
it
up
to
github
and
then
go
ahead
and
open
the
pull
request.
So
this
is
what
that
would
look
like
right
here.
A
I
now
have
a
pull
request:
open
I
have
a
place
to
start
the
conversation
about
what
should
go
on
without
having
made
a
single
change
yet,
and
this
actually
gets
back
to
the
point.
I
was
mentioning
just
a
few
moments
ago,
which
is
opening
for
requests
early,
especially
for
newer
users.
You
may
not
feel
very
comfortable
opening
a
poor
request
on
work
that
you
don't
feel
is
complete,
understandable
natural.
A
Nobody
wants
to
do
something
other
than
put
their
best
foot
forward
right,
but
we
recommend
against
that
very
strongly
and
we
highly
encourage
you
to
open
pull
requests
early
and
to
start
that
conversation
early
and
for
a
whole
manner
of
reasons
number
one
is.
Maybe
somebody
wants
to
help
you
it's
much
better
to
get
their
help
at
the
beginning
that
it
is
when
you're
almost
done.
A
Number
two
is:
maybe
the
approach
you're
taking
is
is
going
to
be
something
that
requires
a
lot
of
careful
thought
and
you
want
some
idea
of
how
to
architect
the
solution
again.
What
that
conversation
happened
in
the
beginning
for
you've
chosen
a
particular
path,
then
there's
a
third
reason,
which
would
be
maybe
these
paths
you're
actually
walking
down,
is
going
to
conflict
in
some
way
with
other
work
that
is
happening
currently
or
will
be
happening
in
the
future.
A
Now
your
boss
comes
to
say,
oh
by
the
way
you
know
we
can't
use
that
library
because
X
you
want
to
know
that
before
you
use
the
live
with
that
library
and
then
have
to
change
your
entire
set
of
work,
so
open
pull
requests
early,
and
if
you
really
don't
know
what
you're
gonna
do
in
that
pull
requests
just
make
it
an
empty
commit.
One
of
the
other
things
that
we
use
a
lot
is
really
just
a
commit,
a
file
that
has
nothing
in
it.
A
If
you
know
you
need
to
make
something
new,
but
you're
not
sure
what
should
go
in
the
file,
yet
you
can
always
a
commit
an
empty
file
and
open
a
pull
request.
That
way,
all
right
so
once
you've
got
that
when
you're
actually
opening
this
pull
request,
there
are
a
number
of
key
words
that
you
can
use
so
fix,
closed
resolve
and
the
different
tenses
of
each
of
those,
so
nine
combinations
in
total,
like
fix,
fixes
fixed
so
forth.
When
you
put
those
in
front
of
a
an
issue
or
pull
request
number.
A
What
will
happen
is
the
that
issue
or
pull
request
will
automatically
get
closed
as
soon
as
you
merge
the
pull
request.
So,
for
example,
right
here,
I
say
fixes
number
12.
So
as
soon
as
this
pull
request
gets
merged,
issue
number
12
will
automatically
get
closed,
really
handy.
If
you
have
a
workflow
where
you
say,
introduce
bug
reports
and
github
issues
and
somebody
needs
to
open
a
pull
request.
A
Once
they've
seen
the
bug
report
in
an
issue,
and
you
want
to
just
be
able
to
automate
the
closing
of
that
particular
ticket
right,
it
makes
perfect
sense.
This
also
brings
up
cross,
linking
if
you
haven't
seen
it
before
you
can
link
between
different
issues
and
pull
requests
by
just
including
the
appropriate
integer
right
there,
so
just
pound
symbol
and
that
integer
we
will
automatically
turn
into
a
link
and
take
you
to
the
Associated
issue,
a
pull
request
in
the
same
repository
so
fix
close
and
resolve.
A
They
also
work
and
commit
messages,
so
get,
of
course,
has
no
notion
of
fixed
closed
and
resolved,
because
this
has
to
do
with
full
requests
and
issues.
But
if
you
include
any
of
those
keywords
followed
again
same
as
Beck
syntax,
followed
by
pound
and
the
issue,
a
pull
request,
number
the
same
action
will
happen
now.
Poor
request
is
merged.
You
go
ahead
and
close
the
issue.
A
Canonical
URLs,
why?
Okay,
that's
not
a
very
exciting
slide!
I
realized
that
this
is
probably
the
most
exciting
thing.
I
learned,
though,
relatively
recently
and
I'm
sorry,
I
didn't
know
what
earlier.
So.
If
you
need
to
within
say
a
pull
request,
link
to
a
specific
version
of
a
file,
usually
what
people
are
gonna
do
is
they're
gonna.
Do
something
like
this
thanks,
but
this
is
the
default
URL
you're
gonna
get
a
given
repo
blob
the
branch
name
and
followed
by
the
filename
and
the
path
to
that
file.
A
This
is
this
is
what
we
show
you
by
default,
so
if
the
branch
is
master,
for
example
and
path,
spec
is
just
read
me.
This
link
will
always
take
you
to
whatever
version
of
read.
The
readme
exists
on
the
master
branch
at
that
time,
so
that
presumably
is
going
to
change
as
your
project
advances
and
is
the
master
version
of
your
readme
changes.
Sometimes
you
want
to
link
to
a
particular
revision,
though
you
don't
want
it
to
actually
automatically
update.
So
in
the
case
of
a
Perl
quest
would
be
a
common
one.
A
Branch,
of
course,
will
move
forward
in
time.
So
here's
here's
hello
world
right
here
and
then
once
I
press,
the
the
Y
key
you'll
notice
shows
up
slightly
differently.
So
the
drop
down
instead
of
being
branch
master,
is
gonna,
say
tree,
followed
by
that
abbreviated,
sha
right
there
for
those
of
you
that
know
get
internals.
Incidentally,
zero
EDD
in
this
case
is
not
actually
a
tree.
It's
actually
just
the
commit
sha,
so
just
just
be
aware,
if
it's
as
mildly
confusing,
so
even
though
it
does
say
tree,
that's
that's
not
the
case.
A
All
right,
these
statuses
API,
is
something
that
a
number
of
people
have
touched
on
and
is
another
ones
incredibly
powerful
things,
especially
if
you
haven't
seen
it
before
so
I.
Thought
of
this
phrase
the
other
day
like
how
best
to
describe
what
the
statuses
API
does
and
I
think
this
is
the
best
one
I've
come
up
with.
Who
knows
maybe
some
from
the
platform
team
is
gonna
come
up
to
me
afterwards,
it's
a
terrible
idea,
that's
wrong
whatever,
but
stateful
commits
what
do
I
mean
by
that.
A
You
want
to
be
able
to
associate
some
data
with
a
given
commit
the
most
obvious
example
being
something
like
CI
status.
So
when
you
start
to
use
our
statuses
API
say
by
using
an
integration
like
Travis,
what
will
happen
is
we'll
fire
off
a
web
book
say
when
you
you
push
a
new
commit
to
github.
Travis
will
run
the
test
that
you
told
it
to
run
and
it
will
report
back
the
status
of
those
tests
and
it
will
associate
a
state
with
the
commit.
A
So
in
the
screenshot
example,
here
that's
two
e
four,
five,
four,
six,
five,
nine
nine-
and
in
this
case
we
have
five
different
states,
actually
so
five
different
CI
tests
in
this
case,
all
of
them
happen
to
be
passing.
So
it's
it's
really.
This
is
probably
the
the
canonical
example
by
now
for
us
of
how
to
use
our
statuses
API.
It's
that's
what's
happening
when
we
offer
an
integration
like
with
circle
or
Travis
or
any
of
the
other
providers
that
you've
seen
in
the
integrations
directory
behind
the
scenes,
they're
just
using
our
statuses
API.
A
So
that
means
you
could
actually
roll
your
own
integration.
If
you
have
your
own
custom,
CI
service
or
you
just
want
to
mess
around,
you
can
do
it
exactly
the
same
thing
and
it's
actually
really
easy
just
to
write
a
few
simple
curl
scripts,
if
you
just
want
to
practice
and
some
scratch
directory
of
yours
and
the
documentation
for
this
is
also
quite
good,
so
developer,
github
comm
as
our
API
documentation
and
there's
some
really
great
examples
that
our
docs
team
has
put
together
they're
of
just
building
your
own
CI
server.
So
we're
not
gonna.
A
So
here's
just
another
view
of
things.
This
would
be
the
bottom
of
a
tap
or
request
right
here.
In
this
case
again,
five
statuses,
three
of
them
are
successful
and
two
of
them
are
failed,
and,
incidentally,
these
these
links
back
here
when
you
see
details
on
the
right
hand,
side.
Those
are
all
the
deep
links
in
this
case
to
the
build
output.
A
A
So
another
useful
thing
is
actually
the
the
deploy
API,
and
you
see
that
here
with
the
the
shipit'
squirrel's,
so
cosima
deployed
to
lab
that's
the
name
we
offer
for
one
of
our
staging
environments
and
then
later
on.
Croissant
deployed
it's
a
production
right
here.
So
much
like
the
statuses
API
the
deploy
API
lets.
You
represent
certain
events
within
the
timeline
view
of
a
pull
request.
So
you
don't
need
to
keep
jumping
around
between
all
these
different
systems
to
understand.
A
Okay,
what's
in
production,
what's
in
with
an
arbitrary
environment,
it's
a
great
way
against
you
to
raise
visibility
of
certain
actions.
So
anybody
can
see
what
the
state
of
a
given
project
is.
Now.
Not
only
can
you
see
a
vehicle
requests,
how
many
commits
have
been
made
who's
made
them?
What
the
latest
versions
are.
You
can
also
have
those
those
stateful
commits.
Really
you
can
have
CI
statuses
associated
with
them,
and
then
you
can
take
it
another
level.
A
You
can
see
where's
this
code
actually
deployed,
you
know,
is
it
still
just
living
on
github
or
we
and
we
actually
deployed
it
to
any
environments,
all
right,
a
lot
of
people
they
like
to
live
on
the
command
line
and
don't
want
to
be
in
the
web
UI.
All
the
time
for
you
I,
say
check
out
hub
hub
github.com
is
a
is
a
wrapper
really
for
our
API
and
it
lets
you
do
a
lot
of
github
stuff,
not
good
stuff
but
github
stuff
on
the
command
line
really
handy.
A
So
you
can
do
things
like
this
have
to
clicker
works
all
right
there.
We
go
hub
checkout,
followed
by
the
URL
of
a
pull
request,
so
you
don't
have
to
go
through
all
the
individual.
Get
operations
we'll
just
go
ahead
and
take
care
of
for
you.
We
will
automatically
create
a
new
branch
and
check
you
out
to
it,
so
you
can
go
right
from
a
pull
request
view
to
the
command
line
and
check
out
the
Associated
branch
locally.
A
So
oftentimes
people
are
reviewing
pull,
requests
or
or
trying
to
merge
things
on
the
command
line,
and
you
get
into
a
really
sticky
situation
say
you.
You
were
halfway
through
fixing
the
merged
conflicts,
but
you
don't
like
where
you've
gotten
and
you
just
need
to
get
back
to
the
original
conflicted
State.
A
In
that
case,
you
can
do
something
like
this.
It's
a
basic
get
operation,
get
check
out,
conflict
followed
by
merger
or
diff
3.
What
this
is
gonna
do
is
say
you
have
a
conflict
and
readme
and
you've
started
to
fix
that,
and
you
don't
like,
where
you've
gone
with
it.
If
you
run
this
command,
you
will
actually
get
back
the
originally
conflicted
version
of
reading,
so
you'll
be
back
at
that
initial
state
of
having
the
merge
conflict.
A
So
it's
a
way
to
back
out
of
changes
that
you,
if
you
don't
like
the
fix
you've
started
to
implement
but
not
finished
the
the
merge,
diff
three
flags
right
there
just
have
to
do
with
what
the
actual
conflict
looks
like
in
the
file
once
it's
restored.
Its
merge
is
going
to
show
you
what
is
on
your
branch
and
then
the
branch
of
trying
to
merge
into
diff
tree
will
also
include
the
version
of
the
file
as
it
existed
at
the
common
parent.
So
wherever
both
people
branched
off
from.
A
All
right
another
option
you
have,
if
you're
in
the
middle
of
emerged,
conflicts
and
you're
having
a
tricky
time
resolving
it.
You
can
do
this
in
a
three-way
merge.
There
are
going
to
be
three
different
versions
of
a
given
file
that
that's
conflicted
right.
There's
the
version
on
the
branch
you're
on
the
version
on
the
branch
you're
trying
to
to
merge
in
and
then
the
version
from
the
common
parent
right
there.
A
If
you
want
to
actually
check
out
into
your
working
directory
any
one
of
those
you
can
with
this
syntax
right
here,
so
the
end
right,
there
should
be
replaced
by
one
two
or
three.
If
you
replaced
n
by
the
number
one,
what
you
would
do
is
go
ahead
and
check
out
a
copy
of
the
file
as
it
existed
on
the
common
parent
commit.
So
the
reason
there's
a
you
give
the
the
end.
A
So
in
this
case
number
one
followed
by
the
the
path
of
the
the
file
you
want
check
out
and
then
the
greater
than
symbol
and
then
whatever
you
want
to
call
the
file
locally.
So
if
they
file,
if
the
conflicted
file
is
readme-
and
you
want
to
check
out
the
common
parent
version
of
readme-
you
probably
want
you
want
to
give
it
a
new
file
name.
Otherwise,
it's
going
to
overwrite
the
the
one
that's
in
your
working
directory,
namely
that
conflicted
version,
so
two
would
be
if
you
were
to
place.
A
If
you
were
to
replace
n
with
number
two
right
there.
What
you
would
get
is
the
version
of
the
conflicted
file
as
it
exists
on
the
branch
you're
on
before
that
merge
conflict
number
three
would
be
from
the
branch
you're
trying
to
merge
in
so
it's
it
sounds
a
little
bit
esoteric.
It's
about
as
esoteric
is
I'm
gonna.
A
Try
to
make
anything
in
today's
talk,
but
it's
a
really
useful
way
to
be
able
to
get
any
of
the
three
different
versions
of
a
file
into
your
working
directory
when
you're
in
the
middle
of
a
merge
conflict.
If
you
don't
want
to
just
look
at
a
single
file
that
has
all
those
different
merged
conflict
markers
in
it,
you
want
to
see
what
the
files
look
like
independently.
A
So
here's
the
next
secret
right
here
so
hat
tip
to
Heather
Baldry
front
from
github
secret,
in
a
sense
that
we
talk
a
lot
about
github
being
really
useful
for
developers,
we'd
like
to
think
it
is,
but
it
can
be
really
handy
for
non
developers
as
well.
So
there's
we
famously
said
before
github
uses
github
to
build
github.
We
also
use
github
to
run
github.
So
it's
not
just
developers
our
product
managers
or
engineering
managers
and
so
forth
that
are
using
github.
We
have
things
like
the
legal
repo,
so
it's
really
handy
right.
A
The
legal
team
isn't
opening
too
many
pull
requests,
but
it's
yeah.
You've
got
seven
right
there,
but
we
have
at
least
eighty-three
legal
issues
right
now,
evidently
or
as
of
yesterday.
So
really
handy
issues
are
a
great
way
to
be
able
to
communicate
with
people.
We
think
much
much
better
than
email.
You
have
a
single
canonical
place
to
go
to.
If
anyone
needs
to
get
caught
up
on
a
conversation,
you
don't
need
to
worry
about
being
cc'd
on
a
thread
or
you
know,
having
part
of
it
or
searching
through
email
history.
A
You
get
lots
of
rich
contextual
information
and,
in
our
case
that
lets
us
stay
in
the
same
spot,
so
I
don't
need
to
be
context,
switching
between
different
apps,
all
the
time
as
well.
So
so
there's
plenty
of
one
of
your
one
of
your
final
github
secrets
is:
if
you
start
to
teach
a
non
developer,
how
to
use
it,
they
will
oftentimes
grow
to
love
it.
It
may
take
a
little
bit
at
first.
That's
fine!
A
There
can
be
a
steep
learning
curve,
but
it
can
be
incredibly
useful
even
for
non
developers,
in
fact,
I'd
a
chance
to
talk
to
a
number
of
you
here.
We
weren't
necessarily
writing
source
code
on
a
day
to
day
basis,
but
doing
something
like
documentation.
Our
docs
team
uses
geta
heavily
all
right,
so
there's
always
more
out
there
right.
This
is
just
a
tiny,
tiny
sample
of
the
getting
github
secrets
out
there.
A
Think
that's
awesome
that
we
to
work
with
two
people
who
are
actively
maintaining
it
today,
we'd
like
to
post
about
new
releases
and
point
out
the
kind
of
things
that
we
think
would
be
interesting
to
different
audiences.
So
you
can
just
check
this
out.
This
was
there
a
plethora
of
blog
posts,
as
you
might
imagine
in
the
last
several
days-
and
this
is
probably
number
seven
or
eight
going
back-
also
really
cool.
If
you
don't
want
it,
if
you
don't
want
to
view
the
general
blog,
you
want
to
just
be
able
to
get
technical
information.
A
We
relatively
recently
launched
the
github
engineering
blog.
So
a
lot
of
different
posts
by
our
whole
engineering
team,
vmg
fellow
back-end
engineer,
happens
to
do
a
lot
of
stuff
with
get
on.
Our
servers
has
the
latest
posts
about
how
we
count
get
objects
and
and
how
we
did
that
a
lot
more
efficiently.
So
there's
really
cool
stuff
in
here
that
happens
to
come
from
our
engineering
team
telling
you
more
and
you'll
you'll
invariably
discover
some
more
getting
getup
secrets
in
there.
A
Another
great
one
that
I
point
people
to
a
lot
is
how
github
does
branch
deploys,
which
was
one
of
the
earlier
posts
on
this
blog
by
bayamón.
It's
great.
If
you
want
to
read
about
how
we
get
hub,
actually
deploy
our
code
out
so
that
all
of
you
can
enjoy
it,
hopefully
enjoy
it
at
least
experience
it.
So
I'm
gonna
end
it
up
right
there.
Thank
you
very
much.
Everybody
and
I'd
like
to
stick
around
for
as
many
questions
as
you
have.
A
A
A
You
had
the
branch
that's
gonna,
get
merged
in
yeah.
Compare
so
the
question.
Thank
you
Thank
You
Brandon.
So
the
question
was
in
the
example
of
searching
through
pull
requests.
I
showed
that
you
could
specify
the
base
branch,
meaning
the
branch
that
you
want.
Some
merge
into
just
type
base
and
the
example
was
actually
master.
Can
you
do
the
same
thing?
Can
you
can
you
search
by
the
branch
that
you
want
to
merge
in
and
the
answer?
There
is
yes,
it's
just
compare
:,
followed
by
the
branch
name.
A
So
proto
yeah
exactly
so.
The
question
had
to
do
with
opening
pull
requests
early
and
more
specifically,
do
we
have
any
etiquette
to
make
sure
that
people
don't
merge
the
pull
requests
early
and
the
answer
is
yeah.
That's
so
get
up
defaults
to
open
this.
You
can,
with
things
like
protected
branches,
now
prevent
people
from
hitting
the
merge
button.
But
we
don't
do
that.
Generally
speaking
and
we
do
it,
we
do
have
an
etiquette.
A
So
if
it's
a
small
ship,
if
it's
a
tiny
change
or
adding
one
line
or
updating
a
typo,
we'd
say,
go
ahead
and
merge
it
yourself
for
pretty
much
everything
else.
We
wait
to
get
a
sign-off,
usually
an
emoji,
so
I
cache
two
patzcuaro,
the
actual
ship
or
a
+1.
Something
like
that
and
that's
our
internal
convention
so
yeah
it
does
require
having
a
culture
of
trust,
but
that's
something
we
try
to
build
and
maintain,
because
we
find
that's
much
more
enjoyable
and
more
effective
workplace.
A
Oh
so
it
would
be
so
there's
a
close
relationship
between
the
the
compare
view
and
the
pull
request.
The
compare
view
by
itself
is
going
to
show
you
commits
that
are
unique
to
a
given
branch
right
there.
So
that's
gonna
be
most
useful
if
that
branch,
if
a
poor
request,
has
not
been
opened
on
that
branch,
yet
that's
the
real
use
case
for
that,
so
somebody's
pushed
it
up
but
doesn't
happen
to
have
open
to
pull
request.
A
Yet,
generally
speaking,
if
you
have
a
lot
of
unique
commits
and
especially
its
recent
work,
you
intend
to
probably
open
a
pull
request.
So
that's
why
the
button
exists
there
to
go
from
the
compare
view
to
opening
the
PR
and
then
that's
where
the
discussion
would
ensue,
and
presumably
you
want
to
ultimately
merge
it
in.
If
you
want
to
just
have
that
discussion,
and
you
realize
you
don't
want
to
merge
it,
you
can't
a
call
always
of
course
close
the
pull
request
and
archive
that
discussion
effectively.
A
So
the
question
is:
if
you
need
a
poor
quest
to
have
a
discussion,
the
answer
to
that
is
no
depends
on
what
kind
of
discussion
you
want.
So
you
can
have
an
issue,
for
example,
use
get
up
issues
to
have
a
general
discussion.
We
generally
speaking,
we
will
open
an
issue
if
we
have
a
higher
level
discussion,
but
we
don't
know
how
that
would
actually
look
in
the
source
code
yet
so
like
do
we
want
to
redesign
the
homepage,
that's
a
discussion
we'll
have
in
an
issue.
A
A
A
So
the
question
had
to
do
with
an
option
that
hub
gives
you
to
turn
an
issue
into
a
pull
request.
We
don't
happen
to
use
it
internally.
Very
much
so
I
don't
have
a
very
strong
opinion
on
it.
I
don't
happen
to
use
it
in
my
personal
work,
but
that's
not
to
say
you
shouldn't
I
just
happened
not
to
have
have
an
opinion
one
way
or
the
other
yeah
any
other
questions
out
there
happy
to
entertain
them.