Hello! Welcome back to your DevOps interview preparation course.
In our last lesson, we designed a robust, multi-stage CI/CD pipeline, focusing on quality gates and a layered testing strategy. We established that the goal of a great pipeline is to enable fast, reliable delivery of code to production.
Today, we'll address a fundamental question that directly impacts the effectiveness of that pipeline: How should your team manage code changes in Git? The branching strategy you choose is not just a technical detail; it dictates your team's workflow, collaboration patterns, and, most importantly, your potential deployment frequency.
This lesson focuses on the learning outcome: Compare different branching strategies (trunk-based, GitFlow, feature branching) and their impact on deployment frequency. This is a classic DevOps interview topic, and by the end of this lesson, you'll be able to articulate the trade-offs of each model and recommend the right one for a given scenario.
1. Why Git Workflows Matter
When Git was created, it offered immense flexibility but no prescribed way of working. This led teams to create conventions, or "workflows," to ensure consistency. The right workflow for a team depends entirely on what they are building and how they plan to release it. A team building a desktop application with quarterly releases has very different needs from a team managing a web service that deploys multiple times a day.
To get a sense of how these workflows have evolved, let's start with a high-level overview.
3 Git Workflows Every Developer Should Know (And When to Use Each)
The video '3 Git Workflows Every Developer Should Know' by TechWorld with Nana provides an excellent introduction to why different branching strategies exist and how they have evolved with the software industry.
Watch the introduction (00:00 - 03:11) and the section on their evolution (22:02 - 24:44). Focus on understanding the core idea: branching strategies changed as the industry shifted from slow, versioned releases to fast, continuous delivery (the rise of SaaS).
The key takeaway is that branching strategies are not static. They evolved to meet the demands of modern software delivery, driven by advancements in automated testing, CI/CD, and the need for greater speed.
2. The Traditional Model: GitFlow
For a long time, GitFlow was the de facto standard for managing branches. It's a highly structured model designed for projects with scheduled release cycles.
GitFlow is built around two long-lived branches:
main(ormaster): This always reflects the production-ready state.develop: This is the integration branch for ongoing development.
It also uses several types of supporting, temporary branches:
feature/*: Branched fromdevelopfor new work. Merged back intodevelop.release/*: Branched fromdevelopwhen preparing for a release. No new features are added here, only bug fixes and final tests. Once ready, it's merged into bothmainanddevelop.hotfix/*: Branched frommainto address an urgent production issue. Merged back into bothmainanddevelop.
This diagram illustrates the complexity of the flow:
Impact on Deployment Frequency
GitFlow is designed for a low deployment frequency.
- Overhead: The process of managing multiple long-lived branches, creating release branches, and merging changes back and forth is complex and time-consuming.
- Delayed Integration: Code can live in feature branches for days or weeks, leading to significant "merge hell" and delaying feedback from integration tests.
- Release Stabilization Phase: The existence of a
releasebranch implies a "code freeze" period dedicated to stabilization, which inherently slows down the release of new features.
For these reasons, GitFlow is fundamentally at odds with the goals of Continuous Integration and Continuous Delivery.
To understand why GitFlow is now considered a legacy practice for most modern applications, watch this explanation from Dave Farley, a renowned expert and co-author of the book 'Continuous Delivery'.
Watch the sections from 01:31-06:57 and 10:29-12:42. He explains how GitFlow's complexity prevents a 'shared, accurate view' of the system, which is the core principle of Continuous Integration. Pay close attention to the part where he mentions that even GitFlow's creator and major companies like Atlassian now recommend simpler workflows for CI/CD.
When to use GitFlow: It remains a valid choice for projects that require managing multiple versions of installed software in the wild, such as mobile apps, desktop applications, or enterprise software that clients install on-premise.
3. Modern Models for Continuous Delivery
For web applications, SaaS products, and microservices, the goal is rapid, continuous delivery. GitFlow's complexity is a bottleneck. This led to the rise of simpler strategies.
A. Feature Branching (and GitHub Flow)
This is a much simpler model. The core idea is:
- The
mainbranch is always stable and deployable. - To work on something new, you create a feature branch from
main. - When the work is done, you open a Pull Request (PR) to merge it back into
main. - Once the PR is reviewed and passes automated checks, it's merged.
- After merging into
main, it can be deployed to production immediately.
GitHub Flow is a specific, well-defined implementation of this feature branching strategy.
Impact on Deployment Frequency
Feature branching enables a high deployment frequency. Because main is always deployable, any merge can trigger a release. This aligns well with CI/CD principles.
Drawbacks: The main risk is that feature branches can live for too long. A branch that exists for many days or weeks diverges significantly from main, increasing the risk of complex merge conflicts and delaying integration feedback. This is the problem that Trunk-Based Development aims to solve.
B. Trunk-Based Development (TBD)
Trunk-Based Development (TBD) is considered the gold standard for high-performing DevOps teams. It takes the principle of frequent integration to its logical conclusion.
The core principle of TBD is that all developers commit to a single shared branch (the "trunk," usually main) at least once a day.
- If developers use branches at all, they are extremely short-lived (a few hours to a day) and are only used to facilitate code review via a pull request before being immediately merged.
- Some "hardcore" TBD teams commit directly to the trunk.
This sounds risky, so how does it work safely? TBD relies on two critical enablers:
- Comprehensive Automated Testing: Every commit to the trunk must trigger a fast and reliable automated test suite. A broken build on the trunk is a "stop the world" event that must be fixed immediately.
- Feature Flags (or Toggles): How do you merge incomplete features to
mainwithout breaking production? You wrap the new code in a feature flag. The code is deployed to production but is "dark" or inactive until the feature is complete and the flag is turned on.
3 Git Workflows Every Developer Should Know (And When to Use Each)
Let's return to the TechWorld with Nana video to see how Trunk-Based Development works in practice, particularly with the use of feature flags.
Watch the segment on Trunk-Based Development from 14:34 to 22:02. Focus on how it minimizes merge conflicts and enables an extremely fast feedback loop. Note the mention of DORA metrics, which show that teams using TBD have better deployment frequency and faster recovery times—a powerful point for an interview.
Impact on Deployment Frequency
Trunk-Based Development enables the highest possible deployment frequency. It is the purest form of Continuous Integration, designed to get code from a developer's machine to production as quickly and safely as possible.
4. Choosing the Right Strategy
In an interview, you won't just be asked to describe these strategies; you'll be asked to recommend one. The correct answer is always "it depends." Your ability to explain the trade-offs is what demonstrates seniority.
Here is a summary comparing the strategies:
| Strategy | Core Idea | Best For | Deployment Frequency | Key Challenge |
|---|---|---|---|---|
| GitFlow | Multiple long-lived branches for features, development, and releases. | Versioned software (e.g., mobile apps). | Low | Complexity, slow feedback, merge conflicts. |
| GitHub Flow | Short-lived feature branches merged to main via PRs. main is always deployable. |
Web apps, SaaS, teams practicing CD. | High | Requires discipline to keep branches short-lived. |
| Trunk-Based | All developers integrate into a single main branch daily. |
High-performing teams practicing CI/CD. | Very High | Requires mature testing and feature flags. |
The following article provides a fantastic decision guide and summary tables that you can use as a mental model for your interview answers.
Git Branching Strategies for DevOps / Git Branch Strategies for CI/CD
The article 'Git Branching Strategies for DevOps' on Medium and 'Git Branch Strategies for CI/CD' on MOSS.sh provide concise tables and a decision guide to help structure your thinking.
First, review the table under the 'Deployment Frequency' section in the Medium article (LINK). This directly links strategies to deployment speed.
Git Branch Strategies for CI/CD
Next, let's look at a practical decision guide.
Now, read the section 'Choosing the Right Strategy: Decision Guide' in the MOSS.sh article (LINK). These bullet points provide a perfect script for an interview answer: 'If the goal is X, I would recommend Y because...'
Test your understanding!
A financial services company is building a new real-time payment processing platform. The platform is composed of several microservices. The Head of Engineering wants the teams to be able to deploy bug fixes and small features multiple times a day to respond quickly to market needs.
Which branching strategy would you recommend, and what two critical prerequisites would you tell the engineering lead they must invest in for this strategy to succeed?
Show answer
I would recommend Trunk-Based Development (TBD).
Reasoning: The goal of deploying multiple times a day requires the highest possible deployment frequency and the tightest feedback loops. TBD is specifically designed for this by minimizing the lifetime of branches and promoting continuous integration to a single source of truth (main).
Prerequisites: For TBD to be successful and not introduce chaos, two non-negotiable prerequisites are:
- A robust, comprehensive, and fast automated test suite. Every commit to the trunk must be automatically validated to ensure it doesn't break the application.
- A mature feature flagging system. This allows developers to merge incomplete work to
mainwithout affecting users, decoupling code deployment from feature release.
Conclusion & Practice
You now have a framework for discussing one of the most fundamental topics in DevOps. You can explain the "what" and "why" of each major branching strategy and, most importantly, connect them to their impact on business goals like deployment speed.
Key Takeaways:
- GitFlow: For versioned, scheduled releases. Low deployment frequency.
- GitHub Flow: For continuous delivery. High deployment frequency, but branches can become a bottleneck.
- Trunk-Based Development: The ideal for continuous integration and the highest deployment frequency, but it demands mature technical practices like automated testing and feature flags.
- The Choice is a Trade-off: The core trade-off is between developer isolation (long-lived branches) and integration speed (short-lived branches). Modern DevOps prioritizes integration speed to reduce risk and accelerate feedback.
To solidify your knowledge, practice answering these common interview questions out loud:
- Can you compare GitFlow and Trunk-Based Development? When would you use one over the other?
- Our team is currently using GitFlow for our web application, and our release process is slow. What would you recommend we do?
- What are the risks of Trunk-Based Development, and how do you mitigate them?
- How does your choice of branching strategy impact your CI/CD pipeline design?
Next Up
We have a functional pipeline and a branching strategy to feed it. But a pipeline that moves fast must also be secure. In our next lesson, we will tackle another critical interview topic: Explain strategies for handling secrets and credentials securely in CI/CD pipelines.