github/gh-stack
GitHub: github/gh-stack
一个 GitHub CLI 扩展，用于管理堆叠式分支和 Pull Requests，将大规模变更拆分为链式的小型 PR 以简化代码评审流程。
Stars: 538 | Forks: 24
# GitHub Stacked PRs
一个用于管理 stacked branches 和 pull requests 的 GitHub CLI 扩展。
Stacked PRs 将巨大的变更拆分成一系列相互依赖的、易于评审的小 pull requests。`gh stack` 能够自动完成其中繁琐的操作——创建分支、保持 rebase 状态、设置正确的 PR base 分支，以及在各个层级之间进行导航。
## 安装
```
gh extension install github/gh-stack
```
需要 [GitHub CLI](https://cli.github.com/) (`gh`) v2.0+。
## AI agent 集成
安装 gh-stack skill，这样你的 AI coding agent 就能知道如何处理 stacked PRs 以及 `gh stack` CLI：
```
gh skill install github/gh-stack
```
## 快速开始
```
# Start a new stack (creates and checks out the first branch)
gh stack init
# ... make commits on the first branch ...
# Add another branch on top
gh stack add api-endpoints
# ... make commits ...
# Push all branches
gh stack push
# View the stack
gh stack view
# Open a stack of PRs
gh stack submit
```
## 工作原理
**Stack** 是一个有序的分支列表，其中每个分支都建立在它的下一个分支之上。Stack 的**底部**基于一个 **trunk** 分支（通常是 `main`）。
```
frontend → PR #3 (base: api-endpoints) ← top
api-endpoints → PR #2 (base: auth-layer)
auth-layer → PR #1 (base: main) ← bottom
─────────────
main (trunk)
```
Stack 的**底部**是距离 trunk 最近的分支，而**顶部**是距离 trunk 最远的分支。每个分支都继承自其下方的分支。导航命令（`up`、`down`、`top`、`bottom`）遵循此模型：`up` 表示远离 trunk，`down` 表示靠近 trunk。
当你提交时，`gh stack` 会为每个分支创建一个 PR，并将它们作为 GitHub 上的一个 **Stack** 关联起来。每个 PR 的 base 都设置为 stack 中其下方的分支，这样评审者就只能看到该层级的 diff。
### 本地跟踪
Stack 的元数据存储在 `.git/gh-stack` 中（这是一个 JSON 文件，不会提交到 repo 中）。它记录了哪些分支属于哪个 stack 以及它们的排序。在中断的 rebase 过程中，rebase 状态会单独存储在 `.git/gh-stack-rebase-state` 中。
## 命令
### `gh stack init`
在当前 repository 中初始化一个新的 stack。
```
gh stack init [flags] [branches...]
```
在本地初始化一个新的 stack。在交互模式下（不提供参数时），会提示输入分支名称，并提供选项将当前分支作为第一层。
当提供明确的分支名称时，会自动采用现有的分支，并创建任何缺失的分支。除非使用 `--base` 覆盖，否则 trunk 默认为 repository 的默认分支。
会自动启用 `git rerere`，以便在多次 rebase 过程中记住冲突的解决方案。
| 标志 | 描述 |
|------|-------------|
| `-b, --base ` | Stack 的 trunk 分支（默认为 repository 的默认分支） |
**示例：**
```
# Interactive — prompts for branch names
gh stack init
# Non-interactive — specify branches upfront
gh stack init feature-auth feature-api feature-ui
# Use a different trunk branch
gh stack init --base develop feature-auth
# Adopt existing branches into a stack
gh stack init feature-auth feature-api
```
### `gh stack add`
在当前 stack 的顶部添加一个新分支。
```
gh stack add [flags] [branch]
```
在当前 HEAD 处创建一个新分支，将其添加到 stack 的顶部，并将其检出。必须在 stack 的最顶层分支上运行。如果未提供分支名称，则会提示输入。
你可以选择暂存更改，并作为 `add` 流程的一部分创建一个 commit。当提供 `-m` 但未提供明确的分支名称时，分支名称将以日期+slug 格式自动生成（例如：`03-24-add_login`）。
| 标志 | 描述 |
|------|-------------|
| `-A, --all` | 暂存所有更改（包括未跟踪的文件）；需要配合 `-m` |
| `-u, --update` | 仅暂存已跟踪文件的更改；需要配合 `-m` |
| `-m, --message ` | 在创建分支前使用该信息创建一个 commit |
**示例：**
```
# Create a branch by name
gh stack add api-routes
# Prompt for a branch name interactively
gh stack add
# Stage all changes, commit, and auto-generate the branch name
gh stack add -Am "Add login endpoint"
# Stage only tracked files, commit, and auto-generate the branch name
gh stack add -um "Fix auth bug"
# Commit already-staged changes and auto-generate the branch name
gh stack add -m "Add user model"
# Stage all changes, commit, and use an explicit branch name
gh stack add -Am "Add tests" test-layer
# Stage only tracked files, commit, and use an explicit branch name
gh stack add -um "Update docs" docs-layer
# Commit already-staged changes and use an explicit branch name
gh stack add -m "Refactor utils" cleanup-layer
```
### `gh stack checkout`
通过 stack 编号、pull request 编号、PR URL 或分支名称检出 stack。
```
gh stack checkout [ | | | ]
```
纯数字会首先被解释为 stack 或 PR 编号（在 GitHub UI 中显示的 repo 范围内的标识符）。如果没有匹配的编号，则会尝试将其作为分支名称。
当引用远程的 stack 时，该命令会获取 GitHub 上的 stack，拉取分支，并在本地设置 stack。如果该 stack 已在本地存在且匹配，则会切换到该分支。如果本地和远程的 stack 组成不同，系统会提示你解决冲突。
当提供分支名称时，该命令仅针对本地跟踪的 stack 进行解析。
在没有参数且处于交互式终端的情况下运行时，会打开一个可搜索的选择器，列出你可用的所有 stack——包括本地跟踪的 stack 和仅存在于 GitHub 上的 stack。每一行显示 stack 编号、其底部和顶部分支、base 分支、一个状态条（汇总了已合并、已开启、已关闭或尚未推送的 pull request 数量），以及该 stack 是在本地可用还是仅在远程可用。使用 All / Local / Remote 选项卡进行过滤，或输入 `/` 进行搜索；完全合并的 stack 会被忽略。选择仅存在于远程的 stack 会先将其在本地克隆，然后再切换。
**示例：**
```
# Check out a stack by its stack number
gh stack checkout 7
# Check out a stack by PR number
gh stack checkout 42
# Check out a stack by PR URL
gh stack checkout https://github.com/owner/repo/pull/42
# Check out a stack by branch name (local only)
gh stack checkout feature-auth
# Interactive — pick from all available stacks (local and remote)
gh stack checkout
```
### `gh stack rebase`
从远程拉取并在整个 stack 中执行级联 rebase。
```
gh stack rebase [flags] [branch]
```
从 `origin` 获取最新更改，然后确保 stack 中的每个分支的提交历史中都包含上一层的 tip。按从 trunk 向上的顺序对分支进行 rebase。如果分支的 PR 已被合并，rebase 会自动切换到 `--onto` 模式，以便在合并目标之上正确地重放 commit。
如果发生 rebase 冲突，操作会暂停并打印出带有行号的冲突文件。解决冲突后，使用 `git add` 暂存，并使用 `--continue` 继续。要撤销整个 rebase，请使用 `--abort` 将所有分支恢复到 rebase 前的状态。
| 标志 | 描述 |
|------|-------------|
| `--downstack` | 仅对从 trunk 到当前分支的分支进行 rebase |
| `--upstack` | 仅对从当前分支到顶部的分支进行 rebase |
| `--no-trunk` | 跳过 trunk —— 仅对 stack 中的各个分支相互进行 rebase（不执行 fetch，不对 trunk 进行 rebase） |
| `--continue` | 解决冲突后继续 rebase |
| `--abort` | 中止 rebase 并将所有分支恢复到 rebase 前的状态 |
| `--remote ` | 要从中获取的远程仓库（默认为自动检测到的 remote） |
| `--committer-date-is-author-date` | 在 rebase 期间将 committer 日期设置为 author 日期。别名：`--preserve-dates` |
| 参数 | 描述 |
|----------|-------------|
| `[branch]` | 目标分支（默认为当前分支） |
**示例：**
```
# Rebase the entire stack
gh stack rebase
# Only rebase branches below the current one
gh stack rebase --downstack
# Only rebase branches above the current one
gh stack rebase --upstack
# Rebase stack branches without pulling from or rebasing with trunk
gh stack rebase --no-trunk
# After resolving a conflict
gh stack rebase --continue
# Abort rebase and restore everything
gh stack rebase --abort
# Rebase and preserve committer date as author date
gh stack rebase --committer-date-is-author-date
```
### `gh stack modify`
交互式地重构当前的 stack。
```
gh stack modify [flags]
```
打开一个用于重构 stack 的终端 UI。你可以删除、折叠、插入、重命名和重新排序分支。在预览期间，所有的更改都会被暂存，并在保存时一次性应用。
如果 PR stack 已经在 GitHub 上创建，请随后运行 `gh stack submit` 来推送更改并重新创建 stack。
| 标志 | 描述 |
|------|-------------|
| `--continue` | 解决冲突后继续 |
| `--abort` | 中止修改会话并将 stack 恢复到修改前的状态 |
**操作：**
- **删除** (`x`)：从 stack 中移除分支及其 commit。保留本地分支和关联的 PR。
- **向下折叠** (`d`)：将分支的 commit 合并到其下方的分支中（靠近 trunk）。被折叠的分支会从 stack 中移除。
- **向上折叠** (`u`)：将分支的 commit 合并到其上方的分支中（远离 trunk）。被折叠的分支会从 stack 中移除。
- **插入** (`i`/`I`)：在 stack 中插入一个新的空分支。`i` 在光标下方插入；`I` 在光标上方插入。
- **重排序** (`Shift+↑`/`Shift+↓`)：在 stack 中向上（远离 trunk）或向下（靠近 trunk）移动分支。
- **重命名** (`r`)：在本地和 stack 元数据中重命名分支。
- **撤销** (`z`)：撤销上一个暂存的操作。
**快捷键：**
| 按键 | 操作 |
|-----|--------|
| `↑`/`↓` | 导航分支列表 |
| `f` | 查看更改的文件 |
| `c` | 查看 commit |
| `x` | 删除分支 |
| `r` | 重命名分支 |
| `i/I` | 在下方/上方插入分支 |
| `d/u` | 向下/向上折叠分支 |
| `Shift+↑`/`Shift+↓` | 向上/向下移动分支 |
| `z` | 撤销上一个操作 |
| `Ctrl+S` | 应用所有更改 |
| `q`/`Esc` | 取消并退出 |
| `?` | 帮助 |
**前置条件：**
- 必须在本地检出一个活跃的 stack
- 工作树必须是干净的
- 没有正在进行的 rebase
- Stack 中没有排队等待合并的 PR
- Commit 历史必须是线性的
**示例：**
```
# Open the modify TUI
gh stack modify
# Continue after resolving a conflict
gh stack modify --continue
# Abort and restore to the previous state
gh stack modify --abort
```
### `gh stack sync`
在单个命令中执行获取、rebase、推送以及同步 PR 状态。
```
gh stack sync [flags]
```
对整个 stack 执行同步：
1. **获取** —— 从 `origin` 获取最新更改。
2. **协调远程 stack** —— 在本地镜像 GitHub stack。当 PR 在 GitHub 上被添加到 stack 时（远程领先于你的本地 stack），它们的分支会被拉取下来并自动追加到你的本地 stack 中。当本地和远程 stack 确实产生了分歧（例如，你在本地添加了一个分支，而在 GitHub 上有不同的 PR 被添加到该 stack 时），系统会提示你进行解决（参见下方的[产生分歧的 stack](#diverged-stacks)）。在非交互式终端中，出现分歧会中止同步（不会推送或更新任何内容）。
3. **快进 trunk** —— 将 trunk 分支快进以匹配远程仓库（如果产生分歧则跳过）。
4. **级联 rebase** —— 将所有 stack 分支 rebase 到其更新后的父分支上（仅当 trunk 移动时）。如果检测到冲突，所有分支都会恢复到原始状态，系统会建议你运行 `gh stack rebase` 以交互方式解决冲突。
5. **推送** —— 推送所有分支（如果发生了 rebase，则使用 `--force-with-lease`）。
6. **同步 PR** —— 从 GitHub 同步 PR 状态并报告每个 PR 的状态。
7. **同步 stack** —— 将 stack 中处于开启状态的 PR 链接为 GitHub 上的一个 stack，如果远程 stack 对象尚不存在则创建它，如果其仅部分形成则更新它。此操作仅在存在两个或更多 PR 时发生；同步操作永远不会开启 PR（请使用 `gh stack submit` 完成此操作）。
8. **清理** —— 在交互式终端中，会提示删除已合并 PR 的本地分支。使用 `--prune` 可自动进行清理。
一个纯净的远程领先更新（在你本地 stack 之上添加了 PR）会自动拉取下来而不会进行提示，因此在自动化环境中运行 `sync` 是安全的。只有当 stack 确实产生分歧时，同步才会进行提示。
#### 产生分歧的 stack
当两个 stack 都不是对方的纯粹前缀时——例如，你在本地添加了一个分支，而在 GitHub 上同一个 stack 中又添加了不同的 PR——同步就无法自动合并两者。在交互式终端中，它提供三种选择：
- **将远程 stack 视为事实来源** —— 使用远程 stack 替换你本地的 stack 组成，并拉取所有缺失的分支。如果你所在的分支不再包含在远程 stack 中，你将被移动到最近的可用分支。要求具有干净的工作状态且没有未提交的更改。
- **删除 GitHub 上的 stack** —— 删除 GitHub 上的 stack 对象并停止同步。你的 PR 和本地分支将不受影响（仅移除了 GitHub 上的 stack）；使用 `gh stack submit` 重新创建 stack（如果你想更改其结构，请先运行 `gh stack modify`）。这是让 GitHub 匹配你本地 stack 的方法，因为与 `sync` 不同，`submit` 还会为你尚未提交的分支创建 PR。
- **取消** —— 中止同步，既不推送分支，也不更新任何 PR。
在非交互式终端中，出现分歧会中止同步（成功退出），既不会推送分支也不会更新 PR；你可以通过退出 stack 并重新创建来解决这个问题。
| 标志 | 描述 |
|------|-------------|
| `--remote ` | 要从中获取并推送到的远程仓库（默认为自动检测到的 remote） |
| `--prune` | 删除已合并 PR 的本地分支 |
**示例：**
```
gh stack sync
# Sync and automatically prune merged branches
gh stack sync --prune
```
### `gh stack push`
将当前 stack 中的所有分支推送到远程仓库。
```
gh stack push [flags]
```
使用 `--force-with-lease --atomic` 将每个分支推送到远程仓库。这是一个围绕 `git push` 的轻量级封装，它了解 stack 中的所有分支。它不会创建或更新 pull requests——请使用 `gh stack submit` 完成该操作。
| 标志 | 描述 |
|------||
| `--remote ` | 要推送到的远程仓库（默认为自动检测到的 remote） |
**示例：**
```
gh stack push
gh stack push --remote upstream
```
### `gh stack submit`
推送所有分支，并在 GitHub 上创建/更新 PR 和 stack。
```
gh stack submit [flags]
```
为 stack 中的每个分支创建一个 Stacked PR，并将分支推送到远程仓库。
创建 PR 后，`submit` 会自动在 GitHub 上创建一个 **Stack** 将这些 PR 链接起来。如果该 stack 已经存在于 GitHub 上（例如之前提交过），新的 PR 将被添加到 stack 的顶部。
如果 stack 中的每个 PR 都已经合并，则该 stack 已完成且无法扩展——在顶部的新 PR 将直接定位到 trunk，而不是链接到已合并的 PR 上。在这种情况下，`submit` 会自动为未合并的分支在 trunk 处启动一个**新**的 stack 并在 GitHub 上创建它，而不会改动已合并的 stack。
在交互式终端中，`submit` 会在单个屏幕上打开一个全屏的、支持鼠标和键盘操作的编辑器。默认情况下，每个没有 PR 的分支都会被包含在内——在左侧面板取消选择任何你不需要的分支（Ctrl+X）。因为每个 PR 都建立在它下方分支的基础上，所以取消选择某个分支也会取消选择堆叠在其上方的分支，而重新包含某个分支也会重新包含其下方的分支。在右侧为每个 PR 起草标题、描述（支持 markdown 预览和 `$EDITOR` 转义），并选择准备好接受评审还是草稿，然后通过 Ctrl+S 一次性提交它们。传递 `--auto`（或在 CI 中运行）可跳过编辑器并使用自动生成的标题。
如果分支已经有开启的 PR，但 GitHub 上不存在 stack，你可以选择通过 Ctrl+B 将这些 PR 链接到一个 stack 中。
在编辑器中，新的 PR 默认为准备好接受评审；可以使用 ready ↔ draft 切换开关将任何 PR 切换为草稿。使用 `--auto` 时，除非你传递 `--open`，否则新 PR 将作为草稿创建。
| 标志 | 描述 |
|------|-------------|
| `--auto` | 跳过编辑器并使用自动生成的 PR 标题 |
| `--open` | 将新的和现有的 PR 标记为准备好接受评审 |
| `--remote ` | 要推送到的远程仓库（默认为自动检测到的 remote） |
**示例：**
```
gh stack submit
gh stack submit --auto
gh stack submit --open
```
### `gh stack link`
在 GitHub 上将 PR 链接到一个 stack，而无需进行本地跟踪。
```
gh stack link [flags] [...]
```
根据分支名称或 PR 编号/URL 在 GitHub 上创建或更新一个 stack。此命令不会存储或修改任何 `gh stack` 本地跟踪状态。它专为那些在本地使用其他工具（例如 jj、Sapling、git-town）管理分支，且只想简单地开启一个 PR stack 的用户而设计。
参数按 stack 顺序（从下到上）提供。在创建或查找 PR 之前，分支参数会被自动推送到远程仓库。对于已经有开启 PR 的分支，将直接使用这些 PR。对于没有 PR 的分支，会自动使用正确的 base 分支链接创建新的 PR。如果现有 PR 的 base 分支与预期的链接不匹配，系统会自动对其进行修正。
如果 PR 尚未处于一个 stack 中，则会创建一个新的 stack。如果其中一些 PR 已经在某个 stack 中，则会更新现有的 stack 以包含这些新的 PR。现有的 PR 永远不会从 stack 中被移除——此更新仅是增量添加。
| 标志 | 描述 |
|------|-------------|
| `--base ` | Stack 底部的 base 分支（默认：`main`） |
| `--open` | 将新的和现有的 PR 标记为准备好接受评审 |
| `--remote ` | 要推送到的远程仓库（默认为自动检测到的 remote） |
**示例：**
```
# Link branches into a stack (pushes branches, creates PRs, creates stack)
gh stack link feature-auth feature-api feature-ui
# Link existing PRs by number
gh stack link 10 20 30
# Link existing PRs by URL
gh stack link https://github.com/owner/repo/pull/10 https://github.com/owner/repo/pull/20
# Add branches to an existing stack of PRs
gh stack link 42 43 feature-auth feature-ui
# Use a different base branch and mark PRs as ready for review
gh stack link --base develop --open feat-a feat-b feat-c
```
### `gh stack view`
查看当前的 stack。
```
gh stack view [flags]
```
显示 stack 中的所有分支、它们的顺序、PR 链接以及带有相对时间戳的最近一次 commit。输出将通过分页器进行管道传输（遵循 `GIT_PAGER`、`PAGER`，或默认使用 `less -R`）。
| 标志 | 描述 |
|------|-------------|
| `-s, --short` | 紧凑输出（仅显示分支名称） |
| `--json` | 以 JSON 格式输出 stack 数据 |
**示例：**
```
gh stack view
gh stack view --short
gh stack view --json
```
### `gh stack unstack`
从本地跟踪中移除某个 stack，并在 GitHub 上取消其堆叠。也可通过 `gh stack delete` 使用。
```
gh stack unstack [] [flags]
```
在不提供参数的情况下，该命令的目标是当前活跃的 stack——即包含当前检出分支的那个 stack——它会在 GitHub 上取消其堆叠并移除本地跟踪。
提供 stack 编号（在 github.com stack UI 中显示的标识符）可在 GitHub 上取消堆叠特定的 stack。无论该 stack 是否在本地检出，此操作都可以在 repository 中的任何位置执行——编号会直接通过 GitHub API 进行处理。如果该 stack 也在本地被跟踪，其本地跟踪也将被一并移除。
使用 `--local` 可仅移除本地跟踪，而不联系 GitHub。
GitHub 会决定哪些 pull requests 可以被取消堆叠：排队等待合并或启用了自动合并的 PR 将保持堆叠状态。当一些 pull requests 保持堆叠时，该 stack 会被保留（并且本地跟踪（如果有）保持不变）。
| 标志 | 描述 |
|------|-------------|
| `--local` | 仅在本地移除 stack（将其保留在 GitHub 上） |
**示例：**
```
# Remove the current stack from local tracking and GitHub
gh stack unstack
# Unstack a specific stack by its number
gh stack unstack 7
# Only remove local tracking
gh stack unstack --local
```
### 导航
在当前 stack 的各个分支之间移动，无需记住分支名称。
```
gh stack up [n] # Move up n branches (default 1)
gh stack down [n] # Move down n branches (default 1)
gh stack top # Jump to the top of the stack
gh stack bottom # Jump to the bottom of the stack
gh stack trunk # Jump to the trunk branch
gh stack switch # Interactively pick a branch to switch to
```
导航命令会将移动范围限制在 stack 的边界内——从顶部向上移动或从底部向下移动都是无效操作并会显示提示信息。如果你正处于 trunk 分支，`up` 会移动到第一个 stack 分支。
**示例：**
```
gh stack up # move up one layer
gh stack up 3 # move up three layers
gh stack down
gh stack top
gh stack bottom
gh stack trunk # jump to the trunk branch (e.g., main)
gh stack switch # shows an interactive picker
```
### `gh stack feedback`
分享关于 gh-stack 的反馈。
```
gh stack feedback [title]
```
在 [gh-stack repository](https://github.com/github/gh-stack) 中打开一个 GitHub Discussion 来提交反馈。可以选择为该讨论帖子提供一个标题。
**示例：**
```
gh stack feedback
gh stack feedback "Support for reordering branches"
```
### `gh stack alias`
创建一个简短的命令别名，让你可以少打字。
```
gh stack alias [flags] [name]
```
在 `~/.local/bin/` 中安装一个小的封装脚本，将所有参数转发给 `gh stack`。默认的别名是 `gs`，但你也可以通过将其作为参数传递来选择任何名称。设置完成后，你可以运行 `gs push` 而不是 `gh stack push`。
在 Windows 上，不支持自动创建别名——该命令会打印手动说明，指导你创建批处理文件或 PowerShell 函数。
| 标志 | 描述 |
|------|-------------|
| `--remove` | 移除之前创建的别名 |
**示例：**
```
# Create the default alias (gs)
gh stack alias
# → now "gs push", "gs view", etc. all work
# Create a custom alias
gh stack alias gst
# Remove an alias
gh stack alias --remove
gh stack alias gst --remove
```
## 典型工作流
```
# 1. Start a stack (creates and checks out the first branch)
gh stack init
# 2. Work on the first layer
# ... write code, make commits ...
# 3. Add the next layer
gh stack add api-routes
# ... write code, make commits ...
# 4. Push everything and create Stacked PRs
gh stack submit
# 5. Reviewer requests changes on the first PR
gh stack bottom
# ... make changes, commit ...
# 6. Rebase the rest of the stack on top of your fix
gh stack rebase
# 7. Push the updated branches
gh stack push
# 8. When the first PR is merged, sync the stack
gh stack sync
# → prompts to prune merged branches (or use --prune to prune automatically and avoid the prompt)
```
## 简化工作流
如果你想尽量减少击键次数，可以使用 `-Am` 标志将暂存、commit 和分支创建合并到一个命令中。如果你不传递分支名称，系统会根据 commit 信息以日期+slug 格式自动生成一个（例如：`03-24-auth_middleware`）。
当分支还没有任何 commit 时（例如，刚执行完 `init` 之后），`add -Am` 会直接在该分支上进行暂存和 commit，而不是创建一个新分支。一旦分支有了 commit，`add -Am` 就会创建一个新的分支，将其检出并在那里进行 commit。
```
# 1. Start a stack
gh stack init auth
# → creates auth and checks it out
# 2. Write code for the first layer
# ... write code ...
# 3. Stage and commit on the current branch
gh stack add -Am "Auth middleware"
# → auth has no commits yet, so the commit lands here
# (no new branch is created)
# 4. Write code for the next layer
# ... write code ...
# 5. Create the next branch and commit
gh stack add -Am "API routes"
# → auth already has commits, so a new branch is created from the
# commit message, checked out, and the commit lands there
# 6. Keep going
# ... write code ...
gh stack add -Am "Frontend components"
# → creates another branch and commits there
# 7. Push everything and create PRs
gh stack submit
```
与典型工作流相比，无需命名分支，也无需分别运行 `git add` 或 `git commit`。每个 `gh stack add -Am "..."` 都能搞定一切。当你想要控制分支名称时，可以随时传递明确的分支名称：`gh stack add -Am "API routes" api-routes`。
## 终端主题
交互式屏幕（`submit`、`modify` 和 `view`）以及所有彩色的命令输出（状态消息、提示）都会自动调整其颜色以适应你终端的背景，因此在深色和浅色主题下均具有可读性。背景颜色是从终端检测出来的；如果终端未报告其背景（某些 SSH 或 `tmux` 设置），则会使用深色调色板。
如果检测不正确，请设置 `GH_STACK_THEME` 来强制指定调色板：
| 值 | 行为 |
|-------|----------|
| `auto`（默认） | 从终端背景检测 |
| `light` | 强制使用浅色调色板 |
| `dark` | 强制使用深色调色板 |
```
# Force the light palette
export GH_STACK_THEME=light && gh stack view
```
## 退出码
| 代码 | 含义 |
|------|---------|
| 0 | 成功 |
| 1 | 一般性错误 |
| 2 | 不在 stack 中 / 未找到 stack |
| 3 | Rebase 冲突 |
| 4 | GitHub API 故障 |
| 5 | 无效的参数或标志 |
| 6 | 需要消歧（分支属于多个 stack） |
| 7 | Rebase 已经在进行中 |
| 8 | Stack 被另一个进程锁定 |
## 许可证
本项目基于 MIT 开源许可证的条款进行授权。有关完整条款，请参阅 [LICENSE](LICENSE) 文件。
## 维护者
请参阅 [CODEOWNERS](CODEOWNERS)
## 支持
请参阅 [SUPPORT.md](SUPPORT.md)
请注意，Stacked PRs 功能目前处于私有预览阶段，如果不启用该功能，**gh-stack** 将无法工作。
标签：EVTX分析, Git, GitHub CLI 扩展, SOC Prime, 代码审查, 安全可观测性, 开发工具, 日志审计, 版本控制, 网络安全研究, 网络调试, 自动化