Post History

How should open source forks, with a mix of upstreamable and non-upstreamable commits, be maintained?

I have a few different projects that rely on open source technology that I wish to make modifications to (say, to add key features for business or personal use) that will vary between upstreamable (the upstream fork would be interested in the feature) and non-upstreamable (the upstream repository has vocally been against the idea, but I still need it or want it for my own projects.)

Ideally, I would like to be able to keep my branch up to date with the latest changes. Currently, I maintain a branch (named akin to `personal/version_num`) which I rebase against upstream's `version_num` tag. This works fine, but it suffers some issues and becomes a bit of a maintenance burden. Specifically, it's hard to account for merge requests that have already been "factored in" to upstream on rebase. Additionally, every version update feels like a partial history rewrite (as rebasing causes all of our internal commits to come to the top of the log, while all upstream commits are below even if they were authored "after" the commits above.)

What is the ideal way to have this process mostly automated (where conflict-free rebasing is possible)? If you are familiar with other companies that have to maintain branches in a similar manner, do you have any advice for ways to organize forks that might have commits that are both upstream candidates and also non-upstreamable (but still open source)?