In this post, we will go over Git Branching Strategy and Git Workflows, it will not focus on comparing Git Branching Models, nor explain one by one since that story has been told more than once, but you will be able to find the links and examples in this post.
If you're looking for a Git Tutorial, I recommend my previous post on it, Git Explained by DEV Community.
Introduction
Git has become the de-facto standard for source control management. Branching is an essential feature of a VCS (version control system), that allows developers to diverge from the main branch and continue their work on multiple feature branches in parallel, without affecting the main branch.
Git does NOT enforce any particular branching strategy.
Git allows teams to tweak Git Workflows, as it fits the team’s culture. As a result, teams and organizations are often required to choose a particular branching strategy that matches their release cadence, while optimizing productivity depending on their team size, strengths and weaknesses.
Some Git Branching Models are the best in certain situations, but none can be considered the "best", therefore, it is important to mention that there is no such thing as "Best Git Branching Model" or "Best Git Workflow" or "Best Gitflow" or any of its variations, but what you may find is "A successful Git branching model for X situation" which is true as Git Workflows are flexible and change as needed, so in certain situations, one Git Workflow is better than others, simple as that.
There is no such thing as "Best Git Branching Model".
Git Workflows
A Git Workflow is a recipe or recommendation for how to use Git to accomplish work in a consistent and productive manner, and deal with the branching problem.
Gitflow is not Git Workflow
In some cases, the term Gitfow is used to refer to the actual Git Workflow used by a team or organization, but this is incorrect. A Git Workflow could be any of the Git Branching Strategies that the team or organization is using and a Gitflow is a type of Git Workflow.
Git Branching Models
Here a list of some well-defined models:
Git Commonflow
Gitflow
GitLab Flow
GitHub Flow
Trunk Based Development
This post performs a comparative analysis of the three most popular branching strategies, namely, Git Flow, Trunk Based Development and GitHub Flow.
Custom Git Branching Models
There are also several custom Git Branching Models; In some cases, teams take a well-defined git workflow and modify it based on the needs of the project. Therefore, it is very common to find mutations of the git branching models mentioned above.
Example: Git Environment Branching Flow
This strategy focuses on branches per environment (development, staging and production), where each branch is restricted by rules.
Initially, three branches are required: staging, develop and master (or main).
| Branch | Environment |
|---|---|
| develop | Development |
| staging | Staging |
| master | Production |
Conclusion
There is No Silver Bullet for Git Branching, each strategy has a list of pros and cons. Choosing the "best" requires researching the well-defined models and the needs of the project, and checking if the model covers all you need or maybe a custom model based on a well-defined one.
Also, it is okay to make mistakes when selecting the correct model, if that happens remember you can always modify the current strategy or move to another one, Git allows that.
Let me know what you think in the comment section, please comment with your suggestions and feedback. If you like this article, don't forget to leave a ❤️ and share it within your network, and if you want to share your own recommended Git Workflow, please do so!
Top comments (0)