We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Devops Cicd
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Devops Cicd
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
A team used long-lived feature branches. A developer worked on a feature branch for three weeks without merging. When they finally tried to merge, the branch had diverged so far from main that there were 47 merge conflicts across 120 files. Resolving them took two full days, introduced bugs, and required retesting the entire feature.
Branch strategies define how a team organizes parallel work. The right strategy minimizes merge conflicts, keeps the main branch deployable, and enables continuous delivery. The wrong strategy creates integration nightmares.
Google's monorepo has 86 TB of data and 2 billion lines of code. 25,000+ developers commit to it. They use trunk-based development, committing directly to the main branch (with code review). If trunk-based works at that scale, the argument that "our team is too complex for trunk-based" doesn't hold up.
| Strategy | How It Works | Best For |
|---|---|---|
| Trunk-based | Everyone commits to main (or very short-lived branches, hours). Feature flags hide incomplete work. | Teams practicing continuous deployment |
| GitHub Flow | Short feature branches (1-3 days), PR to main, deploy from main | Most teams. Simple and effective. |
| GitFlow | Develop, feature, release, hotfix branches | Large teams with scheduled releases |
| Release branches | Branch per release version, cherry-pick fixes | Products with multiple supported versions (mobile apps, SDKs) |
Trunk-based development is the gold standard for high-performing teams. Google, Meta, and Netflix use it. The 2023 DORA report confirms: teams that practice trunk-based development with short-lived branches (less than 1 day) have 2x the deployment frequency and 3x faster recovery from failures than teams using long-lived branches.
The key metric: how long do branches live?
| Branch Lifetime | Merge Conflict Risk | Recommended |
|---|---|---|
| Hours | Very low | Trunk-based |
| 1-3 days | Low | GitHub Flow |
| 1-2 weeks | Medium | OK with daily rebases |
| 3+ weeks | High | Avoid |
When NOT to use trunk-based. When the team lacks the infrastructure for feature flags, automated testing, and continuous integration. Trunk-based development without these safeguards results in a broken main branch. Start with GitHub Flow and evolve toward trunk-based as matures.