How to manage multiple staging branch (dev, stg and production branches) regarding PR integration?

Question

I'm working on a team with multiple developers, all working on different things at the same time.
We have 3 general branches: dev, stg and master(production).
Each one of them has their own CI/CD server and are feeding a different environment.

The current flow for starting a new feature is:

1. Diverge out of master (production) a new feature branch
2. Develop locally and create commits.
3. Once ready and tested locally, push feature branch to remote, create PR and merge it into development branch.
4. Once confirmed to be working in the dev environment, open a PR to merge the feature branch to staging.
5. Once confirmed to be working in the stg environment, open a final PR to merge the feature branch to production and delete the feature branch.

This in my mind, shouldn't introduce any conflicts and allow multiple engineers to test multiple features in the development and staging environments, without pushing unfinished code to production.

The only code that's being pushed is from a feature branch that was already merged and tested in dev and staging, and not is being merged directly to master (production).

We avoid merging development > staging and staging > production because at any given moment, development can have changes we still don't want to merge to production.
So every developer shouldn't be affected by other developer's work.

The problem I am facing is I'm somehow, occasionally, create a PR to merge a feature branch to development branch, and then I see more "files changed" than what my feature branch is changing + many commits and I'm not sure where they are coming from.

My question is if our workflow is flawed and we should follow a different strategy.

Answer 1

The problem I am facing is I'm somehow, occasionally, create a PR to merge a feature branch to development branch, and then I see more "files changed" than what my feature branch is changing + many commits and I'm not sure where they are coming from.

This is a classic case of rebase --onto.

Whenever your PR shows too many commits, it means you need first:

• to fetch the remote tracking branches, refreshing the target branch (the branch your PR needs to be merged into)

• rebase your PR onto that refreshed remote tracking branch

• force push it again: that will update the PR which will show only your PR commits.

That is:

git fetch
git rebase --onto origin/dev my_feature_branch_first_commit~ my_feature_branch

Replace 'my_feature_branch_first_commit' by the first commit of the feature branch, and don't forget the ~ (to select the parent of that first commit, since a rebase --onto move all commits after the first commit parameter)

If you know that first commit was done starting from another branch, you can replace 'my_feature_branch_first_commit' with $(git merge-base my_feature_branch another_branch) (plus, again, the ~)