4 ms·

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 d

by dools 4mo 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 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/ https://icinga.com/blog/undo-git-reset-hard/

ubercore 4mo ago
I've never even seen someone suggest a rebase master onto feature workflow! TIL.
- dools 4mo ago
  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 4mo ago
  > 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.
barbazoo 4mo ago
rerere is still useful here to handle merge conflicts after repeated rebases.
- mqus 4mo ago
  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 4mo ago
    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.
  - kazinator 4mo ago
    The point is that some organizations have a chaotic development process consisting of numerous similar branches. Often there is a main trunk, and then branches that were made for particular product variants (like piece of hardware or whatever) and cut at a particular point in time, in order to isolate from the trunk. What then happens is that when a bug is found that affects all branches, it must be cherry picked into all of them. If that cherry pick runs into conflicts, it is often the same conflicts, over and over again on each branch. Of course, the fix is not to do that, but it's easier to say that than to get away from that kind of workflow once you are steeped in it up to the chin.
    - Sohcahtoa82 4mo ago
      > Often there is a main trunk, and then branches that were made for particular product variants (like piece of hardware or whatever) I worked at a place that did this. The code was written in C, and I always thought the better solution would have been to use #define/#ifdef to flag certain blocks of code out of the compilation. A branch for each product was a nightmare when there were 10+ products, some with multiple variations, each on its own branch. Backporting a bug fix meant cherry-picking into 20+ branches. What made it especially stupid was office politics from each product having its own PM, and then the PM for one of the products would decide the bug wasn't significant enough to spend the time doing the cherry-pick and testing. This happened too often when it came to security fixes when a PM didn't understand the issue.
techwizrd 4mo ago
This is what I've been doing for years. It's remarkably stress-free!
acallaghan 4mo ago
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 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.
- kazinator 4mo ago
  --force-with-lease serves no purpose. If you are sure that the repo you are pushing to is a stable target (nobody else is accessing it), you just use --force. If the repo you are pushing to is a moving target, you ... don't force push to it. Or else you warn all the repo users that you are about to rewrite history. Which means they not only should refrain from pushing, but have to be prepared for a second announcement which informs them that the rewrite is done; they must then fetch the rewritten head and fix up their unpublished work against the non-fast-forward change. Now it may be that --force-with-lease allows you to sneak in non-fast-forward changes without losing newly introduced upstream changes: but that assumes it's a good idea to be doing that sort of thing without communicating with your team. I.e. as long as we can sneak in a non-fast-forward change without accidentally/unknowingly deleting anyone's work, we are peachy; no need to coordinate.
  - twodave 4mo ago
    I wouldn’t say it serves no purpose. It is useful when rewrites are tolerable and loss of history is not. It’s the default when using tools like jj, because the expected workflow wraps git in a way that force pushes are frequent and expected, but blowing away someone else’s work by mistake is not.
  - nlawalker 4mo ago
    >If you are sure --force-with-lease exists for the scenario where you are sure, but wrong.
lelandfe 4mo ago
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)
- dolni 4mo ago
  Squash merging PRs makes your commit log is far less useful. The PR reviewer isn't the only person who will ever review your code, you know.
  - lelandfe 4mo ago
    I felt similarly. But I'm also usually the only person Tim Pope'ing my commits. If you police atomic feature branch PRs instead of atomic feature branch commits, though, things actually work out OK. (By the way, the even more compelling next step to your argument is: pull requests aren't artifacts! I've worked on projects that have emigrated from GitHub, and was left with just the commit log)
overtomanu 4mo ago
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.
- alexsmirnov 4mo ago
  We usually squash feature branches before merge. To squash before rebase, I use git reset --soft $(git merge-base develop HEAD) && git commit && git rebase develop - you have to resolve final conflicts only
ruszki 4mo ago
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.

by dools 4mo ago

ubercore 4mo ago

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

dools 4mo ago
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 4mo ago
> 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.

barbazoo 4mo ago

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

mqus 4mo ago
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 4mo ago
  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.
- kazinator 4mo ago
  The point is that some organizations have a chaotic development process consisting of numerous similar branches. Often there is a main trunk, and then branches that were made for particular product variants (like piece of hardware or whatever) and cut at a particular point in time, in order to isolate from the trunk. What then happens is that when a bug is found that affects all branches, it must be cherry picked into all of them. If that cherry pick runs into conflicts, it is often the same conflicts, over and over again on each branch. Of course, the fix is not to do that, but it's easier to say that than to get away from that kind of workflow once you are steeped in it up to the chin.
  - Sohcahtoa82 4mo ago
    > Often there is a main trunk, and then branches that were made for particular product variants (like piece of hardware or whatever) I worked at a place that did this. The code was written in C, and I always thought the better solution would have been to use #define/#ifdef to flag certain blocks of code out of the compilation. A branch for each product was a nightmare when there were 10+ products, some with multiple variations, each on its own branch. Backporting a bug fix meant cherry-picking into 20+ branches. What made it especially stupid was office politics from each product having its own PM, and then the PM for one of the products would decide the bug wasn't significant enough to spend the time doing the cherry-pick and testing. This happened too often when it came to security fixes when a PM didn't understand the issue.

techwizrd 4mo ago

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

acallaghan 4mo ago

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 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.

kazinator 4mo ago
--force-with-lease serves no purpose. If you are sure that the repo you are pushing to is a stable target (nobody else is accessing it), you just use --force. If the repo you are pushing to is a moving target, you ... don't force push to it. Or else you warn all the repo users that you are about to rewrite history. Which means they not only should refrain from pushing, but have to be prepared for a second announcement which informs them that the rewrite is done; they must then fetch the rewritten head and fix up their unpublished work against the non-fast-forward change. Now it may be that --force-with-lease allows you to sneak in non-fast-forward changes without losing newly introduced upstream changes: but that assumes it's a good idea to be doing that sort of thing without communicating with your team. I.e. as long as we can sneak in a non-fast-forward change without accidentally/unknowingly deleting anyone's work, we are peachy; no need to coordinate.
- twodave 4mo ago
  I wouldn’t say it serves no purpose. It is useful when rewrites are tolerable and loss of history is not. It’s the default when using tools like jj, because the expected workflow wraps git in a way that force pushes are frequent and expected, but blowing away someone else’s work by mistake is not.
- nlawalker 4mo ago
  >If you are sure --force-with-lease exists for the scenario where you are sure, but wrong.

lelandfe 4mo ago

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)

dolni 4mo ago
Squash merging PRs makes your commit log is far less useful. The PR reviewer isn't the only person who will ever review your code, you know.
- lelandfe 4mo ago
  I felt similarly. But I'm also usually the only person Tim Pope'ing my commits. If you police atomic feature branch PRs instead of atomic feature branch commits, though, things actually work out OK. (By the way, the even more compelling next step to your argument is: pull requests aren't artifacts! I've worked on projects that have emigrated from GitHub, and was left with just the commit log)

overtomanu 4mo ago

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.

alexsmirnov 4mo ago
We usually squash feature branches before merge. To squash before rebase, I use git reset --soft $(git merge-base develop HEAD) && git commit && git rebase develop - you have to resolve final conflicts only

ruszki 4mo ago

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.