#~/.config/git/config
[rerere]
enabled = true
autoUpdate = true
[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 = mainthese are changes tacked to my git config over time. they're the result of working in a constant crunch state, where smooth forward move was more import than the state of the git history you left behind. these options remove small annoying road bumps. you should avoid some of them if you're working under different constraints, or the commit process differs such that these options don't apply.
it all starts with `pull.rebase=true` it makes `git pull --rebase` the default behavior. then comes `rebase.autoStash`, which just wraps the rebase with a stash push/pop envelop. if rebase is not your thing, and you prefer merge, `merge.autoStash=true` works the same. finally `push.autoSetupRemote=true` will skip asking you to set a remote tracking branch, it makes `git push` default to `git push --set-upstream`.
[pull]
rebase = true
The man page for "git pull" even has a warning about using this flag.
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.
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.
Sometimes we will have a huge stack of changes one of us is "finished but not clear to merge".
either:
- We just swap ownership of the branches and eng 2 now commits directly in branch 1. We review the final content together and typically pull in a 3rd person to review our combined work. Eng 1 either pairs with eng 2 until its finished or starts on a task that is decoupled from those changes.
- We use an integration branch that gets threated like the temporary master branch until the feature is ready to merge.
this kind of interaction shows up more in a 'release' based model than CI environment, and one where the cost of testing is non-zero (because we're actually doing testing). I know that's not a very popular model, but not all software development is CI websites.
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/
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.
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.