jmcgui05 jmcgui05 - 1 year ago 165
Git Question

Cleanup branch after git rebase

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.

Answer Source

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.

Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download