How can you rebase a branch that is tracked remotely?

We've got a development branch, dev1. Starting from that, I create a feature branch, f1 and push to our git server:

git checkout -b f1
git push -u origin f1

I make some changes, commit them and push them to the branch.

git commit -m "Some changes"
git push

I do that several times, and I later want to get caught up with dev1, with rebase:

git rebase origin/dev1

After resolving some conflicts and committing that, git status gives something like:

On branch f1
Your branch and 'origin/f1' have diverged,
and have 97 and 75 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

After doing some research, it appears that the fact that git status indicates the remote has its own divergent commits is because of the rebase (i.e.: I should have expected that). The git doc suggests using --force-with-lease, but we don't allow that on our server (denyNonFastforwards = true), and I don't know that we want to.

In this case, the remote branch is really just being used as a backup, as I'm the only dev working on this particular feature, but we would like to support multiple developers working on a feature branch, and in any case, we do want the feature branches effective backed up in our git server -- especially for large features that take some time to implement. In the past, I've simply used merge, but have sometimes seen odd behavior, such as "conflicts" with files that were modified in dev1 which I never touched in the feature branch.

So, my questions are:

What happens If I would pull, as suggested by git status? It seems like at this point we have two different histories, and I might end up with a mess.
Is there a better way to handle this? Forgo rebase and only use merge, even if I'm the only one using the branch? Or create a new feature branch after each rebase (f1.1 f1.2, ...), and never push on a feature branch after a subsequent rebase? Something else?

Thank you in advance.

Solution

Forgo rebase and only use merge

Yes, that's it. It's not a good idea to have a long-lived feature branch, but if you have to do it and you have some reason why you need to keep up with the development branch, the way to do that is to merge the development branch into your feature branch (I call this a "reverse merge").

On the other hand, in your situation, I would just rebase and then push with force. By "in your situation", I mean:

You are the only person working on this branch; and
This branch is not really public; the only reason you pushed it is, as you said, for backup.

Pushing with force is completely acceptable in that situation, because your branch is not public.

Okay, on the other other hand (the third hand?), you're not allowed to push with force, even for a personal branch. Well then, what I would do is make another remote, personal and private, and push to that as a way of doing backup.