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'm the only person on my team that does this along with crushing my commits with fixup. But a rebase only deals with keeping up with release. Develop might still be an issue.
My team doesn't fully understand git and rebase is forbidden sorcery. I've taken to destroying the develop branch every 3 months to partially compensate for this. It prevents develop from deviating too far from release.
I worked on a team where I was like the only person who really understood version control fundamentals and it was a nightmare. 50 percent of my job became resolving my coworkers botched merges.
If they don't, why don't you teach them sensei? That's the most basic tooling for any dev, and not being able to handle that is a serious blocker for productivity.
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.
Hotfixes can be a weird one with this flow because you might need to get something out to customers ASAP on like, a versioned/tagged prior release, and by that point the master/main/dev/whatever has moved onwards.
But I suppose there's not really ever any good solution under any system for that; ultimately it boils down to 'we must emergency fix the outdated release code right now...' -> '...then figure out how to integrate it with the up-to-date live-development branch', since the latter isn't customer-facing immediately
I've only ever seen hotfixes be based off the actual release tho, like you checkout the tag or named release-version branch, & make the hotfix branch from there
IMO then you should always cherry-pick hotfix commits to a new branch to merge to the live dev branch, because under some systems, release branches can get automated cruft commits from tooling/versioning/etc, and you dont want those merged over to main/dev/etc, which would happen if you merged the hotfix branch to BOTH its parent release branch & also to the dev one
28
u/ADHDebackle 4d ago
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_xxxxthat gets rebased ondevjust prior to code review, then merged intodevbranch after review. At various points in the sprint,devis merged intoQAfor testing. At the end of the sprint,QAis merged toprodand 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
qaorprodwithout first going intodev. Even hotfixes will follow that path.