Git Branching Strategies

Branching strategies play a crucial role in setting up your workflow. The choice of strategy depends on the scale and speed at which you want to deliver your product.

For small teams that prioritize speed and rapid delivery, a strategy that draws branches from the main/master branch and merges changes immediately after is effective.

In contrast, larger teams that focus on stability and steady deployments, often with multiple environments, benefit from having integrator and main branches running parallel.

This allows for the creation of multiple sub-branches based on specific requirements. Here are the key components of common branching strategies:

1. Main Branch: This is the primary codebase where all development activity is stored. It serves as the parent branch from which new features or releases are developed.

2. Integrator Branch: Used to keep the main branch hidden, the integrator branch is actively utilized to add features and releases.

3. Feature Branch: When planning to add a new service or feature, a new branch is drawn from the main or release branch. Feature branches are typically short-lived, lasting from a few weeks to a month.

4. Release Branch: This branch is created when planning to release a new version of the product. It contains all new features built since the last release and is used for CI/CD deployments into various environments. The lifespan of a release branch is generally 1-3 months.

5. Hotfix Branch: For quick fixes on broken code or to roll back changes, a hotfix branch is drawn from the release or main branch. These branches are usually short-lived, lasting 2-3 days to a week.

After successful deployment, feature, release, and hotfix branches are deleted once merged into the main branch.

In our setup, we utilize GitHub Flow and Trunk Based deployments for small teams focused on fast shipping of code and releases, making it ideal for CI/CD intensive environments.

Conversely, Gitflow and GitLab Flow are preferred for larger teams where a stable workflow is prioritized over rapid release cycles, especially in environments leading up to production. Which Git Branching Strategy do you use at work?