我们有一个GitHub项目（主）生产分公司，团队的每一个成员都有该项目的Fork到自己的资源库。如何创建一个Git回购
一旦开发人员固定的东西，他创造他的地方分叉回购内一个新的分支，并提交到该远程仓库后，他们要求Pull Request，这样的变化进入主reposiroty。
我们发布到生产的“手动”，每周一次，但我们不得不在生产中的问题，因为不期而遇开发商已承诺其分叉库和其他开发人员具有较高的privilegies接受更改并归并到主回购，那么别人发布生产，他不知道这些新的变化没有通过质量保证过程。
所以，我要的是要创造这样一个Production库，所以当我们在主回购的代码，我们知道是稳定的，然后努力创建这样一个分公司生产，所以如果被错误的东西将提交并合并到主回购，那么生产发布的代码不受影响。
任何线索或最佳实践来做到这一点？
使用Git的工作流程是不够好，对待这个问题的关心。
首先，要解决这个问题：
款待意外码推为错误并修复它，你会解决任何其他的bug。执行此活动的最佳人员是推送该代码的开发人员。开发人员可以将它修复到fork中并提交一个pull请求。尽量不要使用此拉取请求添加任何其他不相关的代码。
关于生产分公司或回购：
我不认为你需要另一个生产科/回购（你已经有一个）。正如您在当前的PROD回购中发生的那样，意外的代码推送也可以使其成为新的分支/回购。
而是使用标签/释放功能在GitHub上。只要master repo中的代码状态已准备就绪，就可以对其进行标记并将该标记用于生产发布。
不知道我在正确理解的问题，但你可以根据需要添加尽可能多的远程仓库。有一个在临Git的本书叫Working with Remotes一节，深入探讨这一点。
根据我的经验，分离开发和生产的代码通常与分支模型完成，如git的流动。如果你喜欢，你可以创建单独的存储库来解决这个问题，但这样做是不必要的。这是因为如果开发人员A提交由开发人员B合并的PR，那么开发人员C在尝试提交上游时会得到一个非快速转发错误。这被称为颠覆式工作流程。每docs：
的Git不会让你推，如果自上次有人推你牵强，所以，所有开发商推到同一台服务器集中模型工作得很好。
如果在推送前未向上游分支提交并合适地提交，那么有人可能会自己重写历史记录。