排查堆积拉取请求问题

本文介绍使用堆积拉取请求时可能会遇到的常见问题，以及如何解决这些问题。

存储库报告冲突

当级联存储库遇到冲突时， gh stack rebase 停止并列出冲突的文件。

若要解决冲突并继续：

1. 打开每个冲突的文件并解决冲突标记（<<<<<<<、、=======``>>>>>>>）。

2. 暂存已解析的文件。

   git add .
   

3. 继续重定基。 其余分支会自动重新定基。

   gh stack rebase --continue
   

如果冲突过于复杂或要重新开始，请中止重新数据库以将所有分支还原到其预重新数据库状态。

gh stack rebase --abort

由于冲突而停止同步

如果在运行时 gh stack sync检测到冲突，所有分支将还原到其原始状态，因此不会部分更新任何分支。 通过直接运行存储库以交互方式解决冲突，然后推送更新的分支。

gh stack rebase
gh stack push

修改会话不会启动

gh stack modify 需要干净启动状态。 如果它不会启动，请确认：

• 已签出活动堆栈。
• 工作树干净。
• 没有正在进行的重新基。
• 没有请求请求排队进行合并。
• 提交历史记录是线性的。 如果不是，请先运行 gh stack rebase 。

修改会话中断

例如，如果 gh stack modify 由于不想解决的冲突或终端崩溃而中断，则可以将堆栈还原到启动前的状态。 预修改快照缓存在本地进行恢复。

gh stack modify --abort

如果应用更改时发生冲突，并且你想要继续前进，请解决冲突，暂存文件 git add，然后运行 gh stack modify --continue。

拉取请求无法合并

堆栈中的拉取请求只能在它之后合并，并且每个拉取请求都满足所有合并要求，并且堆栈具有完全线性的历史记录。 如果阻止合并，请检查：

• 拉取请求及其下方的所有拉取请求都具有所需的评审和通过检查。
• 堆栈具有线性历史记录。 如果更改被推送到下分支或中继向前移动，则历史记录可能不再是线性的。

若要还原线性历史记录，请运行 gh stack rebase ，然后单击 gh stack push合并框中的 Rebase 堆栈 。 有关说明，请参阅“管理堆积拉取请求”。

合并在堆栈中停止了部分路

合并前检查在任何合并之前运行，但合并仍可能失败。 例如，由于发生意外冲突或间歇性故障。 如果失败在一定程度上发生，合并会在该拉取请求处停止。

• 将请求拉取到合并成功保留在基分支上的请求。
• 失败的拉取请求及其上方的拉取请求保持打开状态。

解决失败拉取请求的问题，然后重试合并以将堆栈的其余部分搁置。

从合并队列中删除了拉取请求

堆栈保存在合并队列中。 如果从队列中删除或弹出拉取请求，则堆栈中上方的所有拉取请求也会弹出并删除。 解决基础问题后，将堆栈重新添加到队列。

大型堆栈还可以在连续合并组之间拆分：合并队列允许合并组超过其配置的最大大小 50%，以将堆栈一起保留在一起，并且所有不适合在后续组中的拉取请求在完整堆栈降落之前继续。

在堆栈中间关闭拉取请求

关闭堆栈中间的拉取请求会阻止其上方的所有拉取请求可合并。 保留堆栈关系，因此若要打开不同的拉取请求或更改堆栈的结构，必须先解散堆栈，然后重新创建它。

可以从网站取消堆栈， GitHub 或者使用 gh stack modify.. 取消堆栈仅删除打开、草稿和关闭的拉取请求;合并拉取请求和排队拉取请求保留在堆栈中。 请参阅 管理堆积拉取请求 和 管理堆积拉取请求。

重新数据库后未对提交进行签名

从拉取请求触发的存储库在 GitHub服务器上运行，并且 这些提交未 签名。 如果存储库需要签名的提交，请改用存储库 GitHub CLI 。

• 运行 gh stack rebase 使用本地 Git 操作，因此生成的提交遵循本地 Git 提交签名配置。
• 重新分组后，使用 <a0/&a0> 推送更新的分支。

不能跨分叉创建堆栈

堆积拉取请求要求所有分支都位于同一存储库中。 不支持跨分支堆栈。