1

I created a new branch, new-feature, off of a working feature branch that was in code review, working-feature.

My plan was this: Once working-feature got merged to our develop branch, I would git rebase the new feature branch so that it was based on the new version of develop.

HOWEVER, I forgot to run this rebase command before I pushed new-feature to Github. So now, my Pull Request into develop contains commits that have already been merged (commits from the original working-feature branch). These are all at the start of the list of commits, followed by the actual commits from the new-feature branch.

My question is: Is this a problem? Can I merge this PR with no issues? Is there anything that I can do to omit the commits that have already been merged? Thank you.

Ian Anderson
  • 23
  • 3

1 Answers1

0

Rebase your new-feature commits onto develop now:

git rebase --onto develop working-feature new-feature

(If you don't know about the --onto syntax, you might like to read my little essay on it: https://stackoverflow.com/a/68636306/341994.)

And then push with force:

git push --force-with-lease origin new-feature

(We are told not to push shared history, but arguably a pending pull request branch is not actually shared. Okay, if someone has pulled this branch to their local, it's not so nice for them, but it's extremely unlikely, and it's not difficult for them to delete the local version of the branch and pull it again.)

matt
  • 515,959
  • 87
  • 875
  • 1,141
  • No problem. Your intentions were excellent: branching off an existing PR and rebasing after that PR is merged is a perfectly good workflow, and solves the problem it is intended to solve. Forgetting to rebase before pushing is human; we've all made this same mistake. :) – matt Sep 03 '21 at 14:35