Git merge request sequence

You might consider rebasing feature-operation on top of feature-auth, assuming you are the only one working on that feature branch..

That way, you benefit from all commits/features from feature-auth, and can resume working on feature-operation.

git checkout feature-operation
git rebase feature-auth
git push --force

while I read somewhere that Ideally all branches should be made from master.

That is not mandatory.

In your case, you get from:

to:

m--m--m--m--m  (master)
    \          / (pending MR)
     fa--fa--fa
               \
                fo'--fo'--fo' (feature-operation rebased)

The OP adds:

for example I have done working on feature-operation and still feature-auth is not accepted.
Then after completing work and before making a merge of feature-operation as well I have to rebase to master?

If feature-operation is based on feature-auth work, you will have to wait for feature-auth to be merged, before (indeed) rebasing feature-operation on top of an updated master.

And:

So I should not push any changes to feature-operation until master is not updated? Or just before merge request?

While you are working on feature-operation, you can push that work on your remote repo as many time as you want.
Once feature-auth is merged to master, you rebase your feature-operation on top of master (after a git pull on master branch), and you git push --force your feature-operation rebased branch, and continue working (or, if you had finished, make a MR)

In my view, feature branches should emerge from the same branch they will be merged to. If feature b depended on feature a, they probably should not have been different branches and different PRs to begin with.

Rebasing feature b onto feature a could mean your PR on feature b includes all of feature a, which is wrong and unfair to the approval process. Not to mention the force push, which is a bad sign.

In my view, if feature b needs something feature a has, you should just cherry pick it.

I am far from a purist, and I don't like rebase; I prefer things simple, but I also don't have a code review committee breathing down my neck, just teammates.

I would adopt @VonC's branching diagram, branch master to fa, and when fa is completed to your satisfaction, branch fa into fo. No rebasing necessary.

If there are changes in any preceding branch that implement features you want to use, or are important for testing, merge fa or master into fo as often as you like. If nothing else, that will simplify the final merge.

The final merge of fo into master will be closer to master than otherwise, making that final review simpler for all concerned.