在我的 GitHub 存储库上，我有两个主要分支，develop 和 main，分别代表测试和生产就绪网站。我在某个分支上开发一个功能，比如 newFeature，然后我将它合并到 develop 中进行测试。其他人也在他们的分支上这样做，因此 develop 对其进行了许多更改。假设一切都经过测试，我们现在希望通过将 develop 合并到 main 来将这些更改添加到生产就绪站点。
我想定期从 develop 到 main 进行此合并，例如每周五上午 10 点。我需要与本周添加更改的任何人一起检查，以确保一切都经过测试并正常工作。为确保在这里成功的机会，我想阻止人们在星期四下午 2 点之后将任何拉取请求合并到 develop。
开发人员（已获悉此限制的人员）应在当天剩下的时间里测试 develop 上将在第二天早上添加到 main 的任何更改。如果他们发现 develop 上已有的内容有任何问题，他们可以在他们的分支上修复该问题，向 develop 提出 PR，并要求存储库所有者（不受此限制的约束）批准他们的公关。
用户（repo 所有者除外）无法在一周的某些时间将 PR 合并到分支中的情况是否可能？
答案 0 :(得分：2)
有多种方法可以实现这一点，而且它们都不是特定于 GitHub 的：
develop 分支，从时间 X 开始并在时间 Y 结束。AFAIK 最流行的集中式 Git 存储库工具能够让管理员手动锁定和解锁分支（使用显式锁定或通过调整权限）。您是否可以自动化计时取决于工具，但我假设您可以编写自定义集成，如果不能，每周手动锁定一次并不是什么大问题，特别是因为您必须手动干预以允许错误修复develop！这实际上是大多数人所做的。例如，在 Git Flow you simply create a release branch 中正是出于这个原因。如果您不想实际创建专用发布分支，则不必；只需记住您从中截断和测试的 develop 提交 ID，如果您没有用于修复错误的新 PR，只需发布该提交 ID 并将该提交 ID 合并到 main 中即可。如果您最终修复了错误，不妨创建一个 release 分支，以便有一个分支可以将修复程序 PR 到其中。无论您是否使用 Git Flow，出于理智的考虑，我强烈推荐选项 3，这样您就不必在发布周期中停止开发。