3 ms·
Everything Git is kind of hard to understand, but once it "clicks", you kinda start thinking it was easy all along. My suggestion is: before every rebase: - m
by dyingkneepad 4y ago
Everything Git is kind of hard to understand, but once it "clicks", you kinda start thinking it was easy all along.
My suggestion is: before every rebase:
- mkdir patches
- cd patches
- git format-patch HEAD~30 (in case you had 30 commits on top of the main branch but you can also "git format-patch $SHA" to get patches up to that SHA, not including)
- git pull --rebase
Then, if the rebase fails:
- git checkout -b branchname-rebaseattempt origin/branch
- make
- git am 0001*
- make
- git am 0002*
- git am --abort
- etc
This way you have a backup copy of every one of your commits as a patch file, and you can better understand and fix your conflict step-by-step without being "locked" in the process of a git-rebase. Sometimes when there are simple conflicts I edit the patch files themselves before applying.
- solardev 4y agoWhat's the advantage of this instead of just merging?
- seba_dos1 4y agoThere's no advantage for doing this at all. It's just duplicating the work git does for you already, but outside of git. I'd rather recommend spending some time with git to get familiar with your tooling, instead of working around your lack of familiarity this way. And when it comes to "what's an advantage of rebasing over merging" - those are two completely distinct operations that make you end up with different results, so there's no simple answer to that question (it's like "what's an advantage of bold font over italics?"). Sometimes you want to merge, sometimes you want to rebase. Once you can visualize your repository in your head, it becomes rather obvious when to use which one.