问题
Our team has a master branch on GitHub and several other feature branches that eventually need to be merged back to master.
What should one do to ensure that the feature branch is up to date, before a Pull Request is created on GitHub? Is there a sort of lock that we can implement on the master branch to enforce up-to-date feature branches before Pull Requests can be created?
回答1:
GitHub's branch protection can require branches to be up to date before they're merged, but not before they're created. This makes sense. Consider:
*---*---*---* [master]
|\
| *---*---* [feature-1]
\
*---* [feature-2]
Here, both feature-1 and feature-2 are up to date with respect to master. If the restriction required pull requests to be up to date when they're created we can create a PR for each branch.
But what happens when one of those PRs gets merged?
*---*---*---*-----------* [master]
|\ /
| *---*---* [feature-1]
\
*---* [feature-2]
Now feature-2 is no longer up to date. What should happen to its PR? Do we do nothing since it was up to date when it was created? Do we invalidate the PR entirely and require a new one to be created? Should we only ever have a single PR open at any given time?
GitHub's system applies at merge time. This way PRs can be created before they're ready for merging (e.g. draft PRs) and can safely generate meaningful discussion rather than being rushed through. It also means that we don't have to deal with the previous question.
回答2:
I'm not even sure that you need any such feature here. If a feature branch be really far out of sync with the master branch such that merge conflicts would result from the merge PR, then GitHub will flag that pull request and refuse to automatically complete it.
Of course, as a matter of practice, most developers will learn from experience that merging/rebasing with master is a generally good habit to have. But, these things are already enforced by GitHub, at least by default.
来源：https://stackoverflow.com/questions/55757142/enforce-up-to-date-pull-requests-on-github