#~/.config/git/config [rerere] enabled = true autoUpdate = true while you're editing git config, consider these: [pull] rebase = true [rebase] autoSquash = true autoStash = true [merge] # zdiff3 adds original text markers and removes matching lines from conflict regions # https://git-scm.com/docs/git-config#Documentation/git-config.txt-mergeconflictStyle conflictStyle = zdiff3 autoStash = true [push] autoSetupRemote = true default = simple [init] defaultBranch = main
cautiouscat
Every time I think I am adept in git, something like this is shown to me. I really should read into it more lol.
davidelettieri
I'm using these options https://blog.gitbutler.com/how-git-core-devs-configure-git and I'm happy with it
dools
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/
adithyassekhar
Do people really merge left and right between branches? Tell me if I got this wrong, this is how I work. You got 4 devs. Each branched off from master. And we never merge from each other. Suppose 3 other people merged to master I pull it from master and fix only those conflicts. I’m not bringing your code into my branch unless it’s already finished and on master. If I need something you’re working on and it’s not on master when I need it, it’s a much larger planning issue. If you have multiple environments before a stable master, do it only in one direction: feature > dev > staging > master. Don’t merge branches straight into staging or master. I thought this was how everyone worked.
mamcx
I use rerere when "forced" by team to use rebase. It not even work that much at the end (you can't control workflows outside yourself, that is why git ux is wrong: it desperately need total discipline). THEN, I move to jujutsu. Only has a few problems at start trying to use it as git, but after get the idea, all fine. BTW, this was with the same team and they never know, so JJ is in fact better: It survive OTHERS workflows.
barchar
You can use the rerere-train script in the git repo to populate rerere from existing merges. I use this when something in a merge has regressed a big feature branch and I need to bisect. I can train rerere then rebase on the 2nd to latest merge-base, all while still doing no extra work if there isn't a regression.
Discussion Highlights (7 comments)
0123456789ABCDE
#~/.config/git/config [rerere] enabled = true autoUpdate = true while you're editing git config, consider these: [pull] rebase = true [rebase] autoSquash = true autoStash = true [merge] # zdiff3 adds original text markers and removes matching lines from conflict regions # https://git-scm.com/docs/git-config#Documentation/git-config.txt-mergeconflictStyle conflictStyle = zdiff3 autoStash = true [push] autoSetupRemote = true default = simple [init] defaultBranch = main
cautiouscat
Every time I think I am adept in git, something like this is shown to me. I really should read into it more lol.
davidelettieri
I'm using these options https://blog.gitbutler.com/how-git-core-devs-configure-git and I'm happy with it
dools
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/
adithyassekhar
Do people really merge left and right between branches? Tell me if I got this wrong, this is how I work. You got 4 devs. Each branched off from master. And we never merge from each other. Suppose 3 other people merged to master I pull it from master and fix only those conflicts. I’m not bringing your code into my branch unless it’s already finished and on master. If I need something you’re working on and it’s not on master when I need it, it’s a much larger planning issue. If you have multiple environments before a stable master, do it only in one direction: feature > dev > staging > master. Don’t merge branches straight into staging or master. I thought this was how everyone worked.
mamcx
I use rerere when "forced" by team to use rebase. It not even work that much at the end (you can't control workflows outside yourself, that is why git ux is wrong: it desperately need total discipline). THEN, I move to jujutsu. Only has a few problems at start trying to use it as git, but after get the idea, all fine. BTW, this was with the same team and they never know, so JJ is in fact better: It survive OTHERS workflows.
barchar
You can use the rerere-train script in the git repo to populate rerere from existing merges. I use this when something in a merge has regressed a big feature branch and I need to bisect. I can train rerere then rebase on the 2nd to latest merge-base, all while still doing no extra work if there isn't a regression.