_This was originally posted here_
Gitflow Overview
Gitflow is, by far, the most popular branching model and possibly the one that has endured the test of time the most. Introduced by Vincent Driessen in 2010, its fundamental idea is that you should isolate your work into different types of git branches.
Other branching strategies, such as the centralized workflow (for those teams that come from SVN), and the forking workflow (for open-source projects) exist. Git, as a version control system, only details basic branching operations, and it remains controversial as to which approach is the best. Beyond those basic branching operations, it's a matter of opinion.
In this article we will compare Gitflow with its newer approach, GitHub Flow.
The gitflow branching model consists of merging 3 types of temporary branches to a develop branch, which should later get merged to a main branch
‍
Common criticisms of gitflow
Complexity: Having two long-lived branches and three types of temporary branches (feature, release and hotfix) increases the required effort needed to take something to production. Your team has to merge to develop and then to main. This might be a smaller problem for your team, but still, they can forget.
No rebasing concept: With the branching complexity of gitflow, you will need to track branches visually, which for the most part gets rid of the concept of rebasing. Rebasing is a complex topic but it’s still important for the conversation because
More merge conflicts: It’s simple, the number of branches that you have to merge correlates with the number of merge conflicts that you will have. In theory this isn’t something that you should worry about because git is designed to deal with this. But in practice, it will consume a significant portion of your time.
Again, this branching model was conceived in 2010 and even the author of such recognizes that it hasn’t survived the test of time. In an update Vincent Driessen recommends “a much simpler workflow (like GitHub Flow), and suggests that there is no panacea.
Gitflow and GitHub flow compared
The main points of GitHub Flow are:
Anything in the main branch is deployable.
To work on something new, create a descriptively named branch off of main.
Commit changes to this new branch.
When you need feedback or help, or you think the branch is ready for merging, open a pull request.
After someone else has reviewed and signed off on the feature, you can merge it into main.
Once it is merged and pushed to main, you can and should deploy immediately.
‍
Pretty much the same as the traditional gitflow but without the develop branch in the middle.
About pushing directly to the main branch
Purists will say that this is a bad practice, and that you should be adamant about using gitflow.
While it is true that a solid automated testing framework (or extra diligence) is required because any bug merged into main will go straight into production, we recommend GitHub flow as an approach for certain scenarios. Automated testing frameworks are very well developed today and there are lot of ways to catch bugs before they go into production.
While a tradeoff exists indeed, it’s much more what certain kinds of teams get.
- Better suited for continuous delivery
- Branch management becomes easier. Less merge conflicts to deal with.
- Encourages teams to release quickly
- Since there is less overhead, technical debt can be more easily ammortized ‍ ## It’s mainly about product maturity As a framework of thought to choose a branching model, we suggest thinking about the product’s lifecycle.
If the product is pre-Product-Market-Fit (measured by retention and expansion of use, NPS, Sean Ellis test, etc), your team needs to test as much assumptions as possible and as quickly as possible. At this stage you are testing what sticks and what not, therefore accidentally pushing a bug to production isn’t as critical. We recommend GitHub flow at this stage.
If the product is post-Product-Market-Fit, the scenario drastically changes. Your product is either mission critical for a company or something that consumers use everyday. At this stage you don’t have the luxury of pushing bugs to production. We recommend gitflow at this stage.
Regardless of your decision, still have an open mind.
Enriching pull requests with business logic
Regardless of whether you choose gitflow or GitHub flow as your branching model, code review consumes 30% of a developer’s time. A lot PRs stay stale not because of the technical complexity of the change introduced, but because of the debate that it produces around its impact on business metrics.
You can enrich your team’s gitflow or github flow process with business context. Watermelon’s GitHub Application does this by indexing the most relevant information from git, project management, messaging, and ticketing systems for a new pull request; and commenting it with such information. This will help you reduce ping-pong communication in your gitflow or GitHub flow code review process.
Top comments (0)