Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Git Without Branches - Simple, Smooth, Scalable


Published on

  • Login to see the comments

Git Without Branches - Simple, Smooth, Scalable

  1. 1. Git Without Branches -Simple, Smooth, ScalableDefusing the Git Complexity BombbyPieter Hintjens, CEO, iMatixBerlin Buzzwords 2013, 3 June, 2013
  2. 2. Git is easy...... once you understand that a gitbranch is just a folded five-dimensional lepton space that has adetached history with no interveningcache.
  3. 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. 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. 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 dont scale
  6. 6. The Git Complexity Bomb● Branching is a poor solution for poor processes● Complexity oriented design & trash orienteddesign● The process becomes harder to fix● You cant fix just part of this picture● Defusing the bomb needs a holistic intervention
  7. 7. SimplicitySome quotes from my favorite author:● “Simplicity beats functionality, every time”● “If you cant understand it on a cold Mondaymorning before coffee, its too complex!”● “Design by removing problems, not addingfeatures”
  8. 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. 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. 10. Branches vs. Forks● How complex is the organization?● Whats 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. 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. 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. 13. Conclusions● Git branches are part of a “complexity bomb”that may be damaging your projects● By switching to a better development processyou eliminate the need for branches● The result is a simpler, kinder Git that is mucheasier to learn, and safer to use● And that gives you larger, more successfulprojects
  14. 14. If you want to try this● Read C4.1(● Look at a project thatuses it● Read my “ZeroMQ”book (OReilly),Chapter 6
  15. 15. Thanks!● See you here tomorrow at 12pm for anexplanation on how were doing security forZeroMQ● Email me:● Twitter: @hintjens● Blog: