Ask HN: What is your approach to dealing with merge conflicts day in / day out?

1 pointsjossclimb2y ago1 comments

I am working on a project with quite few others (OSS) and constantly hitting merge conflicts, which I then turn into a dumpster fire. Sometimes things go well, other times I just close the PR. Make a fresh branch and start again, as git and GitHub have fallen out.

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.

1 comments

xnorswap2y ago

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.

j / k navigate · click thread line to collapse