yrotslluf
Joined 1 year ago
Joined 1 year ago
There are two things I suggest as workflows for people when I teach them about rebase workflows.
> Since rebase “replays” your commits onto the new base one at a time, each replay is a merge conflict opportunity. This means that as you rebase, you might have to resolve multiple conflicts one after another. ... This is why you can conclude a merge with a simple commit, but ...
For multiple conflicts on several commits being replayed, if it's _not_ useful to go through them all one at a time, I suggest that people do a squash first rebase from the fork point (which by definition can not have conflicts) to collapse their commits into a single commit first, and then rebase again from the branch.
For instance, if forked from main:
git rebase -i `git merge-base main --fork-point`
Squash all of those, and then as usual: git rebase -i main
Second, when rebasing repeatedly onto an evolving branch over time, you'll often find yourself resolving the same merge conflicts over and over again."rerere" (https://git-scm.com/book/en/v2/Git-Tools-Rerere) will allow git to "reuse recorded resolution" so that you don't have to do them manually each time.
My gitconfig for these:
[alias]
forked = "!f() { git merge-base $1 --fork-point; }; f"
squash-first = "!f() { git rebase -i `git merge-base $1 --fork-point`; }; f"
[rerere]
enabled = true
Get a personal trainer or try signing up with a CrossFit gym or another gym that has coached classes. You need form instruction, and you need to take it slow.
For me, my mental health and physical health are tied directly to each other and this was the single best thing I did for myself in my late 30s.