问题在于您正在使用 repos 来执行分支的用途。出于好奇，您如何处理提交被拒绝（但之后的提交很好）的情况？
任何解决方案（除了转移到适合您需求的分支策略，之后您可能会发现单个 repo 不仅足够而且更容易处理）都会变得混乱。
所有可能的选项都归结为将提交 6 重新设置为提交 3。您不真的希望重新设置返回到您的测试存储库，因为它会给所有开发人员造成混乱.但是，如果那个 rebase 不返回测试，那么最终它也必须从生产中删除，以使 repos 恢复同步。
Test Repo
1 --- 2 --- 3 --- 4 --- 5 --- 6 <--(master)
Prod Repo
1 --- 2 --- 3 <--(master)
Local
1 --- 2 --- 3 --- 4 --- 5 --- 6 <--(master)
做一个变基；将此命令中的提交号替换为相应的 SHA ID
git checkout master
git checkout -b temp_master
git rebase --onto 3 5
现在你有
Test Repo
1 --- 2 --- 3 --- 4 --- 5 --- 6 <--(master)
Prod Repo
1 --- 2 --- 3 <--(master)
Local
1 --- 2 --- 3 --- 4 --- 5 --- 6 <--(master)
\
6' <--(temp_master)
现在你必须测试6'。这是以前从未存在过的代码的新状态，并且未经测试。如果6 无意中依赖于4 或5 中的某些内容，则6' 已损坏。
所以你测试，它工作。将修补程序投入生产
git push production temp_master:master
屈服
Test Repo
1 --- 2 --- 3 --- 4 --- 5 --- 6 <--(master)
Prod Repo
1 --- 2 --- 3 --- 6' <--(master)
Local
1 --- 2 --- 3 --- 4 --- 5 --- 6 <--(master)
\
6' <--(temp_master)
现在我的建议是尽快完成4和5的验收测试，然后将master强制推送到production并删除temp_master。
如果你发现你必须在5 准备好之前推送4，它也必须重新定位到6'。
git rebase temp_master 4
git branch -f temp_master
（4 再次被替换为提交的 SHA）。
再次，停止并重新测试，因为6' 中的某些内容可能与4 发生不良交互，因此4' 是代码的新的未经测试的状态。一切都很好？那么：
git push production temp_master:master
你得到
Test Repo
1 --- 2 --- 3 --- 4 --- 5 --- 6 <--(master)
Prod Repo
1 --- 2 --- 3 --- 6' -- 4' <--(master)
Local
1 --- 2 --- 3 --- 4 --- 5 --- 6 <--(master)
\
6' --- 4' <--(temp_master)
此时，您可能会认为，当您测试了 5 后，您不妨对其进行变基，然后继续在生产中使用重新订购的分支进行运输。不要，除非您愿意在测试（以及每个人的本地仓库）中重新排序分支，这将是一件麻烦事。归根结底，您需要一个共同的历史记录，因为即使您将5 变基以获取
Local
1 --- 2 --- 3 --- 4 --- 5 --- 6 <--(master)
\
6' --- 4' --- 5' <--(temp_master)
您可能会发现 6 和 5' 看起来相同 - 它们具有相同的累积更改集和相同的结果树 - 但它们是不同的提交，基于一个的工作必须重新基于另一个.