推送到Gitlab merge requests remote无法识别来自rebase的更改

我和我的同事John正在使用Gitlab合作一个上游项目p。我们都有叉子P，在我的叉子里，我有两个分支：B1和B2。B1本质上是B2的一个旧版本，但这两个分支存在分歧

John想从他的分支C1向我的分支发出合并请求，分支C1是B1的分支。他的合并请求最初以B1为目标，但我要求他将其重新定位到B2；他这样做了，但现在有一堆额外的承诺，我不想，因为B1和B2已经分歧

为了简化Jake的工作，我决定在本地签出他的合并请求，然后自己重新定位，然后将更改推回，这样他就不必做任何事情了。我运行了以下命令：

git-fetch-origin-refs/merge-requests/17/head:refs/merge-requests/17/head

git签出引用/合并请求/17/head

git签出-b mr17

git rebase B2

git推送原点引用/合并请求/17/头

然而，并没有像我所想的那样更新他的开放合并请求，推送成功了，但是说“一切都是最新的”。这让我很惊讶，因为我刚刚重新设置了树枝的基调。我检查了.git/refs/merge requests/17/head，发现它指向旧的（预重基）提交散列

---

我猜我搞砸了，但我真的不明白是什么。我可以编辑.git/refs/merge requests/17/head以指向新的（重基化后）提交散列吗？或者我必须用不同的步骤重新开始吗？

您的

push

命令缺少要推送的本地分支：

git push origin mr17:refs/merge-requests/17/head

除此之外，我认为结果不是你所期望的。重定基础的分支仍将包含来自B1的所有提交（这些提交出现在原始合并请求中）。您将需要执行交互式重新基址，并从重新基址脚本中删除这些提交。或者，使用

git-rebase

的完整调用（在初次尝试重新基址之前）：

---

您应该同时处理fork和fork的分支，而不是

refs/heads/merge\u requests/…

分支。合并请求引用通常仅在GitLab内部，不应直接使用。您应该使用它们的唯一时间是从合并请求中提取更改以进行测试。对这些引用的推送将被对源分支的推送覆盖

git rebase --onto B2 B1 mr17