My team is using pull requests, and we also push our latest changes at the end of the day, even if the latest is a work-in-progress. This has the unfortunate side-effect of sometimes updating a previous pull request with broken code. I can imagine a few possible solutions:
Are there any other options I'm missing, and what solution worked for you to resolve this issue?
I don't know what your branching strategy is, but typically if you're working on a feature branch, you should only issue a pull request for that branch when the feature is complete. Then you should start working on your next feature on a new feature branch. The only reason, in my opinion, that there should be additional commits on the same branch that the pull request was issued for is if the pull request review process has uncovered changes that needed to be made.
That said, in Settings->Pull Requests there is a checkbox to "unapprove all reviewers when the source branch of a pull request changes". That box along with requiring a minimum number of approvers (on the same screen) should help prevent this problem, I think.
That will prevent the incorrect merge - it won't allow you to do the one you wanted to do, though. Ultimately, a pull request is merging a branch, not a specific commit. You could create a branch just for the pull request that you never advance, but I still think feature branching is the best way to go.
Need a few clarifications! What branch is everyone pushing their "end-of-day" work into? And are the pull-requests FROM 'master' or TO 'master'? (In other words, what are the source and target branches of the pull-requests?)
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.