Menu
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?
994
git rebase origin/master will merge in the requested branch ( origin/master in this case) and apply the commits that you have made locally to the top of the history without creating a merge commit (assuming there were no conflicts).
If the feature branch you are getting changes from is shared with other developers, rebasing is not recommended, because the rebasing process will create inconsistent repositories. For individuals, rebasing makes a lot of sense. If you want to see the history completely same as it happened, you should use merge.
The Rebase Option This moves the entire feature branch to begin on the tip of the main branch, effectively incorporating all of the new commits in main . But, instead of using a merge commit, rebasing re-writes the project history by creating brand new commits for each commit in the original 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'.
96
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
