I am a developer working in a team of 8-9 people. We have issues while raising PRs. We have 2 branches. One for Dev and One for Prod (main). Whenever we need to develop a feature, We are creating a branch from main making the code changes and raise a PR for pushing it to dev branch to do our initial testing, later when everything is working fine in dev, we are raising a PR from feature branch to main to deploy to prod. We are following this approach because we have some features which last for months and we don't want to push it to prod, but test in dev. So we are not following the ideal approach of creating feature branch from dev and raising PR from feature branch to dev and then dev to release. So we couldn’t do that due to the long lasting requirements. But the approach we are following is becoming quite messy while raising PRs as the git is not recognising the commits from dev and release as same even though the code changes are same. due to this, for every PR, we are getting so many file changes which are old commits. is there any better way to do this keeping long lasting requirements that to be tested in dev but not pushing to prod?
Pictorial representation of problem
I expect PRs to go smooth without old commits interfering and by allowing us to hold long lasting features in dev with out pushing to prod by allowing us to still push other small requirements. Any other approaches, best practices and suggestions are welcomed.