Comment by the_gipsy
2 months ago
I usually just `git rebase origin/main -i` after the base branch has been merged there, and this means I need to explicitly drop the merged commits, but I can inspect what's happening.
2 months ago
I usually just `git rebase origin/main -i` after the base branch has been merged there, and this means I need to explicitly drop the merged commits, but I can inspect what's happening.
Yeah, I do this too: The `--onto` solution feels a bit too magical at times and an interactive rebase is pretty clear about what's happening.
Add `--update-refs` to your interactive rebase and it will give you an easy line to know how many commits to drop because it will add an `update-ref` line for the old branch. You can just easily delete everything up to and including that `update-ref` line and don't have to manually pull up a git log of the other branch to remember which commits already merged.
(Plus, of course, if you have multiple branches stacked, `--update-refs` makes it easier to update all of them if you start from the outermost branch.)
Nice; thanks :) I usually squash-merge. Does that break this workflow?
1 reply →