我们有一个GitHub
项目(主),团队的每个成员都有一个项目的Fork
进入他们自己的存储库。
一旦开发人员修复了某些东西,他就会在他的本地分叉仓库中创建一个新分支并将其提交到远程存储库中,之后他们会请求Pull Request
,以便更改进入主存储库。
我们每周一次“手动”发布到生产,但我们在生产中遇到了问题,因为偶然的开发人员已经承诺他们的分叉存储库和其他具有更高权限的开发人员接受更改并将其合并到主仓库中,然后其他人发布到他并不知道这些新变化没有通过质量保证流程。
所以,我想要的是创建一个Production
存储库,所以当我们知道master repo中的代码是稳定的并且正在工作然后创建类似于Production分支,所以如果错误地提交了一些东西,合并到主仓库然后生产发布的代码不受影响。
这样做的任何线索或最佳做法?
答案 0 :(得分:1)
我不确定我是否正确理解了这个问题,但您可以根据需要添加任意数量的远程存储库。 Pro Git 一书中有一个名为Working with Remotes的部分,对此进行了详尽的讨论 根据我的经验,分离开发和生产代码通常使用分支模型(如git-flow)完成。如果您愿意,可以创建单独的存储库来解决此问题,但这样做是不必要的。这是因为如果开发人员A提交由开发人员B合并的PR,那么开发人员C在尝试向上游提交时将获得非快进错误。这称为颠覆式工作流程。根据{{3}}:
如果有人自上次获取后推送,Git将不允许您推送,因此所有开发人员推送到同一服务器的集中模型都可以正常工作。
如果在推送之前未正确提取并合并上游分支的提交,则有人可能会自行重写历史记录。
答案 1 :(得分:0)
您的git工作流程足以解决此问题。
首先,解决问题:
将非预期的代码推送视为错误并修复它,就像修复任何其他错误一样。执行此活动的最佳人选是推送该代码的开发人员。开发人员可以在fork中修复它并提交pull请求。尽量不要使用此拉取请求添加任何其他不相关的代码。
关于生产部门或回购:
我认为你不需要另一个生产分公司/回购(你已经有一个)。正如您当前的PROD回购一样,意外的代码推送也可以使其成为新的Branch / Repo 而是在GitHub中使用标签/发布功能。每当主仓库中的代码状态准备就绪时,请标记它并使用该标签进行生产发布。