我想要一个有福的存储库和几个组或开发人员存储库。
开发人员应从受祝福的存储库中克隆并在该克隆的存储库上工作并提交他们的更改。每当他们觉得自己的工作完成时，他们就会将更改推送到公共(public)存储库。然后首席开发人员应从公共(public)开发人员存储库中提取更改——做任何他想做的事情(签署、修改等)，然后将其推送到受祝福的存储库。
在代码审查计数代码可能被拒绝的任何环境中。假设开发人员 A 和 B 同时开发一项功能。两位开发人员都完成了他们的工作并将补丁推送到他们的公共(public)存储库。开发者 A 的补丁被接受，而开发者 B 的补丁被拒绝。然后首席开发人员将开发人员 A 的更改推送到 blessed 存储库。开发人员 B 修复了补丁并在 blessed 存储库(分别为开发人员 A 接受的更改)之上重新构建他的工作。如果开发人员 B 现在将他的工作推送到他的公共(public)存储库，他将收到一个错误，即 存储库具有不兼容的历史记录。
我能解决的唯一方法是删除公共(public)存储库并重新创建存储库。有更简洁的方法来解决这个问题吗？
最佳答案
考虑到公共(public) repo 只有客户集成经理，B 可以安全地强制推送他的工作:
git push --force
集成管理器还没有接受 B 的任何提交，因此 B 可以重写他的提交历史并再次推送它们。
其他人是否会从 B 的公共(public)存储库中克隆/pull ，那么 push --force 将不会被视为可接受的解决方案。
OP Alex 在评论中添加:
So do I get that right? if anybody would pull from B the workflow is broken because the blessed repo isn't a strict ordered subset of B's ?
我回复:
如果其他人从 B 的公共(public)存储库中 pull ，那么该历史就会公开(在您的场景中不是这样，因为只有集成管理器 pull ，甚至不保留 B 的提交)。
而且你不应该改变公共(public)历史。请参阅 Pro-Git 书籍“ the peril of rebasing ”部分
So if I have a hotfix to push to the blessed repo I'd kill all the stuff from my public repo to be as close as possible to the blessed one? Or how would the lead then cherry pick hotfixes?
如果您的公共(public)仓库中还有其他尚未被接受的东西，您可以在专用的“hot_fix”分支中发布您的修补程序(B 已首先基于 blessed 仓库，然后推送到 B 的公共(public) repo )，由集成经理为此进行监控。
无论如何，重点是:集成经理总是希望在他现有的提交集之上有新的提交，新的历史，而不是冲突的历史(因为缺少来自 B 的 rebase )。
任何有冲突的历史都应该被拒绝，无论分支的起源如何。
谨防挑剔，这可能会导致麻烦。见:
关于git - 如何将更改推送到具有冲突历史记录的 git 存储库？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7464580/