An alternative approach would be to rebase the "top" of the stack, part-3 on top of dev. We could then reset each of the branches to the "correct" commit in the newly-rebased branch, something like this:

Don't think that I just naturally perfectly segment these commits when creating the feature. I heavily rebase and edit the commits before creating a PR.

If you don't learn from history, you're doomed to rebase it.

What I think we're lacking is proper tooling, or at least the knowledge of it. I don't know what most people use to write Git commits, but concepts like interactive staging, rebasing, squashing, and fixup commits are very daunting with Git on the CLI, unless you know really well what you're doing. We should do a better job at learning people how to use tools like Git Tower (to give just one example) to rewrite Git history, and to produce nice Git commits.

in order to track the always-improving upstream project, we continuously rebase our patches on top of the upstream master

We don’t use merge commits.

git rebase --committer-date-is-author-date

But in general the guideline is: code should be clean, history should be realistic.

If you push to a public branch you shouldn't rebase it since that makes it hard to follow what you're improving, what the test results were, and it breaks cherrypicking

Rule of thumb: When pulling changes from origin/develop onto your local develop use rebase. When finishing a feature branch merge the changes back to develop.