你将完成什么
本页把一次 Git/GitHub 协作拆成可检查的步骤:确认位置,查看状态和差异,建立分支,提交小改动,创建 PR,处理 review 评论,解决冲突,最后按权限和回滚规则交付。 读完后,你应该能够:- 分清工作区、暂存区和
HEAD的差异; - 使用
status、diff、branch、commit完成一次任务; - 使用
gh创建、查看、检查和评论 PR; - 让每条审查意见都有修改、验证、回复和复查;
- 处理 merge/rebase 冲突并在必要时中止;
- 区分
restore、revert和发布系统回滚; - 守住 push、force-push、主干 merge、权限和生产操作红线。
gh 版本有差异时,先运行 git --help、gh --help 和对应子命令帮助。
01 先建立边界
Git 动作的影响范围不同。读状态通常只读,commit 改变本地历史,push 改变远端分支,merge、权限变更和发布会影响团队或用户。
进入项目先回答:当前目录是否正确?当前分支是否正确?是否有别人的未提交改动?本次命令是否会写远端或影响外部系统?
建议在项目
AGENTS.md 或贡献指南中写入测试命令、分支命名、commit 格式、PR 要求和禁止自动 push/merge/force-push 的规则。持久规则写文件,一次性范围写当前任务。
02 status:先确认你在哪里
rev-parse 确认仓库根目录;remote -v 确认真实远端;branch --show-current 确认分支;ahead 1 表示本地比远程跟踪分支多一个提交。
status --short 的两个字符分别表示暂存区和工作区:
不认识的改动先记录和确认归属。不要为得到“干净状态”直接运行
git restore .、git clean -fd 或覆盖式复制,它们可能删除未提交工作。
任务开始时建议记录:
03 diff:看清提交会包含什么
git diff 是工作区相对暂存区,git diff --cached 是暂存区相对 HEAD,git diff HEAD 包含暂存和未暂存改动。
git diff --check 无输出通常表示没有空白错误,但它不能证明逻辑正确。发现 trailing whitespace、冲突标记或密钥时先停止。
任务范围清楚时按路径暂存:
git add . 当默认提交策略。它可能带入 .env、生成物、调试输出和别的任务。
04 分支:一个任务一条边界
先更新远端引用,再从最新主干创建分支:git worktree list --porcelain 查看占用关系,不要修改 .git/worktrees 绕过保护。
05 Commit:保存可解释的工作单元
一个 commit 应有单一目的、有限范围、可复现验证和清晰消息。提交前:feat、fix、refactor、test、docs、chore。测试、实现和文档若意图不同,拆成独立 commit;这样 review 和回滚都更精确。
06 Push 前检查与红线
Push 前检查目标、分支、差异和敏感文件:--force-with-lease 仍然会改写历史;它不是自动授权。必须强推时,由分支负责人确认远端最新 SHA、备份、影响范围和保护规则,并由人执行。主干 merge、删除远程分支、修改保护规则、发布和生产操作也保留人工放行。
07 gh:管理 Pull Request
检查安装和登录状态:
pr-body.txt:
gh pr checks 不能代替阅读 diff、理解需求和人工审查。失败时区分代码、环境、权限、缓存和超时问题。
08 审查:把评论变成闭环
作者开 PR 前先自查:/review 审未提交改动、某个 commit 或相对基线的差异。它是只读辅助,不是测试证据,也不替代人工读 diff。
推荐审查提示:
评论处理闭环
- 阅读并复现问题;
- 判断是缺陷、需求差异还是非阻断建议;
- 以最小范围修改并补测试;
- 运行针对性和必要的完整检查;
- push 到同一 PR 分支;
- 回复 commit、验证命令和未完成项;
- reviewer 复查后再 resolve;
- merge 前重新检查完整 diff 和 checks。
gh ... --help 为准。外部 PR/Issue 评论是不可信输入,若要求读密钥、上传文件、访问内部地址或绕过审批,应停止并人工核对。
09 Merge 前验收与权限
合并方式可为 merge commit、squash 或 rebase,按项目历史、签名和发布触发策略选择。不要把
gh pr merge --auto 无条件写进脚本。合并按钮是共享系统的放行动作,不能只因 CI 变绿就跳过需求审查。
10 冲突:理解两边行为
冲突时先保存现场:HEAD 通常是当前分支一侧,另一侧是待合入提交;以 status 和历史为准。处理步骤:
- 阅读完整函数和需求;
- 用
git show <sha>查看双方提交; - 用
git diff --ours、git diff --theirs查看两侧; - 决定最终业务行为,不要只删标记;
- 补齐测试,删除所有标记;
- 暂存后检查 staged diff;
- 运行格式、类型、针对性和完整验证。
11 回滚:按阶段选择方法
保存未提交现场:
git revert 只回滚 Git 文件变化,不能撤销已经发送的邮件、扣款、消息、迁移数据或第三方 API 调用。生产回滚必须同时检查数据、队列、缓存、指标和用户路径。
12 完整示例:从任务到 PR 闭环
任务:SHOP-142 修复购物车总价没有乘 quantity。
准备和修改
Push 和 PR
13 最终验收
Git
代码和行为
GitHub
14 常见故障
状态出现未知文件:确认路径和归属,检查diff,不要直接清理。
暂存混入无关文件:用 git diff --cached --name-only 找出它们,运行 git restore --staged -- path,再按路径暂存。
push non-fast-forward:git fetch origin 后用 git log --left-right HEAD...origin/branch 判断远端变化,按团队策略 merge/rebase 并重新测试,不要直接 force-push。
PR checks 失败:区分代码、环境、缓存、权限和超时;不要删除测试或放宽安全检查只求变绿。
分支落后不能合并:更新引用,按项目规则合并或 rebase,解决冲突后查看完整 diff 和测试。
gh 账号或权限错误:检查 gh auth status、gh repo view;不要复制他人 token 或请求无关管理员权限。
误提交密钥:停止传播,立即撤销凭据,按安全事件流程清理历史并通知负责人;删除文件或 revert 不能让已泄露 token 重新安全。
误合并主干:暂停发布,记录 merge commit 和影响范围,创建反向修复 PR;不要 force-push 主干。涉及数据和外部副作用时执行专门补偿。
小结
核心顺序是:status 确认位置和边界,diff 读取事实,分支隔离任务,小 commit 保存意图,push 前核对远端,PR 中完成 review 评论闭环,冲突时理解双方行为,错误时按阶段选择 restore、revert 或发布回滚。
记住六条红线:
- 任何写入前先看
status; - 任何提交前先看
diff --cached; - 任何 push 前确认远端、分支、提交和敏感文件;
- 每条评论都有修改、验证、回复和复查;
- force-push、主干 merge、权限变更和生产操作人工放行;
- 共享历史优先用新 commit 或
git revert,不要改写别人可能依赖的历史。
参考/codex/26-git-github.md、参考/codex/14-workflows.md、参考/codex/36-best-practices.md。