alt Hacker NewsI 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:
Replies
I follow this approach and still get the same merge conflicts coming repeatedly while doing rebase.
Let's say in my feature branch in the first commit I change a line in a file which also gets changed in the main branch. Then I have done 3-4 change commits doing changes in the same file. Now while doing rebase, I will have to resolve this conflict 3–4 times again and again while git re-applies commit one by one, during rebase.
I think I get this sometimes even if rerere is enabled, I am doing rebase using Intellij though, so maybe rerere doesn't get used here somehow or maybe diff context changes, so rerere is not applicable.
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)
rerere is still useful here to handle merge conflicts after repeated rebases.
I've never even seen someone suggest a rebase master onto feature workflow! TIL.
This is what I've been doing for years. It's remarkably stress-free!
That’s a funny Stackoverflow answer. That explanation cannot cause code loss. At least not with plain Git.
What I would check is hooks, or any other customizations. Especially on Windows, data loss is absolutely possible with misconfigured hooks, but it has nothing to do with when a commit was made.