際際滷

際際滷Share a Scribd company logo

Git Without Branches - Simple, Smooth, Scalable

Download as ODP, PDF
P
pieterh

The document discusses how Git complexity can be reduced by eliminating branches in favor of forks and pull requests. It argues that branching leads to complex strategies and processes that don't scale well. By switching to a model where every change is a pull request to a single master branch, projects can be simplified, mistakes reduced, and collaboration improved. The author provides an example of switching to this approach with the MQ project, which saw growth from a few to over 70 contributors as a result of the simpler, kinder process.

1 of 15
Downloaded 16 times
Git Without Branches - Simple, Smooth, Scalable Defusing the Git Complexity Bomb by Pieter Hintjens, CEO, iMatix Berlin Buzzwords 2013, 3 June, 2013
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.
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
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?
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
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
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
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
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
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?
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?
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
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
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
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

More Related Content

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