Git Branching Strategy for Large Projects: Master, Develop, Hotfix, and Release
This article explains a comprehensive Git branching strategy for large projects, detailing the roles and workflows of master, develop, hotfix, and release branches, and how they support product development, testing, and release management.
With the rapid popularization of Git in recent years, it is now used daily by both developers and testers.
For newcomers to Git, opening a repository with dozens of branches can be confusing; many wonder why so many branches exist.
Developers need to know how to manage product development and release through Git branches; for large projects, just master and develop are insufficient, requiring additional branches for better code management.
Testers benefit from understanding development processes and branch management, which aids in creating automated test cases that target specific branches and later locate corresponding tests via branches or tags.
The following diagram illustrates a Git branching management strategy for large projects that covers about 99% of product requirements.
The diagram (please enlarge) roughly divides branches into master, hotfix, release, and develop.
master – used only for storing stable version commits and only allows merge operations. After each successful release, the release branch code is merged into both master and develop, and a corresponding tag (e.g., v1.1, v1.1.01) is created on master.
develop – the primary development branch used by all developers; current bugs and features are fixed on this branch. Each bugfix or feature branch must be created, a Pull Request submitted for code review, and then merged into develop.
hotfix – hotfix branches are created after a product release; for example, after releasing v1.1, a hotfix/1.1.01 branch is created to fix issues found in v1.1. After fixing, the branch is merged into develop to ensure the fix is included in future versions. Subsequent hotfixes (e.g., hotfix/1.1.02) are based on the latest hotfix branch.
release – the release branch is created after code freeze. At this stage, testing begins on a large scale, and developers are not allowed to add new feature code to this branch; only bug fixes approved via Pull Request can be merged. Feature development continues on develop. After a successful release, the release branch is merged into master (with a tag) and also merged back into develop.
Key points to remember:
Hotfix branches are created from the latest hotfix branch.
After a hotfix branch is released, it is merged into develop.
Release branches are created from develop.
After a release branch is released, it is merged into both develop and master.
Defects found on the release branch are fixed on the release branch.
If you are among the 1% of product requirements that cannot be satisfied, feel free to leave a comment.
DevOps Engineer
DevOps engineer, Pythonista and FOSS contributor. Created cpp-linter, commit-check, etc.; contributed to PyPA.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.