How do I rebase my PR without adding commits to it?-CodePudding

Let's say I have a repository with branch master. I checkout a branch feature-branch and started working on it. I raise a PR and push 3 commits in the PR over time. Let's say the master branch moves forward with 10 commits during this time and I have to rebase my PR to the tip of master. I follow these commands for that:

git checkout feature-branch
git rebase master
git pull
git push

These steps do put my PR forward but now my PR contains 3 10 = 13 commits, which makes getting it reviewed difficult. Any solution for this?

CodePudding user response：

Ok.... as LightBender is saying, you have a problem in your recipe because you are merging the old branch that you are trying to rebase so you are keeping the old commits (not to mention that I am not seeing that you are pulling changes into your local master).

The way you should go about it normally is:

git checkout master
git pull # bring changes from upstream master into your local master
git checkout feature-branch
git rebase master # this is how you move your branch on top of master, keeping it straight
git push -f # assuming that the upstream branch as been set before
# if the upstream branch is not set, then write git push -f origin @ -u
# after that, you can just run git push -f (on subsequent pushes)

Now.... how do you get out of the mess that you are in? Well.... I am not completely sure this will work, but it will probably. Assuming that you just came of of the last pull that you were doing there:

git checkout feature-branch~ # go to the first parent of that merge.... you should be on top of 3 commits that are straight from main, no merges
# If that is the case, just place your branch over here:
git branch -f feature-branch
git checkout feature-branch
git push -f

If actually, that is not the case, then you will need to get yours hands dirty and cherry-pick the 3 revisions that you want to have in your branch.... or rebase interactive, which is nice, but can be a little bit scary... which cherry-pick it should be simple:

git checkout --detach master # let's get ourselves on top of master, but let's not move it around
git cherry-pick first-commit-of-the-branch-you-want #you probably have more than one _first_ commit in the messy branch, any of those _firsts_ would do, use its commit ID
git cherry-pick second-commit-of-the-branch-you-want # same thing with the second
git cherry-pick third-commit-of-the-branch-you-want
# if this is your branch and it looks good (straight line from master, 3 commits, no merges):
git branch -f feature-branch
git push -f

And you got out of hell. Now you can start using the recipe as I described in the beginning.

CodePudding user response：

As a general rule, rebasing branches that have already been pushed is a bad idea. In this case, after you rebase—creating new commits on the tip of master—you're pulling (and merging) the original feature branch with all its commits into your rebased branch, then pushing the whole thing up.

The merge-base remains the same as a result, with all of the commits since that point now being "on your branch" including two copies of your commits.

They should have no issues in reviewing because generally they'll be looking at the diff, not the individual commits. You have, however completely defeated the purpose of a single-line history (the usual reason for requiring rebase over merge) because you've introduced a merge.

In these situations, it's usually best practice to create a new branch if you've already pushed the code and point the PR at the new branch to avoid cross-contamination between the two versions of the history.