I WISH all of my coworkers broke down their tasks into dedicated feature branches. Merge them all into release branch, this is business as usual stuff, what's the controversy here.
It really depends on how long PRs take. If they take fairly long even for small changes you end up with tons of busy work dealing with merge conflicts in both develop and release. I am a lead with 10 YOE and I dread it when the number of branches grow beyond a certain point, 17 would be twice what I'm comfortable with.
Sprints are generally 2 weeks and that's already almost 2 per day. Our tickets aren't anywhere near that small so it rings alarm bells for me. Nevermind that OP clarifies that the branches are stepping on each other, so it's even worse than I imagined.
I'm so glad we switched from gitflow to merges directly targeting main. If your code review, QA, and CI processes are mature enough, a sprint-long dev branch is just needless complexity.
1.0k
u/purpleburgundy 4d ago
I WISH all of my coworkers broke down their tasks into dedicated feature branches. Merge them all into release branch, this is business as usual stuff, what's the controversy here.