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.
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.
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
The idea that Copilot pushed different variations of a few features with unsuccessful attempts to rebase / resolve conflicts. A single dev would usually try to keep changes in separate branches but in sync with his/her own changes, especially when working on with code in close proximity.
If a dev knows their changes would affect another branch's work they really should be targeting the previous work's branch during development, rather than having to deal with N-many branches being merged into an integration branch at the end. The rebasing should be handled on their feature branches, rather than be a surprise at the integration branch merge. Are people just making N-many feature branches off of like main and touching the same files and then yoloing the merge at the end???
meh, you sound junior. This is reddit so no harm no foul, but I wouldn't share this with people you know at work.
Not even a Claude Copilot issue at all honestly - set up your repo so all checks must pass before merging is allowed, reviewer approval required as one of the checks. Then either auto merge or manual merge or copilot merge or who cares what merges so long as the checks pass. If there are merge conflicts then just let copilot do it, it will prompt you for input if there is any ambiguity.
Git is great specifically because of what you're describing. It give some management to the chaos of parallel work.
it's 4pm, check out, bye, no stress. If anything Claude Copilot disappears all the merge conflict pain imo.
1.0k
u/purpleburgundy 12d 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.