Trunk based with forking workflow vs Gitflow workflow

Trunk based with forking workflow is based on public repository having a single (master) branch that will be used for CI/CD and developers will only have read-only permission. The merge strategy will ideally be fast forward rebase. Any developers who want to contribute will fork and work on their private repository. When they are ready to make a pull request, they will need to make meaningful commit, eg, squashing the commits.

Advantages of trunk based

• History is linear
• History is cleaner
• History does not contain work in progress code
• The intention of a single commit is much clearer

Disadvantages of trunk based

• Feature flags need to be introduced for parallel releases
• Learning curve for those who are unfamiliar for this strategy

Advantages of Gitflow workflow

• No separate repository
• Most are quite familiar with this workflow

Disadvantages of Gitflow workflow

• History easily becomes messier with handful of contributors
• Tracking of any changes becomes much harder with parallel history