Git Without Branches - Simple, Smooth, Scalable

download Git Without Branches - Simple, Smooth, Scalable

If you can't read please download the document

Transcript of Git Without Branches - Simple, Smooth, Scalable

  • 1. Git Without Branches -Simple, Smooth, ScalableDefusing the Git Complexity BombbyPieter Hintjens, CEO, iMatixBerlin Buzzwords 2013, 3 June, 2013

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. 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 dont scale 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. 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. 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? 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. 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 bombthat 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. If you want to try this Read C4.1(rfc.zeromq.org/spec:22) Look at a project thatuses it Read my ZeroMQbook (OReilly),Chapter 6 15. Thanks! See you here tomorrow at 12pm for anexplanation on how were doing security forZeroMQ Email me: [email protected] Twitter: @hintjens Blog: hintjens.com