Is there any better implementation strategy to avoid conflict while using git rebase or git merge?

Question

Currently I am working on a project with following strategy for Git:

• We have a master branch (production)
• We have a staging branch (staging server)
• Whenever we need a new feature or fix, we create feature branch from master and after implementation, create a Pull Request to Staging. After approval and unit test, we create another Pull Request from feature branch to Master.

Now, I'm having some doubts, though haven't faced any issues yet. If anyone push changes to Master (via Pull Request) and I want to use "git rebase". Is the following strategy good, if my feature branch is not yet merged to staging or production.

• First I will Pull changes to master.
• Then, I will "rebase" feature branch from master.
• Then, I will delete remote feature branch, (because currently I am only working on it)
• Then, Push the new feature branch and create a Pull Request to Staging.

Is this all right? (Question 1)

Now, let's assume, my branch is already merged to Staging. So in that case, I should merge instead of rebase? (Question 2)

Note: I don't want to change any previous commit history in Staging or Master Branch. But If I am only working on a feature branch, I can change history. I don't think that will cause any problem.

With the Question 2, What should be the strategy or steps to do so?

Conclusion: I want to know, If the above strategy as asked in Question 1 is good? Shall I continue with that and If there is any better solution to avoid conflict?