The post considers rebasing the fork. It seems easier to do only merges. You can merge specific upstream commits, or the entire upstream branch. That way you only need to merge in the changes, and not resolve the same conflicts for each downstream commit, every time the upstream is changed.
Maintaining a fork by merging upstream into downstream branches would be a mess: upstream and downstream code would be totally entangled, there would no clean way to edit/remove/reorder downstream commits. You can't easily know what you actually changed (not the full diff, but each "atomic" clean change).
The way the author suggests is way cleaner IMO.
It depends on whether the downstream only ever consumes upstream changes, or also often contributes changes to upstream. Rebasing in both directions can result in a messy history, too.
This doesn't seem to be about forking, but rather contributing upstream using a GitHub-like model.
If you're actually forked, you shouldn't be rebasing.
Nice overview. There is a lot of rebasing going on, and I wonder how that would work when more than one person works on the downstream fork. Force-pushing can easily break other users’ checkouts.
Rule of thumb is:
- never force push a branch
- at least not if someone else could be working on it
- and definitely not without talking to them about it
Personally I force push my branches quite often. It's super useful to rebase my branch on to main/master or doing an interactive rebase to reorder my commits, merge or just change the commit message.
I've been on the other end of someone rebasing and force pushing. I've found that just removing the branch from my local git and then checking it out fresh from origin is the simplest way to go.
Re: continuing a partial rebase
I haven’t tried it myself, but since you know commits A and B have already been rebased and had their conflicts resolved, can’t you instead rebase -i on top of the partial-rebase branch and then drop A and B?
I think this way at least you still benefit from the rebase --edit-todo, which you do not when cherry-picking C^..F.