A “branching strategy” refers to the strategy that a software development team employs when writing, merging and shipping code in the context of a version control system like Git. Teams adopt a branching strategy because it enable parallel development and keeps the main codebase stable.
With branching, each code author works locally in a separate branch focused on a specific task. Branches are published and merged following peer code review. There are two main types of branches; persistent and ephemeral.
With branching, each code author works locally in a separate branch focused on a specific task. Branches are published and merged following peer code review. There are two main types of branches; persistent and ephemeral.
- Persistent branches are long-lived, holding stable, shared code that reflect the state of the project at key stages.
- Ephemeral branches are short-lived and focus on specific development tasks. Engineers create them from a persistent branch and delete them after merging.
Example
An example branching strategy is GitFlow which supports structured, multi-stage software development using a pre-defined set of persistent and ephemeral branches.
There are three persistent branches.
- The main branch contains production-ready code. Teams tag it for releases (e.g., v2.0.1) and often configure CD pipelines to deploy it automatically.
- The develop branch acts as an integration branch. Developers merge completed feature branches into develop for staging and testing.
- A release/* branch stages code for production release. Teams fork a release/* branch from develop to stabilize a version before release. Only bug fixes, documentation updates, and final QA changes are allowed in a release branch.
There are also ephemeral branches.
- A feature/* branch isolates work for a new feature, enhancement, or experiment. A developer branches a feature/* branch from develop, works on it independently, and merges changes back after review and testing. They then delete the branch.
- A hotfix/* branch is an emergency fix to main to address critical issues in production. Developers create such a branch main, fix the issues, and merge the changes into both main (to deploy) and into develop (to sync), and deploy immediately. They delete the branch after merging.
Gitflow Workflow
- Create a feature/* branch from develop.
- Work on the feature.
- Merge feature branch into develop.
- When ready to release, create a release/* branch from develop.
- Finalize the release in the release/* branch.
- Merge the release into both main and develop.
- Tag the release on main for versioning.
Testers should seek to understand the branching strategy adopted in their teams, to understand changes in the test environment and how code is shipped to end users.
