by xnorswap on 7/6/2023, 10:44:38 AM
If merge conflicts are that common, either you're all tripping over each other trying to do things in different ways, or they are "artificial" conflicts caused by people rebasing public shared / branches.
Merge conflicts should be occasional, not an everyday occurrence.
Atlassian's golden rule: Never rebase a public branch.
Try to understand where conflicts are coming from. Are people committing different linting/whitespace/line-endings.
If so, then get automated tooling on the repo which enforces a linting and style guide to prevent re-format conflicts.
If they're from genuine refactors, try to understand why people are refactoring so much in a way that is causing conflicts.
My current approach is:
1. Change to main
2. `git pull` latest changes
3. Change to my feature branch
4. git merge origin/main
5. Get CONFLICTS
6. Fix CONFLICTS
7. git add -A
8. git commit -m "Rebase from main"
9. Fingers crossed, git push origin myfeature
I have also tried `git rebase origin/main` at #4, but this often pulls everyone elses commits into my change, which gets me complaints during review.
At this point it will either go well, or blow up. Sometimes GitHub will claim there is still a merge conflict, even though my local file and the remove file in main are identical. Other times I have new commits locally, I push them upstream and git tells me
Is there any idiot proof approach I can take here. I am guessing this is more the tradesmen at fault, more than the tools. So willing to look a fool here, but this is a bit of a PIA right now.