--- title: "Single Branch" url: "https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/single-branch.md" canonical: "https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/single-branch/" tags: [] author: "Roy Osherove" description: "Lesson 13 of 17 in Beautiful Builds and Continuous Delivery Patterns (Branching Patterns for Continuous Delivery), 3:43. Free video by Roy Osherove." usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Single Branch 1. [Courses](https://courses.osherove.com/#courses) 2. [Beautiful Builds and Continuous Delivery Patterns](https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/) 3. Branching Patterns for Continuous Delivery Lesson 13 of 17 Duration: 3:43 [Watch on YouTube](https://www.youtube.com/watch?v=V717PfFF0tE) ## In this lesson Roy Osherove calls working on a single branch, labeling each release, the perfect match for [continuous delivery](https://pipelinedriven.org/article/continuous-delivery-values "Continuous Delivery Values (pipelinedriven.org)"), because nothing waits for humans on the way to staging or production. Release branches may still be needed for multiple releases, and features that are not done yet are what [feature toggles](https://pipelinedriven.org/feature-toggle-frameworks-list "Feature Toggles (pipelinedriven.org)") are for, which he leaves for a separate video. Once there are users, or QA using staging, he adds a parallel fire hose: a fully automated development environment that looks like staging, with the human test, staging and production environments deployed on a schedule. ## Transcript 648 words [\[00:03\]](https://www.youtube.com/watch?v=V717PfFF0tE&t=3s) Okay, let's talk about single trunk or no [branching strategy](https://pipelinedriven.org/article/2015/5/30/bbbctc-branching-binaries-builds-coding-and-testing-culture "BBBCTC - Branching, Binaries, Builds, Coding and Testing Culture (pipelinedriven.org)"). Basically, no branches, right? Your life is a big nice single branch. So, you want to deploy, you just deploy everywhere. And in a way, a single branch development strategy is the ultimate the perfect match for [continuous delivery](https://leanpub.com/pipelinedriven "The Holy Grail of Continuous Delivery (pipelinedriven.org)") because there's nothing that's stopping you from deploying to staging or even production. Or you can if you want to and you have permission to you can automate deployment everywhere to as far as you need to all the way to the customer because you don't have to wait for humans on the way. [\[00:42\]](https://www.youtube.com/watch?v=V717PfFF0tE&t=42s) So there's no branching that's currently needed. Now this is not always true, right? you have a main but sometimes you might want to actually label or tag whenever you have a release and sometimes your organization wants to create multiple releases. So in that case release branches might be needed. But if you don't need that if you don't need release branches because you only have a single release and you're working in a small team then there is no sense in creating new branches at all. [\[01:15\]](https://www.youtube.com/watch?v=V717PfFF0tE&t=75s) You can just work on the single branch and just label every release. And of course, you're going to ask, well, what happens if I have a feature that's not done yet? I don't want to merge it back in. It will break the current feature. And this is what [feature toggles](https://pipelinedriven.org/feature-toggle-frameworks-list "Feature Toggles (pipelinedriven.org)") are for. And we'll talk about them in a separate video. But assuming that you could actually solve this problem, then a single branch that just deploys everywhere is the is the thing that you can automate in the easiest way. And it's kind of the perfect match. [\[01:46\]](https://www.youtube.com/watch?v=V717PfFF0tE&t=106s) And of course it also means that that you can deploy multiple times a day and you can also make things a bit dirtier multiple times a day. So you can actually break staging multiple times a day etc. And that's either good or bad depending on if you have current if you currently have users or not because if your project is in a very very early stage nobody cares yet about staging or production. You can just deploy to these empty environments and nobody cares. But if your project already has users, it has or maybe there's a QA department just waiting to get their hands on staging or they're using staging between 9 to5 or anything like that then we have to move to a different strategy which we talked about before and that is the parallel fire hose. [\[02:28\]](https://www.youtube.com/watch?v=V717PfFF0tE&t=148s) So here you can see that we have QA and analysts and they're using production we have users. So now we still have a single branch but we have at the bottom we have a parallel fire hose. So we have a parallel environment for development and and it's fully automated and we have a human test and human staging that gets deployed to maybe on a schedule and then deployed to production which can get deployed on a schedule. But at least we get the feedback as close to the customer as possible in something that looks like staging [\[03:03\]](https://www.youtube.com/watch?v=V717PfFF0tE&t=183s) Multiple times a day. And we don't care because we we will not break the user's environment because we have our own environment. And we'll only deploy to the users once or twice a day whenever they need to. Or they can just pull a button, click a button, and pull the latest stable version when they choose to. Either way, life is much easier because there's no no merging involved and if we want to, we can get feedback as close as possible. U the only thing is that now we might need humans to say yes, it's okay to deploy to production, but it's still less [\[03:38\]](https://www.youtube.com/watch?v=V717PfFF0tE&t=218s) Troublesome than also waiting for merges, etc. ## Related - [BBBCTC - Branching, Binaries, Builds, Coding and Testing Culture](https://pipelinedriven.org/article/2015/5/30/bbbctc-branching-binaries-builds-coding-and-testing-culture) · pipelinedriven.org Roy on what moving to fewer branches takes: gated builds on trunk and feature toggles for unfinished work. - [Feature Toggles](https://pipelinedriven.org/feature-toggle-frameworks-list) · pipelinedriven.org Roy's list of feature toggle frameworks by language, for the unfinished features this lesson leaves to toggles. - [Build Pattern: Gated Commit](https://osherove.com/blog/2013/1/20/build-pattern-gated-commit.html) · osherove.com Build pattern for checking changes on the CI server before they reach the master branch, which keeps a single branch from breaking. ### Also linked in this lesson #### pipelinedriven.org - [Continuous Delivery Values](https://pipelinedriven.org/article/continuous-delivery-values) - [The Holy Grail of Continuous Delivery](https://leanpub.com/pipelinedriven) [Previous lesson Branch per Promotion](https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/branch-per-promotion/) [Next lesson Release Branches](https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/release-branches/) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/