Git Without Branches - Simple, Smooth, Scalable
- 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