Zed 发布补丁实践script/cherry-pick 脚本、cherry_pick 工作流与 preview/stable 分支的手动 Cherry-Pick 流程【免费下载链接】zedCode at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.项目地址: https://gitcode.com/GitHub_Trending/ze/zedZed 的main分支上合并的修复最终需要落到preview与stable两条长期维护的发布分支上。本篇以仓库中的 runbook 文档 .agents/skills/zed-cherry-pick/SKILL.md 为主体结合 cherry-pick 脚本 与 cherry_pick 工作流 的源码级实现完整讲解如何在自动化的 GitHub Actions 工作流失败几乎总是合并冲突时在本地手工完成 cherry-pick 并开出一个与自动化产物不可区分的 PR——读完你能掌握通道到分支的映射查询、冲突判定与解决准则、验证与收尾的全部操作。1. 发布模型两条长期分支与绝不硬编码的通道映射Zed 从位于origin的两条长期发布分支出货runbook 原文表述preview通道 → 形如v1.4.x的分支stable通道 → 形如v1.3.x的分支版本号随每次发布变化因此绝不能硬编码通道与分支的映射必须按当前仓库状态动态发现见第 3 节。这一分支名即vX.Y.x的约定可以从版本提升流程得到印证bump_zed_version 工作流 中明确计算preview_branchv${major}.${minor}.x从当前main切出新 preview 分支并通过script/get-released-version preview反查已发布的 preview 版本来推导stable_branchv${stable_major}.${stable_minor}.x。同时 release_channel 定义 中通道取值为stable | dev | nightly | preview四种可见preview/stable是通道channel概念而非分支名——这正是后文陷阱一节强调git fetch origin preview会失败的原因。2. 自动化基线读懂 script/cherry-pick 脚本runbook 明确指出规范流程住在 script/cherry-pick 与cherry_pick工作流里如果任何地方看起来不对劲先读脚本——你的本地步骤必须产出与它相同的分支名、PR 标题和 PR 正文。脚本签名script/cherry-pick branch-name commit-sha channelbranch-name是发布分支如v1.4.x不是通道名channel是preview或stable仅用于 PR 标题/正文中的展示文本。对照脚本源码script/cherry-pick全文仅 34 行其完整行为如下步骤源码行为说明参数校验set -euxo pipefail 参数数检查L2-L7任一命令失败立即退出且逐行回显命令便于定位失败点构造分支名SHORT_SHA${COMMIT_SHA:0:8}NEW_BRANCHcherry-pick-${BRANCH_NAME}-${SHORT_SHA}L13-L14短 SHA 取提交前 8 个字符分支名必须严格遵循cherry-pick-branch-name-short-sha约定拉取git fetch --depth 2 origin ${COMMIT_SHA} ${BRANCH_NAME}L15从源码结构看--depth 2浅拉取提交及其父提交为 cherry-pick 提供完整 diff 上下文建本地分支git checkout --force origin/$BRANCH_NAME -B $NEW_BRANCHL16以发布分支远端引用为基线强制重建本地分支拣选git cherry-pick $COMMIT_SHAL18冲突时在此中止推送git push origin -f $NEW_BRANCHL20强制推送生成 PR 文本提取%s/%b正则匹配标题尾部(#数字)L21-L30见下文标题/正文格式开 PRgh pr create --base ... --head ... --title ... --body ...L33使用 GitHub App tokenPR 标题脚本 L33 与 runbook 一致original commit subject (cherry-pick to channel)原始提交的主题通常已以(#original_pr_number)结尾如 squash merge 的提交这一后缀必须保留。PR 正文runbook 描述的是正常情况原始提交标题以(#N)结尾Cherry-pick of #original_pr_number to channel ---- original commit body, verbatim脚本源码还揭示了 runbook 未展开的兜底分支script/cherry-pick若标题不以(#N)结尾如直接拣选裸提交正文首行退化为Cherry-pick of commit-sha to channel其余格式不变。3. cherry_pick 工作流与通道-分支映射的现查现用3.1 工作流长什么样cherry_pick.yml 是手动触发workflow_dispatch的工作流接收四个必填字符串输入commit、branch、channel、pr_number。其执行链为见 cherry_pick.ymlsteps::authenticate_as_zippy—— 通过actions/create-github-app-token为机器人zed-zippy[bot]生成 token授予 contents/workflows/pull-requests 三项写权限steps::checkout_repo—— 使用上述 token 检出仓库cherry_pick::run_cherry_pick::cherry_pick—— 执行./script/cherry-pick $BRANCH $COMMIT $CHANNEL其中BRANCH/COMMIT/CHANNEL三个环境变量直接来自工作流输入L46-L51提交者身份被固定为 zed-zippy[bot]L52-L55。该文件头两行注明Generated from xtask::workflows::cherry_pick即它是代码生成的产物生成器位于 tooling/xtask/src/tasks/workflows/cherry_pick.rs可用cargo xtask workflows重建。pr_number输入只用于 run-name 展示cherry_pick to ${{ inputs.channel }} #${{ inputs.pr_number }}并不参与脚本执行。3.2 现查通道→分支的当前映射runbook 给出的标准做法是检查最近的cherry_pick工作流运行记录gh run list --workflowcherry_pick.yml --limit 30 --json displayTitle,databaseId # pick a recent run for the channel you want, then: gh run view id --log 21 | grep -E BRANCH:|CHANNEL:一次成功的运行会在日志中打印BRANCH:与CHANNEL:两个环境变量这就是当前的通道→分支映射。4. 手动完成 Cherry-Pick 的标准流程4.1 第一步收集上下文需要三要素merge 提交 SHA、目标分支、通道名。用户给出多个 PR/提交时先收集齐全部元数据再按它们落到main的先后顺序旧到新依次拣选PR 按mergedAt排序裸提交按其在main上的顺序不可得时按提交日期。runbook 的解释是后续改动可能依赖前序改动按序拣选可减少不必要的冲突但当发布分支已分叉时并不保证无冲突。gh pr view PR_NUMBER --json title,number,mergeCommit,mergedAt,url用户提到工作流失败了时拉取失败日志看清究竟哪条命令失败、哪个文件冲突gh run list --workflowcherry_pick.yml --limit 10 --json databaseId,displayTitle,status,conclusion gh run view failed_run_id --log-failed失败日志还会顺带确认工作流实际使用的BRANCH与COMMIT——存在歧义时这是可靠依据对应上文工作流中BRANCH/COMMIT/CHANNEL环境变量的回显。4.2 第二步本地复现脚本的准备工作仓库目录可能是 git worktree检查.git若它是一个文件说明当前是 worktree指向共享的 gitdir。这没有问题照常操作即可。git --no-pager fetch origin branch-name commit-sha git checkout --force origin/branch-name -B cherry-pick-branch-name-short-sha git cherry-pick commit-sha分支名必须与cherry-pick-branch-name-short-sha完全一致脚本约定评审人与工具链都依赖它。这三条命令与 script/cherry-pick 中的fetch/checkout/cherry-pick一一对应差异仅在于本地场景不需要--depth 2。4.3 第三步先查缺失的前置 cherry-pick不要急着手工解冲突runbook 在此设置了一个关键闸门cherry-pick 若冲突不要立即手工解决。先判断冲突是否很可能由main上已存在、但发布分支缺失的其他 PR/提交引起。若是向用户指出这些候选前置 PR/提交附 PR 链接并给出两个选项手工解决冲突或先让 GitHub cherry-pick 工作流把这些前置提交拣过去。若用户选择先跑工作流补齐前置到此停止——这往往能让后续 cherry-pick 保持干净、并有资格获得自动批准automated approval。只有满足以下其一才进入手工解决未发现可能存在缺失的前置或用户明确选择手工解决而非先拣选前置。4.4 第四步手工解决冲突仅在完成前置检查后进行。runbook 的准则用grep -n \|\| path定位每个冲突文件中的标记冲突通常是diff3风格含三段HEAD发布分支侧、||||||| parent of sha在main上的合并基、以及传入的改动先读原始提交git --no-pager show commit-sha -- path理解作者意图然后选择一种能在发布分支上产出等价终态的解法不要顺手把main上恰好位于冲突区旁边的无关改动一并带进来——保持 cherry-pick 最小化。4.5 第五步验证在继续 cherry-pick 之前必须构建在合理时并测试受影响的 cratecargo check -p affected_crate cargo test -p affected_crate验证失败就修解决方案绝不让构建处于破损状态继续。如果无法达到干净状态用git cherry-pick --abort中止并向用户回报。4.6 第六步完成 cherry-pickgit cherry-pick --continue默认会打开编辑器非交互环境下必须屏蔽git add resolved_files GIT_EDITORtrue git cherry-pick --continue这样做会逐字保留原始提交信息——与脚本的行为一致。4.7 第七步推送并创建 PRgit push origin -f cherry-pick-branch-name-short-sha然后用gh pr create创建 PR标题与正文格式必须与 script/cherry-pick 的产物完全一致使手动 PR 与自动化 PR 不可区分标题commit subject (cherry-pick to channel)原始主题的(#N)后缀保留正文原始提交标题以(#N)结尾的正常情形Cherry-pick of #original_pr_number to channel ---- original commit body, verbatimrunbook 建议把正文写入临时文件以保持格式git --no-pager log -1 --prettyformat:%b /tmp/cp-body-tail.md printf Cherry-pick of #%s to %s\n\n----\n PR_NUMBER channel | cat - /tmp/cp-body-tail.md /tmp/cp-body.md gh pr create --base branch-name --head cherry-pick-branch-name-short-sha \ --title commit subject (cherry-pick to channel) \ --body-file /tmp/cp-body.md两条明确的不要做不要添加Release Notes:段——原始提交正文里已经有一个或已写N/A重复添加会造成冗余标题不匹配(#N)时正文首行使用Cherry-pick of commit-sha to channel脚本 L28-L30 的兜底行为。5. 收尾给用户的最终报告runbook 规定完成后必须向用户交代四件事新 PR 的 URLWhen Finished一节强调最后一步永远是给出已开 PR 的链接冲突及解决方式的一句话总结运行了哪些验证命令 结果本地分支当前停在cherry-pick-branch-name-short-sha上以便用户需要时切回。6. 常见陷阱Gotchasrunbook 单独列出四条全部有明确的工程原因--no-pager与GIT_EDITORtrue本环境中非交互 git 的硬性要求cherry-pick --continue漏掉GIT_EDITORtrue会挂起终端。worktree 的索引锁若前一条 git 命令被中断可能遇到index.lock错误worktree 场景下锁位于gitdir/index.lockgitdir是cat .git所指向的路径。仅确认没有 git 进程在运行时才可删除。不要扩大 cherry-pick 的范围解冲突时绝不因为无关改动恰好位于冲突区旁边就从main把它们拉进来。PR 应当是在发布分支上复现原始提交意图的最小 diff。通道分支不叫preview/stable不要尝试git fetch origin preview先查出真实的vX.Y.x分支名再操作。7. 相关文件速查文件作用.agents/skills/zed-cherry-pick/SKILL.md本 runbook 的原始文档何时使用、七步流程、陷阱清单script/cherry-pick规范脚本分支命名、拣选、强推、PR 标题/正文生成.github/workflows/cherry_pick.yml自动化工作流四个输入、zippy 鉴权、脚本调用与环境变量tooling/xtask/src/tasks/workflows/cherry_pick.rs工作流的 xtask 生成器cargo xtask workflows重建.github/workflows/bump_zed_version.yml版本提升流程展示vX.Y.x分支名的派生规则crates/release_channel/src/lib.rs通道枚举定义stable / dev / nightly / preview适用前提说明上述流程依赖仓库具备可用的ghCLI 与对origin的写权限且目标仓库启用 GitHub Appzed-zippy[bot]自动化对于仅本地查看的镜像仓库本文档的价值在于理解发布分支的补丁规范与分支/PR 命名约定所有命令均可照原文复制执行。【免费下载链接】zedCode at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.项目地址: https://gitcode.com/GitHub_Trending/ze/zed创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Zed 发布补丁实践：script/cherry-pick 脚本、cherry_pick 工作流与 preview/stable 分支的手动 Cherry-Pick 流程
Zed 发布补丁实践script/cherry-pick 脚本、cherry_pick 工作流与 preview/stable 分支的手动 Cherry-Pick 流程【免费下载链接】zedCode at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.项目地址: https://gitcode.com/GitHub_Trending/ze/zedZed 的main分支上合并的修复最终需要落到preview与stable两条长期维护的发布分支上。本篇以仓库中的 runbook 文档 .agents/skills/zed-cherry-pick/SKILL.md 为主体结合 cherry-pick 脚本 与 cherry_pick 工作流 的源码级实现完整讲解如何在自动化的 GitHub Actions 工作流失败几乎总是合并冲突时在本地手工完成 cherry-pick 并开出一个与自动化产物不可区分的 PR——读完你能掌握通道到分支的映射查询、冲突判定与解决准则、验证与收尾的全部操作。1. 发布模型两条长期分支与绝不硬编码的通道映射Zed 从位于origin的两条长期发布分支出货runbook 原文表述preview通道 → 形如v1.4.x的分支stable通道 → 形如v1.3.x的分支版本号随每次发布变化因此绝不能硬编码通道与分支的映射必须按当前仓库状态动态发现见第 3 节。这一分支名即vX.Y.x的约定可以从版本提升流程得到印证bump_zed_version 工作流 中明确计算preview_branchv${major}.${minor}.x从当前main切出新 preview 分支并通过script/get-released-version preview反查已发布的 preview 版本来推导stable_branchv${stable_major}.${stable_minor}.x。同时 release_channel 定义 中通道取值为stable | dev | nightly | preview四种可见preview/stable是通道channel概念而非分支名——这正是后文陷阱一节强调git fetch origin preview会失败的原因。2. 自动化基线读懂 script/cherry-pick 脚本runbook 明确指出规范流程住在 script/cherry-pick 与cherry_pick工作流里如果任何地方看起来不对劲先读脚本——你的本地步骤必须产出与它相同的分支名、PR 标题和 PR 正文。脚本签名script/cherry-pick branch-name commit-sha channelbranch-name是发布分支如v1.4.x不是通道名channel是preview或stable仅用于 PR 标题/正文中的展示文本。对照脚本源码script/cherry-pick全文仅 34 行其完整行为如下步骤源码行为说明参数校验set -euxo pipefail 参数数检查L2-L7任一命令失败立即退出且逐行回显命令便于定位失败点构造分支名SHORT_SHA${COMMIT_SHA:0:8}NEW_BRANCHcherry-pick-${BRANCH_NAME}-${SHORT_SHA}L13-L14短 SHA 取提交前 8 个字符分支名必须严格遵循cherry-pick-branch-name-short-sha约定拉取git fetch --depth 2 origin ${COMMIT_SHA} ${BRANCH_NAME}L15从源码结构看--depth 2浅拉取提交及其父提交为 cherry-pick 提供完整 diff 上下文建本地分支git checkout --force origin/$BRANCH_NAME -B $NEW_BRANCHL16以发布分支远端引用为基线强制重建本地分支拣选git cherry-pick $COMMIT_SHAL18冲突时在此中止推送git push origin -f $NEW_BRANCHL20强制推送生成 PR 文本提取%s/%b正则匹配标题尾部(#数字)L21-L30见下文标题/正文格式开 PRgh pr create --base ... --head ... --title ... --body ...L33使用 GitHub App tokenPR 标题脚本 L33 与 runbook 一致original commit subject (cherry-pick to channel)原始提交的主题通常已以(#original_pr_number)结尾如 squash merge 的提交这一后缀必须保留。PR 正文runbook 描述的是正常情况原始提交标题以(#N)结尾Cherry-pick of #original_pr_number to channel ---- original commit body, verbatim脚本源码还揭示了 runbook 未展开的兜底分支script/cherry-pick若标题不以(#N)结尾如直接拣选裸提交正文首行退化为Cherry-pick of commit-sha to channel其余格式不变。3. cherry_pick 工作流与通道-分支映射的现查现用3.1 工作流长什么样cherry_pick.yml 是手动触发workflow_dispatch的工作流接收四个必填字符串输入commit、branch、channel、pr_number。其执行链为见 cherry_pick.ymlsteps::authenticate_as_zippy—— 通过actions/create-github-app-token为机器人zed-zippy[bot]生成 token授予 contents/workflows/pull-requests 三项写权限steps::checkout_repo—— 使用上述 token 检出仓库cherry_pick::run_cherry_pick::cherry_pick—— 执行./script/cherry-pick $BRANCH $COMMIT $CHANNEL其中BRANCH/COMMIT/CHANNEL三个环境变量直接来自工作流输入L46-L51提交者身份被固定为 zed-zippy[bot]L52-L55。该文件头两行注明Generated from xtask::workflows::cherry_pick即它是代码生成的产物生成器位于 tooling/xtask/src/tasks/workflows/cherry_pick.rs可用cargo xtask workflows重建。pr_number输入只用于 run-name 展示cherry_pick to ${{ inputs.channel }} #${{ inputs.pr_number }}并不参与脚本执行。3.2 现查通道→分支的当前映射runbook 给出的标准做法是检查最近的cherry_pick工作流运行记录gh run list --workflowcherry_pick.yml --limit 30 --json displayTitle,databaseId # pick a recent run for the channel you want, then: gh run view id --log 21 | grep -E BRANCH:|CHANNEL:一次成功的运行会在日志中打印BRANCH:与CHANNEL:两个环境变量这就是当前的通道→分支映射。4. 手动完成 Cherry-Pick 的标准流程4.1 第一步收集上下文需要三要素merge 提交 SHA、目标分支、通道名。用户给出多个 PR/提交时先收集齐全部元数据再按它们落到main的先后顺序旧到新依次拣选PR 按mergedAt排序裸提交按其在main上的顺序不可得时按提交日期。runbook 的解释是后续改动可能依赖前序改动按序拣选可减少不必要的冲突但当发布分支已分叉时并不保证无冲突。gh pr view PR_NUMBER --json title,number,mergeCommit,mergedAt,url用户提到工作流失败了时拉取失败日志看清究竟哪条命令失败、哪个文件冲突gh run list --workflowcherry_pick.yml --limit 10 --json databaseId,displayTitle,status,conclusion gh run view failed_run_id --log-failed失败日志还会顺带确认工作流实际使用的BRANCH与COMMIT——存在歧义时这是可靠依据对应上文工作流中BRANCH/COMMIT/CHANNEL环境变量的回显。4.2 第二步本地复现脚本的准备工作仓库目录可能是 git worktree检查.git若它是一个文件说明当前是 worktree指向共享的 gitdir。这没有问题照常操作即可。git --no-pager fetch origin branch-name commit-sha git checkout --force origin/branch-name -B cherry-pick-branch-name-short-sha git cherry-pick commit-sha分支名必须与cherry-pick-branch-name-short-sha完全一致脚本约定评审人与工具链都依赖它。这三条命令与 script/cherry-pick 中的fetch/checkout/cherry-pick一一对应差异仅在于本地场景不需要--depth 2。4.3 第三步先查缺失的前置 cherry-pick不要急着手工解冲突runbook 在此设置了一个关键闸门cherry-pick 若冲突不要立即手工解决。先判断冲突是否很可能由main上已存在、但发布分支缺失的其他 PR/提交引起。若是向用户指出这些候选前置 PR/提交附 PR 链接并给出两个选项手工解决冲突或先让 GitHub cherry-pick 工作流把这些前置提交拣过去。若用户选择先跑工作流补齐前置到此停止——这往往能让后续 cherry-pick 保持干净、并有资格获得自动批准automated approval。只有满足以下其一才进入手工解决未发现可能存在缺失的前置或用户明确选择手工解决而非先拣选前置。4.4 第四步手工解决冲突仅在完成前置检查后进行。runbook 的准则用grep -n \|\| path定位每个冲突文件中的标记冲突通常是diff3风格含三段HEAD发布分支侧、||||||| parent of sha在main上的合并基、以及传入的改动先读原始提交git --no-pager show commit-sha -- path理解作者意图然后选择一种能在发布分支上产出等价终态的解法不要顺手把main上恰好位于冲突区旁边的无关改动一并带进来——保持 cherry-pick 最小化。4.5 第五步验证在继续 cherry-pick 之前必须构建在合理时并测试受影响的 cratecargo check -p affected_crate cargo test -p affected_crate验证失败就修解决方案绝不让构建处于破损状态继续。如果无法达到干净状态用git cherry-pick --abort中止并向用户回报。4.6 第六步完成 cherry-pickgit cherry-pick --continue默认会打开编辑器非交互环境下必须屏蔽git add resolved_files GIT_EDITORtrue git cherry-pick --continue这样做会逐字保留原始提交信息——与脚本的行为一致。4.7 第七步推送并创建 PRgit push origin -f cherry-pick-branch-name-short-sha然后用gh pr create创建 PR标题与正文格式必须与 script/cherry-pick 的产物完全一致使手动 PR 与自动化 PR 不可区分标题commit subject (cherry-pick to channel)原始主题的(#N)后缀保留正文原始提交标题以(#N)结尾的正常情形Cherry-pick of #original_pr_number to channel ---- original commit body, verbatimrunbook 建议把正文写入临时文件以保持格式git --no-pager log -1 --prettyformat:%b /tmp/cp-body-tail.md printf Cherry-pick of #%s to %s\n\n----\n PR_NUMBER channel | cat - /tmp/cp-body-tail.md /tmp/cp-body.md gh pr create --base branch-name --head cherry-pick-branch-name-short-sha \ --title commit subject (cherry-pick to channel) \ --body-file /tmp/cp-body.md两条明确的不要做不要添加Release Notes:段——原始提交正文里已经有一个或已写N/A重复添加会造成冗余标题不匹配(#N)时正文首行使用Cherry-pick of commit-sha to channel脚本 L28-L30 的兜底行为。5. 收尾给用户的最终报告runbook 规定完成后必须向用户交代四件事新 PR 的 URLWhen Finished一节强调最后一步永远是给出已开 PR 的链接冲突及解决方式的一句话总结运行了哪些验证命令 结果本地分支当前停在cherry-pick-branch-name-short-sha上以便用户需要时切回。6. 常见陷阱Gotchasrunbook 单独列出四条全部有明确的工程原因--no-pager与GIT_EDITORtrue本环境中非交互 git 的硬性要求cherry-pick --continue漏掉GIT_EDITORtrue会挂起终端。worktree 的索引锁若前一条 git 命令被中断可能遇到index.lock错误worktree 场景下锁位于gitdir/index.lockgitdir是cat .git所指向的路径。仅确认没有 git 进程在运行时才可删除。不要扩大 cherry-pick 的范围解冲突时绝不因为无关改动恰好位于冲突区旁边就从main把它们拉进来。PR 应当是在发布分支上复现原始提交意图的最小 diff。通道分支不叫preview/stable不要尝试git fetch origin preview先查出真实的vX.Y.x分支名再操作。7. 相关文件速查文件作用.agents/skills/zed-cherry-pick/SKILL.md本 runbook 的原始文档何时使用、七步流程、陷阱清单script/cherry-pick规范脚本分支命名、拣选、强推、PR 标题/正文生成.github/workflows/cherry_pick.yml自动化工作流四个输入、zippy 鉴权、脚本调用与环境变量tooling/xtask/src/tasks/workflows/cherry_pick.rs工作流的 xtask 生成器cargo xtask workflows重建.github/workflows/bump_zed_version.yml版本提升流程展示vX.Y.x分支名的派生规则crates/release_channel/src/lib.rs通道枚举定义stable / dev / nightly / preview适用前提说明上述流程依赖仓库具备可用的ghCLI 与对origin的写权限且目标仓库启用 GitHub Appzed-zippy[bot]自动化对于仅本地查看的镜像仓库本文档的价值在于理解发布分支的补丁规范与分支/PR 命名约定所有命令均可照原文复制执行。【免费下载链接】zedCode at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.项目地址: https://gitcode.com/GitHub_Trending/ze/zed创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考