GIT Strategies for Trunk-Based Development
Many teams transitioning to Trunk-Based Development face a challenge: How do we integrate testing environments without disrupting the continuous flow to main?
Hello, developers! 🚀
Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!5t
Before starting, I quickly remind you that my brand new Test-Driven Development 101 5-day Email Course is available: it is the introduction to TDD I wish I had when I started learning it, so I think you will find it very useful!
As a subscriber to my newsletter, you can have it with a 10EUR discount! 👇
Now, let's dive into today's micro-topic!
In short
🚀 Trunk-Based Development (TBD) promotes fast, incremental, and safe delivery, but integrating a staging environment without disrupting the workflow is a challenge.
✅ Staging should be a validation tool, not a bottleneck. Release automation should be simple and automatic, and staging should be temporary rather than a fixed step.
🔄 Three Approaches to Staging in TBD
1️⃣ Main → Staging, Tag to Production
2️⃣ Main → Production, Branches to Staging on Demand
3️⃣ Main → Production, with on-demand Staging environments
GIT Strategies for Trunk-Based Development
Many teams transitioning from GitFlow or other complex branching strategies to Trunk-Based Development (TBD) face a critical challenge:
💡 How do we integrate testing environments without disrupting the continuous flow to
main?
In traditional branching workflows, a staging branch acts as a buffer before production, ensuring changes are tested in a controlled environment. But in TBD, changes are continuously merged into main, making it the single source of truth.
🚀 The goal of TBD is to maximize fast, incremental, and safe delivery—but what happens to staging in this new model? Should it be eliminated entirely, or is there a way to keep its benefits without introducing bottlenecks?
If your team is struggling with - or worried by - this transition, here are three practical approaches to handle staging while keeping your workflow lightweight and efficient - from the less to the more advanced.
🔹 Option A: main → staging, tag → production
This is the most simple and easy approach, which makes it a good starting point for teams moving to TBD.
How It Works:
✅ main is continuously deployed to staging
✅ Once changes are validated, a release tag is created to deploy to production
✅ Short-lived branches (max 1 day) are allowed to benefit from pull request automation
Pros:
✔️ Maintains a clear separation between staging and production
✔️ Teams can still manually validate features in staging before release
✔️ Works well with existing CI/CD pipelines
Cons:
❌ Still relies on a staging step, which can slow down the feedback loop
❌ Requires discipline to ensure main is releasable to production
✅ Best For: Teams transitioning from GitFlow or other complex GIT strategies that still want a buffer before production while reducing complexity.
🔹 Option B: main → production, test branches on demand
This approach aligns more closely with Trunk-Based Development principles while keeping staging available when needed.
How It Works:
✅ main is deployed directly to production 🚀
✅ A separate staging branch is created only when necessary
✅ Developers push feature branches to staging on demand to test before merging
Pros:
✔️ Faster releases, since main is production-ready at all times
✔️ Commit-based versioning can be used, which is more coherent with a continuous integration approach than tag-based versioning
✔️ Developers can still test in a controlled environment when needed
Cons:
❌ Requires clear rules on when staging should be used and a good automated pipeline to ensure production release are safe
❌ Needs an easy way to deploy a branch to staging on demand
✅ Best For: Teams ready to move towards true TBD, but still need occasional manual testing.
🔹 Option C: Fully Dynamic Environments 🌟
The most advanced approach—completely eliminating staging as a bottleneck by using on-demand environments.
How It Works:
✅ main is always deployed to production
✅ No fixed staging branch—temporary environments are set up when needed
✅ Infrastructure as Code (IaC) is used to automatically create and tear down testing environments
Pros:
✔️ Enables parallel testing without blocking releases
✔️ Removes the staging bottleneck entirely
✔️ Fully aligns with Continuous Delivery best practices
Cons:
❌ Requires mature DevOps and Infrastructure as Code (IaC) capabilities
❌ More complex setup compared to traditional workflows
✅ Best For: High-performing teams with strong automation and DevOps capabilities, aiming for true Continuous Deployment.
Key Takeaways
✔️ Staging should not block releases → Use it for validation when needed, but don’t promote from staging to main.
✔️ Keep release automation simple → Any push to staging should auto-deploy, no manual steps.
✔️ Embrace disposable staging → Treat it as a sandbox, not a bottleneck.
Adopting Trunk-Based Development is not just about merging faster—it’s about delivering value continuously and safely. Choosing the right strategy will help your team move faster while maintaining stability.
🇮🇹 Calling my Italian readers!
🚀 Want to master Continuous Integration and safely hide work in progress?
Join my hands-on Mastering CI: Fast Releases for Modern Team Workshop, organized in collaboration with Crafted Software Community, where you'll learn to implement these techniques in real-world projects. Say goodbye to long-lived branches and risky deployments—embrace seamless integration with confidence!
📅 Dates: March 29th, April 5th and April 12th. (3h sessions, 10am-1pm).
🎟️ Spots are limited—Sign up now and take your development workflow to the next level! 🚀
Until next time—happy coding! 🤓👩💻👨💻