Branching Strategies

← Back to Git

---

🏗️ GitFlow Branching Strategy

This is a common Git workflow (often referred to as GitFlow or a simplified variant of it) designed to provide a robust framework for managing releases and parallel development. It is primarily used for software development projects where multiple developers collaborate on features that need to be explicitly versioned and released.

Core Branches

• main: The source of truth for your production-ready code. Commits here should only come from merges from develop or release branches, and they are usually tagged with release versions.
• develop: The integration branch for features. It represents the latest delivered development changes for the next release.
• feature/*: Short-lived branches used to develop new features, branching off from develop.
• release/*: Branches used to prepare for a new production release. They branch off from develop and merge into both main and develop.

Workflow

1. Feature Development:
   • Create a new feature/* branch branching off from develop.
   • Developers write code, test locally, and commit changes to their isolated feature branch.
2. Merge to Develop:
   • Once the feature is complete, open a Pull Request (PR) against the develop branch.
   • Upon approval, the PR is merged into develop and the feature branch is deleted.
3. Release Preparation:
   • When develop has accumulated enough features for a release, a release/* branch (e.g., release/v1.0.0) is created from develop.
   • Only bug fixes, documentation generation, and other release-oriented tasks are allowed on this branch.
4. Release to Main:
   • Once the release branch is ready, it is merged into main and tagged with a version number.
   • The release branch is also merged back into develop to ensure that any bug fixes made during the release process are kept.
   • At this point, CI/CD can deploy the latest main branch to the production environment.

Flow Diagram

main       *------------------------------------------------------------------------------------> * (v1.0.0)
            \                                                                                    /
release      \                                                       *------------------------> * 
              \                                                     /                            \
develop        *-------> *----------------> *-------------> *-------> *---------------------------> *
                          \                /                 \            /
feature-login              *----> *-----> *                   \          /
                                                               \        /
feature-cart                                                    *----> *

---

🚀 Environment-Based Branching for CI/CD

Another common pattern, especially when managing infrastructure, declarative environments, or Continuous Delivery (CD) deployments, is mapping branches directly to specific environments.

The Strategy

You maintain three primary branches representing your environments: - dev: The Development environment. - qa: The Quality Assurance / Testing environment. - prod: The Production environment.

Version Configuration

Each branch contains a standard configuration file specific to its environment. Using independent files avoids merge conflicts between branches that may carry different histories side-by-side. - dev branch uses versions-dev.yaml - qa branch uses versions-qa.yaml - prod branch uses versions-prod.yaml

Example: versions-dev.yaml

app1: 1.0.0
app2: 0.0.2

The CD Pipeline Flow

1. Deploying to dev:

   • The CD pipeline triggered on the dev branch reads the versions-dev.yaml file from the dev branch.
   • It reads app1: 1.0.0 and app2: 0.0.2 and deploys these versions to the Development environment.

2. Deploying to qa:

   • For QA deployments, the pipeline uses the qa branch.
   • It reads versions-qa.yaml from the qa branch and heavily tests these versions in the QA environment.

3. Deploying to prod:

   • For Production deployments, the pipeline uses the prod branch.
   • It ensures that only carefully vetted configurations in the prod branch's versions-prod.yaml are deployed to Production.

Updating Versions via Pull Requests

Because each environment's state is strictly gated by its branch, all updates to the environment's version file must go through a Pull Request process.

1. Create an Update Branch: To deploy a new version to QA, create a temporary branch off qa (e.g., update-qa-app1-1.0.1).
2. Modify the File: Update versions-qa.yaml in this new branch to set app1: 1.0.1.
3. Open a PR: Open a Pull Request merging your update branch into the qa branch.
4. Review & Approve: The change is reviewed and approved by peers or release managers.
5. Merge: Upon merge, the target branch (qa) is updated.
6. Trigger Deployment: The CD pipeline detects the merge on the qa branch and automatically applies the new versions-qa.yaml state to the QA environment.

Flow Diagrams

Development Environment

update-dev                  * (PR: update versions-dev.yaml)
                           / \
dev       *-------------------> * (Deploys app to Dev)

QA Environment

update-qa                   * (PR: update versions-qa.yaml)
                           / \
qa        *-------------------> * (Deploys app to QA)

Production Environment

update-prod                 * (PR: update versions-prod.yaml)
                           / \
prod      *-------------------> * (Deploys app to Prod)

Best Practice

Keep Branches Isolated: The key advantage of this strategy is that dev, qa, and prod never merge into one another. You only merge configuration update branches into their respective environments. This drastically reduces merge conflicts and accidental deployments of untested code.

Infrastructure as Code (IaC)

This pattern is overwhelmingly popular for GitOps workflows (like ArgoCD or Flux) and Infrastructure as Code repositories (like Terraform or Helm charts) where the codebase primarily consists of declarative state rather than application source code.

---

🧠 Quick Quiz — Branching Strategies

#

What is the primary purpose of the develop branch in the GitFlow strategy?

It contains the stable, production-ready code

It serves as the integration branch where new features are accumulated for the next release

It is used for hotfixing bugs directly in production

It is a very short-lived branch for a single developer's work

In GitFlow, the develop branch acts as the testing/integration holding area before features are deemed stable enough to merge into main (or a release branch).

#

In an Environment-Based CI/CD strategy, how do you correctly deploy a new version to the QA environment?

By merging the dev branch directly into the qa branch

By creating a temporary update branch, updating the versions-qa.yaml file, and merging it back into qa via a PR

By updating the main branch which automatically updates all environments

By directly committing to the prod branch

You strictly maintain isolation by updating the specific environment's version file via a Pull Request to that environment's branch.

#

Why is maintaining independent version files (like versions-dev.yaml, versions-qa.yaml) beneficial in an environment-based branching strategy?

It prevents messy merge conflicts that occur when environment branches have differing histories

It reduces the amount of storage space Git requires

It allows developers to completely bypass Code Reviews

It automatically writes integration tests for you

Because each environment might be locked to different app versions at any given time, keeping independent configuration names avoids standard git merge conflicts when dealing with side-by-side branch histories.

---

📬 DevopsPilot Weekly — Learn DevOps, Cloud & Gen AI the simple way.
👉 Subscribe here