Gitflow is great for when you need centralized control of mainline branch, which is "gatekeeped" (either by specific individuals or by a particular process - eg, 2 approvals required). This is great for open source projects.
In fast-moving autonomous teams, you want to remove as many bottlenecks and barriers to getting code into staging and production (assuming your team has skilled, competent and high-ownership individuals). Hence a better alternative in these situations is trunk-based development.
Tech enthusiast studying ICT and graduating soon enough👨🏿🎓. Software Engineer in the making, experimenting my way through life. I'm here to connect, learn from y'all and share my knowledge.👊🏿
There's only one branch that you commit to. There's no notion of a develop, staging and master branch.
I've had experiences using gitflow with teams of 10+ engineers where there are enormous merge conflicts due to inconsistencies between those develop, staging and master branches - the most obvious being when a patch lands in master but the developer forgets to add that patch back into staging and develop. Gitflow is too complicated to do correctly with so many people.
With trunk-based development you also let your developers merge to mainline when they're ready. There's no code review required (pair programming is a better alternative IMO) but a dev can certainly request a review if they need it. This leads to low friction to getting code into production. And leads to a design that allows for multiple production deployments per day with little effort on any particular person.
Tech enthusiast studying ICT and graduating soon enough👨🏿🎓. Software Engineer in the making, experimenting my way through life. I'm here to connect, learn from y'all and share my knowledge.👊🏿
I've had experiences using gitflow with teams of 10+ engineers where there are enormous merge conflicts due to inconsistencies between those develop, staging and master branches
I've seen these conflicts before too. As a junior I thought it was just human error and it's not something that would hinder the development in the long run. Guess I was wrong.
Trunk-based sound great for big teams, I'll have to look into it and see if and how I can propose it to the team when I'm more familiar with it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Gitflow is great for when you need centralized control of mainline branch, which is "gatekeeped" (either by specific individuals or by a particular process - eg, 2 approvals required). This is great for open source projects.
In fast-moving autonomous teams, you want to remove as many bottlenecks and barriers to getting code into staging and production (assuming your team has skilled, competent and high-ownership individuals). Hence a better alternative in these situations is trunk-based development.
Thanks for your contribution to this post!
What does trunk-based development do differently from git-flow that makes it a better alternative?
There's only one branch that you commit to. There's no notion of a
develop,stagingandmasterbranch.I've had experiences using gitflow with teams of 10+ engineers where there are enormous merge conflicts due to inconsistencies between those
develop,stagingandmasterbranches - the most obvious being when a patch lands inmasterbut the developer forgets to add that patch back intostaginganddevelop. Gitflow is too complicated to do correctly with so many people.With trunk-based development you also let your developers merge to mainline when they're ready. There's no code review required (pair programming is a better alternative IMO) but a dev can certainly request a review if they need it. This leads to low friction to getting code into production. And leads to a design that allows for multiple production deployments per day with little effort on any particular person.
Thanks for the elaboration!
I've seen these conflicts before too. As a junior I thought it was just human error and it's not something that would hinder the development in the long run. Guess I was wrong.
Trunk-based sound great for big teams, I'll have to look into it and see if and how I can propose it to the team when I'm more familiar with it.