We have a master repository, which is designated to be only code that has been Approved by all team members. There was an OPEN pull request from last month that was all-but-closed (code review work was complete, individual team members had a Approved it, comments for closure added to the PR, etc. - but nobody actually MERGED it).
People went on vacation/hiatus/etc. - a month later, a team member tried to submit a new Pull request, with a set of ~10 commits. When he pushed these from his Repository to the Master, intending to _create_ a pull request, it instead automatically appended them as an amendment to the Open pull request.
We need to keep that new set apart/distinct from the old PR. We need to remove/delete/decline those specific new commits from the Open Pull Request, and then actually Merge the original Pull Request, and then have the team member re-submit the new commits as a NEW PR. How do we remove those unwanted new commits from the old/open Pull Request ?
This is a perfect situation for git history rewriting.
Do a "force push" targeting the "from branch" of the pull request to set it back to how it was before these 10 new commits arrived. In other words "rewrite the history" of the PR's source branch.
Like so:
git push --force origin <COMMIT-ID-TO-GO-BACK-TO>:refs/heads/PR-SOURCE-BRANCH
(Warning: that command interacts directly with the remote branches on your Bitbucket instance, so you must get it right the first time).
Before doing that I recommend copying the PR's current source branch to a backup branch, like so:
git checkout PR-SOURCE-BRANCH
git checkout -b PR-SOURCE-BRANCH-backup
git push
I also recommend cherry-picking the 10 commits that got there accidentally to another new branch just so you have a nice isolated backup of them to help the original hapless developer who accidentally pushed them resume their own work.
I went through a similar scenario earlier this week and solved it like this:
You can now push the other branch with the new commits to Bitbucket and create a new Pull Request.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for the response - but that scenario will not work for us. I probably should have clarified why step 1. of your solution negates that as an option for us.
The original Pull Request was protracted over almost a week, with a LOT of documented history (comments and replies and counter-comments) from the team, and included 3 iterations of code review follow-up commits - so we need to preserve all that documentation and history and tie the open Pull Request up with a bow as "complete" as-is (which it essentially was - only thing missing was that final MERGE).
The problem is, we need to separate/extract the new commits (that were unintentionally appended) as a new, distinct, _separate_ pull request itself.
Barring some other solution, our anticipated resolution would be:
1. In the Local repository, do a backout of each of the new commits.
2. Submit this set of backouts as if a commit set to also be pushed, which will get sucked into the open pull request.
3. This should bring the open pull request back to a zero-state of where it was prior to the additions.
4. MERGE that pull request.
5. Go into the Local repository, and backout the backouts for each commit.
6. Submit that commit set as a new Pull Request.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
All the information in your original pull request will still be there, declining the pull request will just close it so you can delete the branch and then recreate it. Once you have recreated it by pushing it back to Bitbucket after you rolled it back and reopen the pull request again, everything will be there except for the 10 new commits.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.