I am working on my personal fork of a public Git repo. I have added multiple features on separate branches in my fork (say fork/feature1 and fork/feature2), for which I have submitted separate merge requests (MRs) to the upstream repo.
Now, it takes a while for upstream to accept my MRs (it is only sporadically maintained), and I need all of these features in my application right now. My question is: How do I safely apply those changes on my fork's master (so I can use it with my application), while keeping the feature branches and still being able to update them if the upstream MR requires me to?
My basic idea would be this: Simply merge fork/feature1 and fork/feature2 into fork/master, but don't delete fork/feature1 or fork/feature2. But what if a discussion in the upstream MR requires me to change some things on fork/feature1 to get it accepted? I would then need to apply these new changes to fork/master again. In this case, can I just merge fork/feature1 into fork/master again, even though fork/master is a few commits ahead of fork/feature1, and an older version of fork/feature1 was already merged before?
I think the best strategy here is to treat each independent feature as a separate 'mini-product' that gets delivered (merged into upstream) eventually after review and acceptance testing. It's like that from upstream's pespective anyway; they don't really care about your forked master branch, right?
In this case you'll have to maintain the correct state of both your master branch AND your 'product' feature(s), in the same way you're expected to apply hotfixes to both develop and master branches by Gitflow.
And yes, you can actually go without separate hotfix branches. Instead you can 'promote' fork/feature1 first, then merge this branch once again in fork/master. Merges are not about branches, they're about commits and their hierarchy.