前端构建构建工具开发工具【免费下载链接】farmExtremely fast Vite-compatible web build tool written in Rust项目地址https://gitcode.com/gh_mirrors/fa/farm点击查看免费下载本篇技术指南以 Farm 仓库自带的 AI 技能文档 .agents/skills/rebase-commit-push-pr/SKILL.md 为主体完整讲解如何在功能分支上安全地执行fetch origin/main、rebase、冲突解决、提交、推送以及创建 Pull Request 的端到端流程。结合 Farm 仓库的 commitlint 配置、PR 标题校验工作流、Changesets 与 release 流水线等真实工程实践读者可掌握一套既适合人工操作、也适合 AI Agent 执行的、可复制的分支收尾方法论。一、Skill 是什么一次看懂元数据与适用场景rebase-commit-push-pr是 Farm 仓库在.agents目录下维护的一份工作流技能文档供 VS Code Copilot 等 AI 编程助手通过斜杠命令调用。其 YAML frontmatter 定义了技能的核心信息字段值含义namerebase-commit-push-pr技能名与目录名一致descriptionFetch origin/main, rebase current branch, resolve conflicts safely, then commit and push changes; create a PR if none exists for the branch触发提示语说明该技能负责同步主干、安全解决冲突、提交推送、确保 PR 存在licenseMIT技能文档遵循 MIT 许可compatibilityRequires git repository with origin remote and GitHub CLI (gh) for PR checks/creation前置条件仓库配置了origin远端且安装了 GitHub CLIgh用于 PR 检查与创建metadata.authorfarm作者标识metadata.version1.0技能版本一句话概括其核心目标让一个工作分支安全地同步到origin/main妥善处理 rebase 冲突再把本地改动发布到远端并保证该分支存在一个可评审的 PR。该技能适用于以下典型场景功能分支开发完成后主干main已合入其他提交需要先 rebase 再推送本地存在尚未提交的改动需要一并收尾提交推送后希望自动确认或在缺失时创建对应分支的 Pull RequestAI Agent 被要求完成一次从同步到提 PR 的完整 Git 操作时由该技能提供标准步骤与安全护栏。二、前置条件检查在进入正式步骤前需确认环境满足技能文档compatibility声明的两个前提Git 仓库与origin远端当前工作区必须位于一个 Git 仓库内且存在名为origin的远端通常指向 Fork 或上游仓库。Farm 仓库的CONTRIBUTING.md建议的协作方式是 Fork 后 clone并配置 upstreamgit checkout -b your-branch-name从main切出主题分支git remote add upstream upstream-url添加上游远端。GitHub CLIgh第 6 步的 PR 查询与创建依赖gh命令并需要已通过gh auth login完成认证且账号对目标仓库具有读取与创建 PR 的权限。如果这两项不满足技能应在早期停止并提示用户补充环境而不是硬着头皮执行后续命令。三、七步完整工作流技能文档将流程拆解为 7 个明确步骤。下面逐一步展开包含每条命令的用途、输出解读与注意事项。第 1 步检查当前分支与工作区状态git branch --show-current git status --shortgit branch --show-current输出当前分支名后续的 PR 查询、汇报都要用到它git status --short以紧凑格式列出工作区变更M修改、A新增、D删除、??未跟踪等用于判断工作树是否干净、是否存在尚未解决完的冲突。技能文档特别强调如果git status已经显示存在未解决的冲突conflict应立即停止并请求用户指示不要带着冲突状态强行 rebase否则会把情况搞得更复杂。第 2 步拉取并 rebase 到主干git fetch origin main git rebase origin/maingit fetch origin main只更新本地的origin/main引用不会改动工作区安全无副作用git rebase origin/main将当前分支的提交重放到origin/main最新提交之上使分支历史保持线性后续合入主干时无需产生 merge commit也便于评审。这里要留意 rebase 与 merge 的本质差异rebase 会重写当前分支的提交哈希因此它属于改写历史操作。正因为如此技能在第 5 步才把--force-with-lease的强制推送限定在用户明确要求改写历史推送这一前提下详见下文护栏部分。第 3 步解决 rebase 冲突如有rebase 过程中如果当前分支与origin/main改动了同一处代码Git 会暂停并标记冲突文件。此时按技能文档的指引# 1. 查看冲突文件列表 git status --short # 2. 逐个文件有意地解决冲突不要执行破坏性 reset # —— 编辑冲突标记 / / 之间的内容保留正确的合并结果 # 3. 将已解决的文件加入暂存区 git add paths # 或对确认删除的文件使用 git rm paths # 4. 继续 rebase git rebase --continue重复解决 → add → continue直到 rebase 完成或者遇到必须由用户拍板的情况例如两个语义冲突的改动方向不明时停下询问。两条安全红线技能 Guardrails 原文禁止使用git reset --hard、git checkout --这类会丢弃工作的破坏性命令来图省事地解冲突不要用重放式覆盖掩盖问题。每个冲突都应人工审阅后再git add。第 4 步提交用户要求的本地改动仅在需要时# 若工作区已干净跳过提交 git status --short # 否则暂存默认全量并提交 git add -A git commit -m conventional message如果第 3 步解冲突后没有遗留未提交改动则跳过提交避免产生空提交默认使用git add -A暂存全部改动若用户指定了具体路径则只暂存这些路径提交信息遵循Conventional Commits规范feat:、fix:、chore:等。Farm 仓库对此有硬性约束根目录的 commitlint.config.js 通过extends: [commitlint/config-conventional]启用 Conventional Commits 校验并借助package.json中配置的 huskyprepare: husky与 lint-staged 在提交阶段拦截不合规信息CI 侧的 .github/workflows/lint-pr-title.yml 还会用amannn/action-semantic-pull-request校验 PR 标题允许的类型包括fix、feat、docs、style、refactor、perf、test、build、ci、chore、revert、release。第 5 步推送分支git push # 仅在用户明确要求改写历史推送时才使用 git push --force-with-lease首次推送新分支时若远端未建立上游跟踪可能需要git push -u origin branch这与仓库内 .agents/skills/finishing-a-development-branch/SKILL.md 中git push -u origin feature-branch的写法一致由于 rebase 改写了历史普通git push可能被远端拒绝此时技能文档明确要求只有用户显式提出改写历史推送时才允许使用git push --force-with-lease。--with-lease比裸--force安全——它会先校验远端引用是否仍是你上次拉取的状态避免覆盖他人同期推入的提交。第 6 步确保分支存在 PR# 查询当前分支已有的 PR gh pr list --head $(git branch --show-current) --json number,title,state,url # 若不存在则创建 PR gh pr create --fill # 若 --fill 因缺少元数据失败则显式提供标题与正文 gh pr create --title title --body bodygh pr list --head branch按分支名过滤JSON 输出包含 PR 编号、标题、状态与 URL用于判断已有 PR 则复用没有则新建gh pr create --fill会尽量复用当前分支提交信息与模板自动填充标题/正文当仓库缺少可推断的元数据例如没有 PR 模板、提交信息不足以生成标题时回退为显式传入--title与--body。Farm 仓库提供了 .github/PULL_REQUEST_TEMPLATE.md包含Description动机与解决的问题、BREAKING CHANGE 声明、Related issue三部分——若改动破坏兼容性PR 中必须填写 BREAKING CHANGE 说明以进入 CHANGELOG这正是--fill可以借助的模板上下文。第 7 步汇报结果技能文档要求操作结束后汇报以下五类信息供用户或后续流程确认分支名Branch nameRebase 结果是否成功、解决了哪些冲突文件Rebase outcome and conflict files resolved本次运行创建的提交提交哈希与标题若无新提交则注明 no new commit推送目标Push destinationPR 信息已有 PR 或新建 PR 的 URL。四、Guardrails技能的安全护栏全解技能文档将护栏单独成节是整套流程最核心的约束原文要点如下绝不使用git reset --hard、git checkout --或未经用户明确批准使用强制推送不修改amend提交除非用户显式要求若提交或推送过程中 hook/测试失败报告第一个失败项并停止而不是继续或绕过检查。这些护栏与 Farm 仓库的全局约定一脉相承根目录 AGENTS.md 的 Do Not 清单明确禁止 Agent 未经批准执行git push --force、git reset --hard禁止删除文件/分支禁止用--no-verify绕过 lint/format hookCONTRIBUTING.md 的 What AI Should Not Do 也复述了同样的红线force-push / hard-reset 需显式批准、不编辑生成文件、不直接改pnpm-lock.yaml、不绕过 hooks。这套护栏的设计逻辑是Git 收尾操作一旦出错就是历史级事故丢失提交、覆盖他人推送因此宁可停下询问也不擅自使用高风险命令。对 AI Agent 而言这些护栏同时扮演行为边界与停止条件两个角色。五、与仓库其他协作约定/技能的衔接rebase-commit-push-pr不是孤立的它在 Farm 仓库中与多个机制协同工作.agents/skills/git-commit-push/SKILL.md更轻量的仅提交并推送技能适合不需要 rebase 的收尾场景其护栏不强制推送、不 amend、hook 失败即停与本文技能保持一致。仓库另有对应的提示词文件 .github/prompts/git-commit-push.prompt.md。.agents/skills/finishing-a-development-branch/SKILL.md在实现完成、测试通过后提供四种收尾选项本地 merge、推送建 PR、保持原样、丢弃工作其中推送并创建 PR分支的git push -u origin branchgh pr create与本文技能第 5、6 步完全互通。.agents/skills/creating-changesets/SKILL.mdFarm 的版本管理约定——涉及包版本变更的 PR 应在.changeset/目录附带 changeset 文件。这与 rebase/commit/push 流程互补先按本技能完成提交推送再确保 PR 携带 changeset是 Farm 贡献者提交 PR 的完整形态。仓库.changeset/目录中现存大量真实 changeset 文件即为佐证。CI / 发布流水线合入main后.github/workflows/release.yaml 会通过changesets/action自动创建 Version Packages PR 并执行pnpm run release发布其中 scripts/check-changeset-status.mjs 负责判断是否存在待处理的 changeset 以决定是否跳过 Rust 构建。这解释了为什么PR 正确合入是整个发布链路的起点——而本文技能正是保证 PR 质量与分支卫生的关键一环。六、常见误区与最佳实践综合技能文档的步骤、护栏与仓库约定梳理出以下容易踩坑的点误区正确做法工作区有未解决冲突就 rebase第 1 步先检查git status --short发现冲突先停下询问用git reset --hard/git checkout --快速清除冲突逐文件审阅冲突标记解决后git add再git rebase --continue任意使用git push --force仅在用户明确要求时使用--force-with-lease保护远端他人提交忘记随 PR 附带 changeset参考creating-changesets技能与CONTRIBUTING.md在.changeset/中补充变更说明提交信息/PR 标题不符合 Conventional Commits使用feat:/fix:/chore:等规范类型本地 commitlint 与 CI 的lint-pr-title都会校验hook 或测试失败后继续推送报告第一个失败项并停止先修复再继续最佳实践小结以小步、可验证的节奏推进每完成一步fetch、rebase、add、commit都可以用git status确认状态出错时易于定位任何改写历史的动作都先沟通rebase、force-with-lease、amend 全部属于需要用户拍板的操作汇报结构标准化分支名、rebase 结果、提交哈希、推送目标、PR URL 五要素齐全便于人工复核与后续 CI 跟踪与仓库约定对齐Conventional Commits 信息、changeset 附带、BREAKING CHANGE 声明都是让 PR 顺利通过 Farm CI 闸门pnpm run ready、lint-pr-title等的前提。七、总结rebase-commit-push-pr为 Farm 仓库的功能分支收尾提供了一条可审计、可回滚、高风险操作显式授权的标准路径七步流程检查 → fetch/rebase → 解冲突 → 提交 → 推送 → 建 PR → 汇报覆盖了从同步主干到产出 PR 的全部动作Guardrails 则划定了绝不越过的安全边界。对开发者而言它可以当作一份手写 check-list 直接执行对 AI Agent 而言它是与仓库 commitlint、PR 标题校验、Changesets 发布链路等工程约定对齐的可靠工作流模板。理解并遵守这套流程是 Farm以及同类 monorepo 项目中高质量协作贡献的基本功。赞分享前端构建构建工具开发工具【免费下载链接】farmExtremely fast Vite-compatible web build tool written in Rust项目地址https://gitcode.com/gh_mirrors/fa/farm点击查看免费下载相关推荐MXNet 贡献者 Git 工作流完全指南从 rebase 冲突解决、分支管理到 squash 合并与安全强制推送MXNet 贡献者 Git 工作流完全指南从 rebase 冲突解决、分支管理到 squash 合并与安全强制推送 Apache MXNet 是一个社区驱动的人工智能深度学习机器学习Farm 仓库 AI 技能实践git-commit-push 安全提交与推送工作流解析Farm 仓库 AI 技能实践git commit push 安全提交与推送工作流解析 Farmfarm fe是一个用 Rust 编写、兼容 Vite 的前端构建构建工具开发工具TVM 贡献者 Git 工作流完全指南从 rebase 冲突处理到 force push 的正确姿势TVM 贡献者 Git 工作流完全指南从 rebase 冲突处理到 force push 的正确姿势 Apache TVM 是一个由社区共同开发的开源机器学习模型编译深度学习推理引擎上一篇PlayIntegrityFix终极指南2025年Android设备完整性修复完整解决方案下一篇Beekeeper Studio 多语言支持10 语言文档站与 11 份本地化 README 怎么用创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考