►
Description
Presented by Kyle Dumont
Many hardware teams are starting to leverage the power of git by piecing together disparate tools, but they’re still stuck in the past, especially when compared to software development. This session will cover the best practices hardware engineers have shared with us for adapting git workflows in hardware development.
About Git Merge:
Git Merge is dedicated to amplifying new voices in the Git community and showcasing the most thought-provoking projects from developers, maintainers, and teams around the world. Git Merge 2022 took place at Morgan Manufacturing in Chicago, IL on September 14th and 15th.
A
A
Also
thinking
you
know,
here's
my
opportunity
to
build
a
hardware
workflow
from
the
ground
up.
You
know
the
the
green
space
for
New
Opportunities
sky's
the
limit.
Unfortunately,
when
I
looked
around
there's
several
things,
I
didn't
see,
you
know
what
I
needed
was
a
process
to
organize.
You
know
design,
Source
documentation
and
release
outputs.
This
probably
looks
pretty
familiar
to
a
lot
of
you.
A
I
need
to
do
it
to
be
flexible
without
requiring
manual,
exports,
updating
part
numbers
or
anything
like
that,
and
it
needed
to
be
lightweight
to
set
up
and
manage
out
of
the
box.
You
know
we
didn't
have
the
budget
to
you
know
subscribe
somebody
full
time
to
managing
a
system
looking
around
at
the
industry
and
kind
of
pulling
from
my
previous
experience.
This
is
generally
what
I
found
we
had.
A
Svn
was
pretty
common
in
Hardware
as
as
a
lot
of
you're
familiar
with
from
software
before
git
came
around,
and
you
know,
I
knew
enough
from
my
work
in
firmware
and
software
on
the
side
that
the
industry
was
really
moving
away
from
SVN
they
get.
Was
you
know
the
the
new
product
that
was,
you
know,
pulling
a
lot
of
development
I'm,
getting
a
lot
of
support,
had
great
documentation
and
really
pulling
the
industry
forward,
so
SBN
was
kind
of
looking,
not
not
so
not
like
such
a
good
option.
A
There's
also
PLM,
which
stands
for
product
life
cycle
management.
If,
if
all
of
you
have
not
had
the
pleasure
of
working
with
PLM
systems,
they're,
essentially,
you
know
pretty
pretty
straightforward
object.
Data
storage
with
kind
of
brutalist,
UI,
proprietary,
apis
and
all
sorts
of
kind
of
fun
interfaces
like
that
in
in
where
and
still
are,
very
common
in
in
Hardware
design,
generally
used
more
for
managing
with
suppliers
working
with
operations
team
where
we
kind
of
are,
are
looking
at
as
the
deployment
for
Hardware
engineering.
A
Now,
as
we
look
for
the
future,
of
course,
we
also
had
Dropbox
and
shared
file.
Network
file
storage.
You
get
such
fun,
you
know
system
or
workflows
in
this
kind
of
wild
west
style
of
product
design,
where
you
get
v1.0,
v2.0,
V,
2.0,
final
e,
2.0,
final
final
and
then
okay,
really
final
final,
we're
we're
serious
this
time
and
that's
what
ships
out
the
door.
A
A
We
saw
a
lot
of
young
Hardware
companies
moving
to
GitHub
and
that's
ultimately,
what
we
ended
up
doing
when
we
looked
at
around
a
lot
of
our
our
contemporaries
and
Hardware
startups.
That
was
the
big
Trend,
but
unfortunately
like
most
of
them,
we
ran
into
very
limited
capabilities,
especially
when
it
came
down
to
binary
files,
no
diff,
which
meant
we
really
couldn't
do
a
merge
request.
We
really
couldn't
do
branching
even
releases.
A
A
You
know
when
we
look
across
the
the
system
of
Hardware.
Design
This
is
not
an
easy
problem.
There
are
lots
of
tools.
We
have
CAD
design
tools,
documentation.
You
know
right
in
the
middle
I
put
email
or
as
Hardware
teams
like
to
call
it
continuous
deployment
and
and
that
all
has
to
come
together
and
be
connected
together.
You
know,
usually
with
systems
that
aren't
meant
to
integrate
right
out
of
the
box.
A
A
You'll
maybe
do
five
at
Max,
maybe
six
releases
throughout
a
year
and
they're
they're
pretty
well
defined
ahead
of
time,
and
so
that
was
one
of
the
reasons
it
could
kind
of
get
away
with
doing
fewer
releases,
having
inefficiencies,
because
it
wasn't
impacting
them
as
much.
You
also
had
all
of
these.
You
know
one
of
the
other
frictions
was
you
have
these
all
these
file
formats
and
Integrations
that
I
showed
on
the
previous
page?
A
A
lot
of
them
are
binary
formats
very
deliberately
from
the
industry
built
up
walled
Gardens
that
the
typical
product
release
cycle
and
Hardware
was
to
you
know.
If,
if
you
wanted
to
introduce
new
product
to
the
industry,
you
would
get
everybody
to
use
your
CAD
design
tool
and
then
build
out
that
ecosystem
around
it
and
didn't
really
play
well
with
others,
which
is
still
a
lot
of
a
lot
of
the
case
in
the
industry
and
then
there's
also
this.
A
This
kind
of
last
couple
is
just
the
the
focus
less
of
a
focus
and
Hardware
on
or
potentially
even
Obsession
of
productivity
in
the
hardware
space
as
compared
to
software.
In
fact,
a
lot
of
Hardware
teams
are
are
still
somewhat
focused
on.
You
know
getting
first
pass
success
partially
because
of
you
know
some
expense
that
goes
with
designing
new
hardware
projects,
but
partially
because
of
the
the
culture
that's
built
up
in
the
hardware
ecosystem,
and
then,
of
course,
you
know
the
learning
curve.
A
So
just
to
dig
a
Little
Deeper,
you
know,
technical
limitations
are
large.
Binary
files
doesn't
play
nicely
with
Git
Delta
compression
very
few
tertiary
features
that
you
may
get
from
a
broader
GitHub
or
gitlab
ecosystem.
The
long
release,
Cycles
waterfall
methodologies
in
needing
alignment
for
teams
and
then
worldwide
Communications
really
became
frictions
in
this
space.
A
So
all
of
a
sudden,
the
the
designers
that
are
Behind
These
systems
are
no
longer
away
allowed
to
get
away
with
these
kind
of
very
forward-looking
release.
Cycles,
all
of
a
sudden
they're
getting
notes
from
factories
in
saying
we're
going
to
have
to
shut
down
the
the
the
the
the
factory
or
the
the
product
line,
because
we
can
get
some
chip
and
you
need
to
design
a
new
trip,
qualify
and
release
it
in
the
next
few
days.
Otherwise,
we're
shutting
things
down,
there's,
of
course,
the
move
to
remote
teams.
A
You
know
largely
due
to
covid
there's
in
the
push
to
improve
relationships
with
contract
manufacturers
and
a
lot
of
you
know
new
capabilities
for
quick
term
prototyping,
so
that
cost
that
we
had
earlier,
for
you
know,
potentially
the
perceived
cost
that
it's
going
to
cost
us
a
lot
of
money
and
take
a
while
to
get
a
design.
So
we
better
have
it
right,
it's
kind
of
going
away.
You
can
get
pcba
designs
in
in
a
couple
days.
A
At
least
you
know,
I'd
be
a
long
compile
time,
but
you
know
it's
something
that
at
least
is
manageable
and
then,
of
course,
there's
the
pressure
to
iterate
designs
to
keep
Pace
with
changing
consumer
demands
and
Technologies.
All
these
pressures
to
move
faster,
especially
when
a
lot
of
the
other
teams
Hardware
Engineers,
are
working
with,
are
also
able
to
move
so
much
faster.
So
you
know,
git
has
enabled
software
Engineers
to
iterate
very
quickly,
be
very
flexible,
be
nimble.
A
A
What
we
need
is
flexibility,
so
these
the
the
day
of
manual
exports,
in-person
design
reviews
is
going
away
Okay,
so
our
company
exists
largely
because
we
believe
that,
at
the
end
of
the
day
there
are
a
lot
more
similarities
than
there
are
differences
in
in
in
hardware
and
software
designs,
for
instance,
similarities.
Of
course,
the
desire
for
organized
design,
data
revision,
control
and
review,
asynchronous
collaboration,
desire
for
automated
design,
validation
and
release
supported
documentation
alongside
design
data.
Markdown
has
been.
A
You
know
for
one
of
the
biggest
Technical
and
usability
differences.
Is
that
we're
generally
working
with
vector
graphics,
design,
data
schematics
and
printed
and
circuit
boards
a
lot
of
times?
These
are
binary,
but
not
always
because
of
the
the
bullet
point
above
even
if
they're,
not
binary
files
presenting
a
user,
a
schematic
textual
difference
isn't
very
important
because
they're
so
used
to
seeing
things
visually
and
consuming
information.
That
way,
there's
also
generated
output,
design
files
included
in
reviews.
A
This
is
an
area
where
I
actually
think
the
hardware
folks
have
something
to
teach
software
a
little
bit,
because
I
think
this.
This
desire,
for
you,
know,
reviewing
the
outputs
whether
that's
compiled
code
or
whether
that's
a
new
UI
in
software,
is
as
part
of
a
pull
request,
is
important,
but
in
the
hardware
communities
they're
so
used
to
doing
this
that
it
it's
kind
of
expected
coming
in
and
then
there's
the
strong
need
for
some
assemblies
and
in
assemblies.
A
A
So,
to
dig
a
little
bit
deeper
and
see
what
this
looks
like
you
know,
our
company
really
exists
to
kind
of
run.
This
translation
from
software
to
Hardware
applied
to
hardware-
and
you
know
what
you
might
expect
in
the
software
space
is-
is
a
textual
diff
green,
highlighted
text
red
deleted
text?
What
we
show
is
green
highlighted
elements
ready
for
deleted
elements
in
a
visual
format.
You
would
expect
inline
code
comments
and
design
reviews.
A
You
know
what
we've
introduced.
The
market
is
visual
Snippets
and
then,
when
we
look
at
cicd
in
terms
of
units
as
integration
tests.
Well,
there's
this
whole
concept
of
simulation
and
so
much
information
that
we
can
kind
of
give
to
the
users
give
to
the
hardware
Engineers
about
their
design.
That
is
currently
actually
being
withheld
from
them,
and
this
is
what
that
looks
like
so
for
diffs
on
the
left.
You
can
see
your
typical
textual
diff
and
on
the
right
you
can
see.
A
So
this
is
what
our
Snippets
look
like
on
the
left.
You
know
in
code
comment,
you
know
feedback
and
then
on
the
right.
You
can
grab
a
specific
section
of
your
design.
You
can
comment
on
that
for
feedback
tag.
Somebody
just
like
you
would
in
software
that
all
becomes
part
of
the
designer
view,
part
of
that
kind
of
immutable
documentation
that
you
get
as
part
of
just
using
a
git
workflow
and
the
really
exciting
part
for
us,
as
we
start
to
look
forward
into
this
year
and
into
next
year,
is
cicd.
A
So
just
like
git,
you
know
build
up
this
whole
world
of
CI
and
CD
that
so
many
of
us
are
working
in
today
we
see
the
same
thing
happening
in
Hardware,
there's
no
limit
to
what
we
can
test
with
component
information
and
really
allow
a
flexible
system
for
users
and
Hardware
Engineers
to
design
their
own
tests.
This
can
go
all
the
way
from
you
know.
A
So
we've
we've
introduced
that
it's
been
really
exciting.
It's
been
awesome
to
work
on.
You
know
we're
kind
of
laying
the
groundwork
for
git
for
Hardware
design.
You
know
as
we're
continuing
to
build
for
the
future.
We
have
a
lot
of
you
know
really
interesting
technical
problems
that
we're
continuing
to
solve.
A
You
know
these
are
some
areas
where
you
know
myself
and
my
colleagues
are
at
this
this
event,
even
to
learn
a
little
bit
more
about
you
know
we
still
have
to
to
help
our
users
better,
manage
binary
and
large
files
is
lfs
going
to
be
the
solution
there.
Maybe,
but
we
also
look
at
you,
know,
potentially
extending
our
implementation
of
git
to
have
hooks
that
maybe
transform
data
into
a
more
Delta
compressible
schema,
ecad
file
merging,
is
a
big
deal.
A
You
know,
of
course,
the
beauty
of
building
on
top
of
the
git
is
that
we
have
either
the
base
functionality
or
the
plumbing.
For
so
many
of
these
things,
I
mean
git
has
been
extended
in
so
many
directions
that
it's
been
a
technology.
That's
really
enabled
us
to
to
build
up
some
of
these
capabilities,
no
matter
where
the
industry
tends
to
pull
us.
It
also
aligns
really
well
with
software.
You
know
integrators
for
GitHub
and
gitlab
and
in
bitbucket
as
well
have
been
really
helpful,
especially
when
we
talk
about
you
know.
A
Helps
teams
just
iterate
faster.
We
know
we
need
to
get
them
more
flexible.
We
know
we
can't
accept
a
three-week
in-person
scheduled
design
review.
It
has
to
be
async,
it
has
to
be
digital
and
remote,
and
then
it's
integrated
and
customizable.
So
we
we
need
to
break
down
the
barriers
of
Walled,
Gardens,
proprietary
software
and
proprietary
interfaces
and
exposed
data
to
Consumers.
Let
them
connect
it
to
the
other
tools
that
they're
doing.
A
We
have
no
intention
of
being
the
best
in
class
for
every
single
thing
that
the
hardware
Engineers
are
doing
in
their
day-to-day
workflow.
So
being
able
to
connect
to
other
tools
is
really
important
and
it
needs
to
be
easy
to
adopt
it
scalable,
you
know
we're
not
hiring
Consultants
to
come
in
and
set
up.
You
know
a
a
git
solution
at
a
startup.
It's
just
not
gonna,
not
gonna
happen.
A
In
more
and
more,
we
see
even
the
larger
companies
want
to
democratize
their
data
management.
They
want
to
enable
their
Engineers
to
do
more
of
their
design,
have
more
control
and
autonomy
over
what
they're
working
on,
because
you
know
we
view
repositories
for
really
an
extension
of
Engineers,
so
really
extension
of
designers
to
be
able
to
say
hey.
This
is
how
my
design
data
is
going
to
be
presented
and
how
I'm
going
to
communicate
it.
A
A
So
once
we
get
there,
you
know
we
really
see
the
the
growth
of
CI
and
CD
and
Hardware.
We
see
cross-disciplinary
teams
coming
together
test
driven
development,
even
you
know,
pulling
it
from
software
Translating
that
to
Hardware
in
a
new
chapter
of
Open,
Source
formats
and
Integrations,
and
that's
really
it
I
think
we
have
time
for
maybe
one
or
two
questions.
If,
if
we
have
the
mic
available.
A
A
A
So
us
being
able
to
to
you
know
be
the
middleman
between
the
chip
manufacturers
and
the
the
the
engineer
at
the
end
of
the
day
is
really
desirable
for
them.
There
has
been
a
lot
of
efforts
to
standardize
some
ship
information
and
data.
Pdf
has
generally
been
the
the
old
way
of
doing
things,
not
surprisingly
they're,
going
away
from
that
into
more
more
again
standardized
in
tax-based
encodings.