We’v known this for twenty years and had the data ta back it up for ten. Github flow is one of the most damaging things to ever happen to software teams
Got asked about this twice so I’m cut/pasting my answer, but happy to discuss further
Check out the dora reports and the data Nicole Forsgren lays out in her book Accelerate. DORA reborts are free to access. She has found clear links between trunk based (no branching) development and a whole host of positive metrics. There is some suggestion that PRs are not too bad if always done at high quality and within the same day, but its weaker.
Omfg yes! Have nothing to add, but an upvote was not enough to express my hate for gitflow. So fucking stupid. And you’ll show stats from Jez Humble etc about trunk based, and my boss was still “eh not convinced”
Gitflow is far more complex and unnessaray for most places. You do not need a dev, main, and release branches. Github flow is far closer to trunk based dev - create a branch of master, PR back into master when done. If you keep your PRs small it gives you most of the benefits of trunk based dev with a CI check before you merge to the mainline.
Github flow has the same issues, in practice. Branching is the root cause, not the kind of branching. Even anonymous branches. Its the frequency of integration that matters.
what data? just curios because there are so many ways to do PRs properly… like for everything, if it’s done badly better not do it. does not mean it is inherently bad
Check out the dora reports and the data Nicole Forsgren lays out in her book Accelerate. DORA reborts are free to access. She has found clear links between trunk based (no branching) development and a whole host of positive metrics. There is some suggestion that PRs are not too bad if always done at high quality and within the same day, but its weaker.
depends on the company/team culture. are other people gonna have to fix or extend code you wrote? are you the sole engineer working on entire modules? do you hate feedback?
Mandatory pull requests + approvals within a team are a waste of everyone’s time.
deleted by creator
sounds like your company sucks. I’m sorry, must be lonely
Big hot take to me; especially in an organization with a large size and code high standard
We’v known this for twenty years and had the data ta back it up for ten. Github flow is one of the most damaging things to ever happen to software teams
Source?
Got asked about this twice so I’m cut/pasting my answer, but happy to discuss further
Check out the dora reports and the data Nicole Forsgren lays out in her book Accelerate. DORA reborts are free to access. She has found clear links between trunk based (no branching) development and a whole host of positive metrics. There is some suggestion that PRs are not too bad if always done at high quality and within the same day, but its weaker.
Omfg yes! Have nothing to add, but an upvote was not enough to express my hate for gitflow. So fucking stupid. And you’ll show stats from Jez Humble etc about trunk based, and my boss was still “eh not convinced”
gitflow != github flow
Gitflow is far more complex and unnessaray for most places. You do not need a dev, main, and release branches. Github flow is far closer to trunk based dev - create a branch of master, PR back into master when done. If you keep your PRs small it gives you most of the benefits of trunk based dev with a CI check before you merge to the mainline.
Git Flow and GitHub Flow are entirely different branching strategies.
Gitflow is has the same issues
Git Flow is awful I absolutely agree. On the other hand I like GitHub Flow.
Github flow has the same issues, in practice. Branching is the root cause, not the kind of branching. Even anonymous branches. Its the frequency of integration that matters.
what data? just curios because there are so many ways to do PRs properly… like for everything, if it’s done badly better not do it. does not mean it is inherently bad
Check out the dora reports and the data Nicole Forsgren lays out in her book Accelerate. DORA reborts are free to access. She has found clear links between trunk based (no branching) development and a whole host of positive metrics. There is some suggestion that PRs are not too bad if always done at high quality and within the same day, but its weaker.
depends on the company/team culture. are other people gonna have to fix or extend code you wrote? are you the sole engineer working on entire modules? do you hate feedback?
Depends how good you are at what you’re doing. I’d argue that humans err and it saves a bunch of time to catch bugs before debugging in the wild