在我的GitHub repo上，我有两个主要分支，develop和main，它们分别代表一个测试和生产就绪的网站。我在某个分支上开发一个功能，比如newFeature，然后将其合并到develop中进行测试。其他人也在用他们的分支做这件事，所以develop有很多更改。假设所有内容都经过了测试，我们现在想通过将develop合并到main中，将这些更改添加到生产就绪站点。
我想定期从develop到main进行合并，比如每周五上午10点。我需要与本周添加更改的任何人联系，以确保一切都经过测试并正常工作。为了确保这里的成功机会，我想防止人们在周四下午2点之后将任何拉取请求合并到develop中。
开发人员(意识到了这一限制(应该在当天剩下的时间里测试develop上的任何更改，这些更改将在第二天早上添加到main中。如果他们发现develop上已有的内容有任何问题，他们可以在分支机构上解决问题，向develop提出PR，并要求存储库所有者(不受此限制(批准他们的PR。
这种情况下，用户(除了回购所有者(不能在一周中的某些时间将PR合并到分支机构中，这可能吗？
有多种方法可以实现这一点，但没有一种是特定于GitHub的：
- 锁定
develop分支，从时间X开始，到时间Y结束。AFAIK最流行的集中式Git回购工具可以让管理员手动锁定和解锁分支(通过显式锁定或调整权限(。你是否能自动计时取决于工具，但我认为你可以编写自定义集成，如果不能，每周手动锁定一次也没什么大不了的，尤其是因为你必须手动干预才能修复错误 - 添加自定义集成"；"门控登记"；使得在期望的时间帧期间存在额外的要求
- 根本不要锁定
develop！这实际上是大多数人所做的。例如，在GitFlow中，你只是出于这个原因创建了一个发布分支。如果你不想真正创建专用的发布分支，你不必；只需记住从develop中截取并测试的提交ID，如果没有新的PR来修复错误，只需释放该提交ID并将该提交ID合并到main中即可。如果您最终修复了错误，那么您还可以创建一个release分支，这样就有一个分支可以将修复程序PR到其中
无论你是否使用Git Flow，出于理智的目的，我强烈建议选择3，这样你就不必在发布周期中停止开发。