Comment by dools
2 hours ago
I never get conflicts during a merge because I only ever merge in one direction. I get all my conflicts on branches because I rebase before merging. I started doing this years and years ago because I kept coming across these mysterious silent regressions with my team. I searched something like "git merge silent regressions" and came across this stackoverflow answer:
https://stackoverflow.com/a/28510260
That completely fixed the problem. Now I only ever get conflicts on my feature branches. The rule is always: rebase away from main, and merge towards main. All conflicts are then on your branches, never on main, and always from rebase, never from merge. Then I set the pull behaviour to rebase, too.
I've never had a silent regression since, and never had a problematic conflict scenario.
I did recently learn about ORIG_HEAD though which was very cool, because I had accidentally rebased to main instead of to a dev branch from which I had created a bunch of worktrees, then when I merged back to the dev branch all hell broke loose, and I learned that I could revert a merge by checking out ORIG_HEAD:
I'm also like this, rebasing feature branches onto main - I however have one suggestion when it comes to the push back up to origin
Instead of
`git push --force`
always use
`git push --force-with-lease`
https://git-scm.com/docs/git-push
This probably should be the default in git (as in there should be a `git push --force-without-lease` instead) and asks git to make sure the commits locally on your branch are up-to-date with those on remote/origin. It then fails if you try to overwrite commits that you haven't seen, and has saved me a few times when working between computers on the same project when i could have lost history on the remote that i failed to fetch.
If you squash merge PRs, this is equivalent to merging master back into your feature branch before merging to master.
I do that a lot to avoid commits mutating mid-review, so you avoid having to force push over reviewed commits (which is a sin)
This is what I've been doing for years. It's remarkably stress-free!
rerere is still useful here to handle merge conflicts after repeated rebases.
As someone who tried rerere and didn't see the point:
How? Usually I rebase the same branch multiple times onto different, but successive commits of the master branch. But after I solved a bunch of conflicts of the first rebase, I shouldn't have the same conflicts again in a second one, since the rebased branch contains the merged conflict. Rebasing again could only turn up new conflicts (with newer, other commits on the master branch).
How can I have the same conflict again for repeated rebases?
I've never even seen someone suggest a rebase master onto feature workflow! TIL.
I think the terminology would be the other way around, like you're rebasing the feature onto the main:
git checkout feature
git rebase main
git checkout main
git merge feature
that way you get all your conflicts on the feature branch during rebase and your merge is always clean.
> I get all my conflicts on branches because I rebase before merging
Pretty sure it's the other way around. You're on the branch and rebase it atop current master. If you merge after that, you won't have merge conflicts.