Git workflow, rebase in cascade with 2 features branches

I am trying to find a good git workflow for a specific situation.

General case works fine: I have a master branch, from which I create a feature branch. I regularly rebase feature onto master, and once feature is ready, I do a pull request on master.

            master
            v
*---*---*---*
         \
          *--*
             ^
             feature

Now sometimes, several developpers are needed for a big feature. We still create a feature branch from master, and then feature1 and feature2 from feature. The workflow between feature1, feature2 and feature is the same as the one you would have with feature and master in the general case (sorry, my git drawing might be a bit ugly, not used to doing that).

            master      feature2
            v           v
*---*---*---*       *---*
         \         /
          *---*---*
              ^    \
        feature     *---*
                    ^
                    feature1             

In an ideal world, once feature1 and feature2 are done, we would PR/merge them into feature, and then rebase feature onto master, and finally merge/do a PR of feature onto master.

But it might happen that we need to rebase feature onto master before that, to get some new changes or simply to not have to get too many changes at once. We might have conflicts that we fix (caused by an hypothetical feature3, or maybe because we already did a merge from feature1 onto feature even thought feature1 was not quite finished).

Feature1 and feature2 are not yet finished, and we will need to rebase them onto feature. And very similar conflicts than when we rebased feature onto master will arise. I heard recently about git rerere but I tried on a very simple example and I had very similar conflicts but not quite the same ones and so I had to resolve them all each time. I did not totally understood how it works however so maybe I did something wrong.

Another solution would be to not rebase feature onto master but rather to merge master into feature. So if conflicts are resolved there, they will not appear anymore when I rebase feature1 onto feature. This pollutes the history of feature, but I guess I could do an interractive rebase to squash undesirable merge commits before merging feature into master.

So basically my question is: Is there a good practice for what I am trying to achieve ? My coworkers tend to just merge everything regardless, but I would like to have something cleaner and that I can understand from start to finish. Can I keep on rebasing and avoid recurring conflicts with git rerere ? Is it ok to rebase feature since it is a public/shared branch in this case ? Should I just not care about the state of feature until I decide to merge it into master and do some refactoring only then, merging master into it in the mean time ? Is rebasing feature onto master instead of merging master into it too much trouble for what it's worth ?