DEV Community


Discussion on: How to organize your git branches

adymitruk_64 profile image
Adam Dymitruk

Right. Because the Linux kernel doesn't scale. TBD is based on pseudo science, usually coming from the agile dogma proponents. I'll show you peer reviewed papers on the benefits of smoking too.

Thread Thread
mrlarson2007 profile image
Michael Larson • Edited

I can't really speak to how Linux project works or how they organize their code. What I can tell you is that there has been research done that shows that TBD allows an organization to scale as their code velocity increases and the number of developers increases too. Great book that has results from a multi year study said this:

  1. Teams that developed off trunk/master had more frequent and stable releases and did not need a "code freeze" to stabilize things regardless of size
  2. As long as branches are short lived, and integrated daily with trunk/master it does not violate the spirit of TBD.
  3. longer lived branches are acceptable for open source since not everyone is working on it full time.

Forsgren PhD, Nicole. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations (Kindle Locations 971-985). IT Revolution Press. Kindle Edition.

I can also attest to this from personal experience working on a large volunteer project with lots of developers, before starting TBD merging feature branches was stressful event and took hours to complete. We went from quarterly releases to weekly after we switched to TBD and other changes that where made to support that. We could not do that if we still had those long lived feature branches, and we no longer have to deal with the pain of merging large branches of code.

Thread Thread
mrlarson2007 profile image
Michael Larson

Adam, if you have any research that shows the opposite I would be certainly interested in reading it. At the end of the day its up to you to decide how you want to organize your projects. I know there is a time places for branches, but the trouble I have seen is the longer these branches live, the more pain they cause. There is a tipping point where any benefit to placing code in a feature branch is out weighed by pain it causes the team when they need to integrate that code back into the main line.