1. Git Without Branches -
Simple, Smooth, Scalable
Defusing the Git Complexity Bomb
by
Pieter Hintjens, CEO, iMatix
Berlin Buzzwords 2013, 3 June, 2013

2. Git is easy...
... once you understand that a git
branch is just a folded five-
dimensional lepton space that has a
detached history with no intervening
cache.

3. Git makes me feel stupid
● (I love git... but)
● Inconsistent and arbitrary commands
● Too many concepts to learn
● Too many ways to make mistakes
● Too much space for opinion
● Every team has to invent a strategy

4. Git-flow is a popular strategy
● Has base branches (master, develop)
● Has feature branches
● Has release branches
● Has hotfix branches
● Has support branches
● Has its own git extensions
● Is this making life simpler?

5. Complexity
● Engineers just enjoy making stuff
● Complexity makes us feel stupid
● We make mistakes
● We lose confidence
● We fight over “unicorn policies”
● Outcome: projects that don't scale

6. The Git Complexity Bomb
● Branching is a poor solution for poor processes
● Complexity oriented design & trash oriented
design
● The process becomes harder to fix
● You can't fix just part of this picture
● Defusing the bomb needs a holistic intervention

7. Simplicity
Some quotes from my favorite author:
● “Simplicity beats functionality, every time”
● “If you can't understand it on a cold Monday
morning before coffee, it's too complex!”
● “Design by removing problems, not adding
features”

8. Simplicity Oriented Design
● Small patches to precise problems
● Fork + pull request for every single patch
● Contributor-maintainer ping-pong
● Accuracy over speed
● Community over code
● Bundled up as C4.1 protocol

9. In Practice
● Development repo has 1 branch = master
● Pull requests always applied to master
● Travis CI for builds & regression tests
● Stable releases are forked off
● Cherry pick fixes from master to stable

10. Branches vs. Forks
● How complex is the organization?
● What's the change latency?
● What is the learning curve for newcomers?
● How many ways can we screw up?
● How much upfront coordination do we need?

11. Branches vs. Forks
● Who owns what we make?
● Can our agreements survive arguments?
● How safe is my code from your errors?
● How visible is this project?
● How large can the project scale?

12. Does it work?
● We switched ØMQ in Dec 2011 after much talk
● Initial reactions: mixed and apprehensive
● After 18 months, ~70 contributors (from 2-3)
● Dev master is perfect most of the time
● Community is happy, and we use this widely
● Easy to learn, and smooth to drive

13. Conclusions
● Git branches are part of a “complexity bomb”
that may be damaging your projects
● By switching to a better development process
you eliminate the need for branches
● The result is a simpler, kinder Git that is much
easier to learn, and safer to use
● And that gives you larger, more successful
projects

14. If you want to try this
● Read C4.1
(rfc.zeromq.org/spec:
22)
● Look at a project that
uses it
● Read my “ZeroMQ”
book (O'Reilly),
Chapter 6

15. Thanks!
● See you here tomorrow at 12pm for an
explanation on how we're doing security for
ZeroMQ
● Email me: ph@imatix.com
● Twitter: @hintjens
● Blog: hintjens.com