One of the common dilemma when it comes to manage branches is whether to use git flow or trunk based development.
How git flow works?
When we do a ‘git flow init’
- main and develop branches are automatically created.
- main is generally used for tracking releases.
- develop will be the branch where we work.
- We can start a feature branch in git flow using command: git flow feature start feature_branch, this will create a feature branch named ‘feature/feature_branch’.
- Feature branches use develop branch as their parent branch.
- We can finish a feature branch by the command: git flow feature finish feature_branch, this will merge back the feature branch with develop branch.
- Once a certain stack of features have been developed, it is time to create a release.
- We can create a release branch by command: git flow release start 0.1.0, this will create a release branch named ‘release/0.1.0’.
- Release branches also use develop branch as their parent branch.
- Once release is ready to ship, it should be merged to main as well as develop branch, this command takes care of it: git flow release finish 0.1.0.
- We might encounter some bugs/issues after release, we might need an immediate release, in that case we can opt for hot fix branches.
- This are the only branches that uses main branch as their parent branch.
- We can create hot fix branches using command: git flow hotfix start hotfix_branch, this will create a hot fix branch named: hotfix/hotfix_branch.
- Hotfix branches needs to be merged to main as well as develop. This command takes care of that: git flow hotfix finish hotfix_branch.
- CI/CD pipelines are configured on top of main branch or develop branch or both.
Git flow disadvantages:
- Numerous, longer-lived branches and larger commits which creates a lot of deviation from the actual branches.
- More collaboration will be required while merging. This will be difficult to achieve over time.
Git flow inclinations:
- The ‘git-flow’ command set provides ease of use in managing branches.
- The branching strategies makes a lot of sense and keeps everything segregated.
Trunk based development
- Developers make small and frequent updates on the same branch.
- This makes all the developers be aware of all the changes happening. Kinda ensures continuous code review.
- In this cases the main branch should be configured with smoke tests, contract tests, test coverage/quality (using sonarqube). This ensure the trunk branch healthy.
- Also the code is always production ready. Enables consecutive production code releases.
Best practices with trunk based development:
- Make smaller commits.
- Opt for check-in-dance (git pull — rebase -> merge conflicts -> run tests locally -> git push).
- Wrap new codes under feature flags (that are not to be picked up in the upcoming release)
- Comprehensive automated integration tests is required
- Build fast and execute immediately
- Reduced code freezes
My personal take is why not make best of both worlds. Git flow commands provides great flexibility in terms of managing branches. Opt for main branch, develop branch, short lived PRs, release branch and hotfix branch. Instead of creating feature branches, we can do trunk based on develop branch itself as well as we can opt for short lived PRs to be auditing compliant.