Cleanup branch after git rebase

user_7338454 0
Viewed 1243

I am usually fairly capable when it comes to Git but I am not so sure what happened in this scenario, and what would be the best solution.

Scenario:

  • I created a feature branch off of dev.
  • Fix completed, tested and pushed.
  • I then switch back to dev, do git pull and see several commits from my team mates.
  • git checkout featureBranch followed by git rebase dev to replay my changes over the latest dev (as I understand it).
  • git status says that local and origin featureBranch have diverged git pull is required.
  • git pull results in a commit message terminal opening.
  • git status shows git push is required.
  • After git push, my PR shows all of the commits from my co-workers from dev on my branch, not just the fix.

What did I do wrong in this case? I wanted to stay working on my featureBranch in isolation until it was fixed, and at that point, make sure my changes were applied to the latest dev to avoid conflicts. In this case my team encourages rebase.

Why are the new commits from dev showing in my PR featureBranch >> dev when they are already on dev?

What would be the best solution to bring my PR back to the 1 original commit? I don't mean squash here, I mean the dev commits should not be here.

rebase git
3 Answers

What did I do wrong in this case?

The second git pull. Once you have rebased, a git status is expected to tell you you have diverged.
But you are supposed to force push from there (git push --force), to replace the remote history of your PR branch by a new one.
This is especially true if you are the only one working on that PR.

VonC_63090

git status says that local and origin featureBranch have diverged git pull is required.

When you rebase you're essentially changing the history of your branch. This history will differ from the history at origin, but this is fine because it's what you wanted. What you probably should have done at this step was force the push by running push -f to origin/yourFeatureBranch.

user_22032180

git status says that local and origin featureBranch have diverged git pull is required.

This is expected, since you've rewritten your local branch history compared to the original version (tracked upstream).

git pull results in a commit message terminal opening.

Yeah, what you want to do here is either not do a pull, and merge locally, or force push upstream to reflect your rebased branch version in the remote. By pulling you're then merging the original history into your rebased history again, which goes against the purpose of rebasing.

What did I do wrong in this case? I wanted to stay working on my featureBranch in isolation until it was fixed, and at that point, make sure my changes were applied to the latest dev to avoid conflicts. In this case my team encourages rebase.

(In your situation) what you did "wrong" was to pull the branch again after rebasing. You should force push carefully instead (e.g. git push myremote mybranchname --force). If you get into the habit of always specifying the remote and branch name when force pushing you're much less likely to overwrite something you didn't expect to.

Why are the new commits from dev showing in my PR featureBranch >> dev when they are already on dev?

Because you rebased but then messed up the branch history by pulling your original version back into your rebased version. You should expect a successful rebase to only show your commits in the pull request.

What would be the best solution to bring my PR back to the 1 original commit? I don't mean squash here, I mean the dev commits should not be here.

If you haven't changed anything other than rebasing since you last pushed to your remote, I would suggest resetting and rebasing again:

git reset --hard yourremote yourbranchname
git rebase devbranch
git push yourremote yourbranchname --force

Hope this helps.

user_28128420
Related