Git Branching, Picking a Git Flow
Branching
Managing your branching and versioning effectively for your project development is a key aspect to success when working with Git. Most git projects depend and follow a Branching Model that defines the rules and expectations from developers to manage their branches. The Branching Model helps provide a common practice that everyone can openly know and be able to work with.
Picking a Branching Model
Picking the right branching model for your project can be difficult because there are a lot of models out there and they all advocate they are the best. When picking a model look at your project first. Define some requirements that you need your model to meet based on your release cycles to all the different environments you support and what kind of project it is. An API or Web Service might need a different model than a Web App.
ESDC Projects Requirements
We have extracted a few requirements from our typical ESDC release process.
- Can manage a long term production equivalent branch separated from the day-to-day development.
Why? Our production release are sometimes 6 months or more apart.
- Can manage a semi-long term staging branch separated from the day-to-day development and production code.
Why? We have Testing and QA cycles that last about 2 months.
- Can handle emergency releases in a way that doesn’t alter from the regular branching.
Why? ERs can be high stress situations, we don’t want to change the “regular” method for moving code from branch to branch.
Popular Flows Comparison
| Key Features | GitFlow | OneFlow | Microsoft Release Flow | GitHub Flow | GitLab Flow |
|---|---|---|---|---|---|
| Production and Development branches segregated * |  |
 (Optional) |
|
 |
|
| Manages Staging/Release branches * | |
|
|
|
|
| ER branching similar to “regular” * | |
|
|
|
|
| Easy to follow history ** | |
|
|
|
|
| Easy to learn when new to Git ** | |
|
|
|
|
| Maintains all main branches (reduced chances of code loss) | |
|
|
|
|
| Designed for Continuous Deployment | |
|
|
|
|
| Designed for Continuous Delivery | |
|
|
|
|
| Can handle Continuous Delivery | |
|
|
|
|
| Can handle Continuous Integration | |
|
|
|
|
| Deploys to Production from “Main/Master/Default” branch | |
|
|
|
|
Legend:
*from ESDC Projects Requirements;**Subjective analysis.
Our Recommendation
Use GitFlow branching model. It is great for managing releases and parallel development in large applications.
This model has two primary branches, master & dev, that always exist.
All other branches only exist as long as they are active (until merged into a primary or secondary branch).
The secondary branches include release, feature and hotfix.
Both the primary and secondary branches should be protected to only accept changes via a pull or merge request.
The last branch is a working branch.
This branch is the only place you should be committing code against.
GitFlow can be fairly simplistic but also get very complex. We recommend you try to keep it as simple as possible, but don’t shy away from getting complex if that is what the project requires.