I have the following scenario:
Once the developer has finished its work, he creates a pull request on the develop branch. After approval, we squash-merge the feature branch onto the develop branch in order to not include all the commits the developer made on the feature branch. This allows us to have a clear and clean git history on the develop branch.
Sometimes the feature branch needs a rebase from the develop branch and this is where the trouble starts.. When we rebase the feature branch with the develop branch, all of the sudden a lot of commits from the develop branch are included in the pull request.
How can this be avoided so that the PR only includes the actual commits from the feature branch?
I suspect this happens after you rebase develop from master after a hotfix release.
Consider the following scenario:
master A->B->C
\
develop D
\
feature A E
You then get a hotfix in master
, F, and rebase develop
off it. The rebase creates a "new" commit (D') with a different hash, so from git's perspective D and D' are two separate and unrelated commits. D still exists, and C is its parent, but it is no longer on develop
- only on feature A
:
master A->B->C->F
\ \
develop \ D'
\
feature A D->E
So if you then try to rebase feature A
off develop
, if you don't do an interactive rebase, git won't be able to recognise that D and D' are the same commit, and you'll end up with the following:
master A->B->C->F
\
develop D'
\
feature A D->E
To get around this, when rebasing feature A
from develop
, do it interactively and tell git to drop D
, as you know that it is identical to D'.