我和我的同事John正在使用Gitlab合作开发上游项目P。我们都有分叉的P，在我的分叉中，我有两个分支：B1和B2。B1 本质上是 B2 的旧版本，但这两个分支已经分道扬镳。
John 想从他的分支 C1 向我的分支发出合并请求，该分支是从 B1 分支出来的。他的合并请求最初针对 B1，但我要求他将其重新定位到 B2;他这样做了，但现在有一堆我不想要的额外提交，因为 B1 和 B2 已经分道扬镳。
为了让 Jake 的工作更轻松，我决定在本地签出他的合并请求并自己重新定位它，然后将更改推回去，这样他就不必做任何事情了。我运行了以下命令：
git fetch origin refs/merge-requests/17/head:refs/merge-requests/17/headgit checkout refs/merge-requests/17/headgit checkout -b mr17git rebase B2git push origin refs/merge-requests/17/head
但是，推送并没有像我想象的那样更新他的开放合并请求，而是成功了，但说"一切都是最新的"。这让我感到惊讶，因为我刚刚重新调整了分支。我检查了.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(在初始变基尝试之前(：
git rebase --onto B2 B1 mr17
你们都应该在分叉上工作，并推送到分叉的分支，而不是refs/heads/merge_requests/...分支。合并请求引用通常只是 GitLab 的内部引用，不应直接使用。您应该使用它们的唯一时间是从合并请求中提取更改进行测试。推送到这些引用将被推送到源分支覆盖。