Git flow manages all changes through pull requests.
It provides strict access control to all changes. It’s great for open-source projects, large enterprises, companies with established products, or a team of inexperienced junior developers.
You can safely check what is being introduced into the source code. On the other hand, it might lead to extensive micromanagement, disputes involving office politics, and significantly slower development.
Trunk-based development gives programmers full autonomy and expresses more faith in them and their judgment.
Access to source code is free, so you really need to be able to trust your team. It provides excellent software development speed and reduces processes.
These factors make it perfect when creating new products or pivoting an existing application in an all-new direction. It works wonders if you work mostly with experienced developers.
what is your choice? Why?
Top comments (2)
That is a hard one! I'm using both in projects at work and I do see a lot of merit for both workflows. I'm more comfortable with gitflow as that has been my go-to in my three years of professional development. The velocity of trunk-based development is enjoyable, but I think I will have to go with gitflow just based on experience.
As I level up as a developer going forward, I wouldn't be surprised if I shift to trunk-based as my prefered style of git strategy.
Trunk-based development does not necessarily negate branches. The idea is that you can still use them for pull-requests before mergeing back into master as long as such branches are kept small in size. Definition of small, of course, changes and is contextual to the project but the goal is that the changes are so small that they get checked in as frequently as possible. Checking into master as frequently as possible, coupled with continuous deployment, ensures that in case of failures the issues are easy to address because the amount of changes since the last successful deployment is very small.
Trunk-based development is usually coupled with feature flags because you still want control over whether to enable a functionality or not, regardless of the code being already in production or not. This is especially useful while the functionality is still in development.
I personally strive for trunk-based development because it forces you to think in terms of continuous flow of work but requires discipline as well as an additional preparatory work to enable it.