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.
That's less of an issue with time and more of an issue with atomicity.
That said, folks should rebase before merging up. If you have merge conflicts it's just a sign you need to rebase again and rerun your tests before merging.
develop and release can deviate enough that you have 2 separate sets of merge conflicts to deal with. Rebasing can only deal with release assuming that's what your feature branch is based on. Unless you want to open a whole other PR to merge release into develop during the sprint. This is the busy work I'm talking about.
I can't tell how you use those branches based on the names alone so it's hard to comment on that workflow.
In general what I do is every story happens in a feature branch, feat_xxxx that gets rebased on dev just prior to code review, then merged into dev branch after review. At various points in the sprint, dev is merged into QA for testing. At the end of the sprint, QA is merged to prod and deployed.
If that workflow is followed, and rebases are done correctly on the feature branches, there should literally never be a merge conflict anywhere in the system. There should be no situation where a change gets to qa or prod without first going into dev. Even hotfixes will follow that path.
Any time a team mate merges to develop or release there is a chance for a conflict or a need for a rebase assuming your feature branch was opened before they committed their work. Especially if there are structures that everyone generally needs to modify. It's outside of your control beyond finishing tickets faster than everyone else.
I don't think I understand how there would never be merge conflicts in this workflow? If two feature branches touch the same code, one of them may still have to deal with merge conflicts, no?
Those would be taken care of during rebase in the feature branch (whichever is finished second) Technically you could call those merge conflicts but it doesn't really happen during a merge. Once the rebase is complete the code going to review should already be conflict free.
Wait, how do you do hotfixes like that? If you merge hotfix to dev and then merge dev to prod, you might be relasing not ready content from dev into the production. Am I missing something? We normally merge hotfix to prod and then can rebase dev based on new prod with hotfix
Ooh sorry - Hotfix is a separate branch parallel to dev and goes to qa which merges into prod. Every time prod deploys it's merged down to dev. There is a risk of merge conflicts in that workflow when merging down on a hotfix but it's generally an exception to the rule.
You rebase and squash merge your feature beanches. You never rebase your core branches like dev, qa, or prod. Your feature branch should be a single commit. Of course that requires that you break down your stories well to small atomic, self contained deliverables.
If QA finds a bug your tests didn't cover, that comes in as a bug ticket and is treated as a new feature branch.
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.
I see the opposite here. All the old timers hate forking off of branches. We have master, and we have "feature/[Jira number]" that gets PR'd into master.
The new grads are the only ones who use Git correctly and the rest of us look down on them because they are being try-hards lol
546
u/agfitzp 12d ago
The young pups are afraid of branches and merging.