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:

https://icinga.com/blog/undo-git-reset-hard/

▲

acallaghan 28 minutes ago | parent | next [-]

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.

▲

lelandfe 24 minutes ago | parent | prev | next [-]

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)

▲

techwizrd 31 minutes ago | parent | prev | next [-]

This is what I've been doing for years. It's remarkably stress-free!

▲

barbazoo an hour ago | parent | prev | next [-]

rerere is still useful here to handle merge conflicts after repeated rebases.

▲

mqus 29 minutes ago | parent [-]

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?

	▲	barbazoo 13 minutes ago \| parent [-]
		I know what you mean but doesn't that require squashing as well? If I have a branch with 5 commits, I think rerere helps me by only having to fix the conflict once, not potentially multiple times. I might be wrong here though.

▲

ubercore 2 hours ago | parent | prev [-]

I've never even seen someone suggest a rebase master onto feature workflow! TIL.

	▲	dools 2 hours ago \| parent \| next [-]
		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.
	▲	barbazoo an hour ago \| parent \| prev [-]
		> 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.