Git 分支管理
每项更改都应在自己的分支上进行。这包括一行修复和没有 issue 的更改。不要在主分支上提交。
1. 查找基础分支
使用第一个给出答案的源：
- 仓库说明。 阅读
CLAUDE.md、CONTRIBUTING.md和.github/文档。如果它们命名了某个基础分支或集成分支，就使用它。 - 远程默认分支。
git symbolic-ref --short refs/remotes/origin/HEAD # 输出 origin/<名称> gh repo view --json defaultBranchRef -q .defaultBranchRef.name - 歧义情况。 如果远程也有
develop或development分支，并且没有文档说明哪个是基础分支，请询问用户。不要猜测。
当集成分支（例如 develop）是基础分支时，针对已发布版本的 hotfix 应从默认分支开始。仅当用户将工作称为 hotfix 时才使用。
2. 检查当前所在位置
git status --porcelain
git rev-parse --abbrev-ref HEAD
- 如果工作树有不是你做的更改，则停止。询问用户如何处理它们。
- 如果你已在一个用于同一工作的分支上，则保持在该分支上。
- 如果你在基础分支上且有自己未提交的编辑，则移动它们：
git switch -c <name>会将它们保留在工作树中。
3. 从远程 tip 创建分支
git fetch origin --prune
git switch -c <name> origin/<base>
git log -1 --oneline
从 origin/<base> 开始，意味着本地过时的基础分支不会造成影响。不要运行 git pull 来“赶超”基础分支。没有必要这样做。
4. 命名分支
如果仓库有约定，则使用它。否则使用 <type>/<ref>-<slug>：
| 部分 | 值 |
|---|---|
type | feat、fix、docs、chore、refactor、test、release、hotfix |
ref | Issue 编号 (42)、流水线工单 (ticket-007) 或留空 |
slug | 两到五个小写单词，用连字符连接 |
示例：fix/42-null-session-crash、feat/ticket-007-search-filters、docs/readme-install-steps。
5. 工作期间
- 以每个提交都是独立有意义的步骤进行小步提交。使用祈使句写主题，不超过 72 个字符。在正文中说明原因。
- 不要在提交信息中添加
Co-Authored-By: Claude标签。这是 gener8v 的规定。 - 在第一次推送之前，你可以 rebase 到
origin/<base>。分支推送之后，改用合并基础分支到该分支的方式。对已推送分支进行 rebase 会重写历史，而engineering:git-safety对此进行限制。 - 使用一个在第一次失败时停止的管道链进行推送：
set -o pipefail git fetch origin && <test command> 2>&1 | tail -n 40 && git push -u origin HEADset -o pipefail，| tail会隐藏其之前命令的退出码。切勿在没有它的情况下通过tail管道传递 git 命令或测试命令。
并行工作
对于两个或更多同时编辑代码的代理，在启动任何代理之前阅读 resources/parallel-work.md。简而言之：从基础分支创建一个批处理分支，从批处理分支为每个代理创建一个工作树和一个分支，并且没有两个代理处理相同的文件。
完成条件
- 你在一个名称清晰的分支上，并且它从当前的
origin/<base>开始。 git status没有显示属于其他人的更改。
相关技能
engineering:github-pr-merge：工作完成后打开 PR。engineering:git-safety：关于强制推送、删除分支等命令的审批规则。engineering:github-issue-workflow：issue 或流水线工单的完整生命周期。它首先调用此技能。