GitHub Copilot 应用中的堆叠会话与拉取请求

请你看一下这张来自 GitHub Copilot 应用的截图。它很小，图标很多，但讲述了一个让我非常兴奋的精彩故事。这张图是一组堆叠会话（stacked sessions）。它们是在同一个仓库中的一系列任务，每个会话都建立在彼此之上！下面会详细说明，但首先，为什么这张截图如此神奇？我们需要从十多年前开始说起。我有一个非常古老的个人应用仓库。我第一次创建它是在很久以前（大约 2014 年底），这些年来它一直满足我的需求（它就像我个人的“生活”仪表盘，集成了日历、家里的智能设备和任务管理）。我偶尔会做一些更新，但越来越难处理了。我的依赖项已经变得陈旧。陈旧得令人尴尬。我还在用 React 15（2016 年发布）、Less 做 CSS 预处理，以及那个时代的 react-bootstrap 版本。是的，你没看错。Bootstrap。这确实很老了。在没有 AI 的情况下，试图理清这团乱麻需要我花上几周时间。我以前尝试过，但放弃了。这个应用虽然不是世界上最大的，但规模刚好大到让人头疼，而且投入产出比实在不划算。

……但我们现在有 AI 了，于是我启动了 GitHub Copilot 应用，添加了这个仓库，然后开始工作。

第一步：我能一次搞定吗？不能。不过我还是试了！这是我在 Plan 模式下使用的 prompt：

我想让这个项目的前端现代化。这些代码大部分是我十多年前写的，应该好好清理一下。我在想，要么开始用 Tailwind，要么就用纯 CSS（请全面评估以帮我决定），我们要移除所有 Less（等等），并在可访问性和响应式方面进行全面清理。现在我真的只想专注于样式，然后慢慢但稳妥地组织和整合 React 功能。可能也值得把依赖项现代化一下。在深入之前，我们先制定一个计划。

1. 没有什么是一成不变的，即使某些部分必须完全重写也没关系
2. 链接在悬停/聚焦时应改变颜色并添加下划线
3. 输入框的边框半径通常应该更小，标签应该更简洁
4. 容器应该有良好的换行和最大宽度，这样输入框就不会横跨整个宽屏显示器。

我把它传给 Claude Opus 4.8，又从 GPT-5.5 那里得到了一个 Rubber Duck 审查，并且来回讨论了很多次才做出决定。当我找到一个满意的方案后，我点击了“开始”，让应用在我的项目上大展拳脚，看看它是否有效！

……它没成功，而且是我的错。

第二步：意识到我以前试过

所以，还记得我说过“以前尝试过，但放弃了”吗？结果，我实际上有一个旧的开发分支，在那里我已经现代化了一些部分，但没有意识到会遇到兼容性问题。不过，这其实是件好事！当我运行这个会话的新版本时，我意识到我是从 main 分支出来的，但我当前正在使用的部署版本，用的是 dev 分支上那个部分更新的版本。所以，一些我为自己做的、想要的功能需要包含在这组更改中。但是，这些更改规模刚好大到让我不得不把这些更改应用到 dev 分支上，以保持头脑清醒，而不是把 dev 的更改合并到 main 分支。

在 AI 出现之前……天哪，这肯定会让我沮丧到抓狂。说实话，我当时也很沮丧。我花了时间和 token，试图按照我认为不错的计划来运行。但是！我只需简单地问一句就能切换方向（和会话），这比我预期的要酷得多：

之前的努力没有白费！

Copilot 为我创建了一个新会话，关闭了我尝试创建的 pull request，并将我的样式决策移植到了它应用到 dev 分支的更改中。

第三步：测试后的发现

呼，好吧，我有了一个不错的分支，以及一个我相当满意的 pull request。然而，当我开始测试时，我忍不住注意到控制台里的一些旧警告。当我看到对 findDOMNode 和 componentWillReceiveProps 的旧引用时，我的心沉了下去——这些函数我自己已经很多年没碰过了。唉。这些引用在我的代码库里已经不多了，但它们存在于 react-bootstrap 中。我再次打开了 Plan 模式，因为我需要弄清楚升级是否可行，或者是否应该完全移除这个库：

你觉得我们应该完全移除 react-bootstrap（并用一个现代替代品替换），还是只升级/迁移现有的组件？

运行这个给了我一个不错的计划，讨论了各种选项，并建议完全替换这个库。

第四步：在一个会话之上堆叠另一个会话

我需要确保我的更改不会影响已有的工作，但替换 react-bootstrap 对我来说感觉像是当前工作的范围蔓延。我发现，在我很多“代理式”工程工作中，特别难以避免这种范围蔓延。因为我不必自己写所有代码，所以很容易就想做一个 10,000 行的 pull request，一次性搞定所有我想做的事情！这其实只是一种新形式的拖延，哈哈。

所以，我没有为自己创建一个巨大的 pull request 来测试，而是把它拆分成一个新会话，并提示：

让我们为现有的工作创建一个 pull request，然后为这个 react-bootstrap 替换工作启动一个新会话，它将从现有的工作这里分支出来，并作为一个单独的 pull request，在这个之后合并到 dev。

这就是让我觉得神奇到想写这篇博客的部分。GitHub Copilot 应用：

• 为我当前所有基于 dev 的更改创建了一个 pull request
• 为移除 react-bootstrap 创建了一个“堆叠会话”（它获取了之前的上下文，创建了一个在现有会话之后运行的会话，制定了一个计划，让我批准计划，然后运行）
• 在我现有工作之后创建了一个堆叠的 pull request

这太酷了。堆叠会话和堆叠 pull request？这就是未来吗？是的。

如果你不明白这个名字的含义：堆叠（stack）是同一个仓库中的一系列 pull request，每个 pull request 的目标是它下面那个 pull request 的分支，形成一个有序的链条，最终合并到你的 main 分支。在我的例子中，不仅会话是相互衔接的，它们的更改也是！

第五步：带着堆叠 pull request 驶向夕阳

我知道我的兴奋有点得意忘形，但我的快乐是真诚的。在忽视我的旧代码库这么久之后，如此轻松地交付这些更改是一种愉快的体验。让我们再看一下第一张截图：

我来给你解释一下。最上面，你可以看到我拉取的仓库。接下来，“Frontend modernization”是初始会话名称。嵌套在下一层的是第一次尝试创建的 pull request，我们最终没有交付（所以是红色图标）。同一层级嵌套的下一层是我们为 dev 分支创建的一个可用的 pull request。再下面嵌套的会话是正在进行的草稿 pull request，包含了 react-bootstrap 的更改。

软件开发从来都不是一帆风顺的。但有了这些现代工具，这个项目变得容易多了。如果你想现代化你自己的代码库，试试这个吧！在 GitHub 上任何你提交代码的地方查看 pull request 堆叠，以及在 GitHub Copilot 应用中的堆叠会话。

这篇文章《Stacked sessions and pull requests in the GitHub Copilot app》最初出现在 GitHub 博客上。