git appraise request 未生成 review-ref 的根本原因是 git-appraise 默认只对比当前分支与 origin/master（或 origin/main），若远程跟踪分支不存在、未 fetch 或未设置 upstream，则静默跳过创建。
git appraise request 为什么没生成 review-ref？
常见现象是执行 git appraise request 后，git appraise show 显示 “no active review”，或 git appraise list 为空。根本原因不是命令失败，而是 Git-Appraise 默认只对比当前分支与 origin/master（或 origin/main），如果远程跟踪分支不存在、未 fetch 过，或当前分支未设置 upstream，它就找不到目标 ref，从而静默跳过创建。
实操建议：
CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。
- 先确认上游分支已建立：
git branch --set-upstream-to=origin/main（或对应主干分支名） - 确保远程已同步：
git fetch origin，否则origin/main可能是 stale 的 - 显式指定目标分支更可靠：
git appraise request --target-ref refs/heads/main - 检查仓库是否启用 Git-Appraise 的元数据存储：运行
git rev-parse refs/notes/reviews，若报错说明 notes ref 尚未初始化（首次 push 后自动创建，但本地不会自建）
git appraise comment -l 行号评论不生效？
执行 git appraise comment -f foo.py -l 42 -m "TODO" 后，git appraise show 不显示该评论，或评论出现在错误的提交上。这不是 bug，而是 Git-Appraise 的行号绑定机制依赖于 diff 上下文 —— 它把评论锚定在“该行在 diff 中的偏移位置”，而非文件绝对行号。一旦目标文件被其他人修改（增删空行、调整格式），原始 diff 偏移失效，评论就“丢失”了。
实操建议：
- 评论前先
git appraise show --diff确认当前 diff 内容，避免在尚未 push 的本地变更上评论 - 优先评论函数/方法级范围，用
-f foo.py -m "函数 X 缺少边界检查"，比行号更稳定 - 若必须用行号，确保评论时 diff 已固定（即已 push 到远程，且他人未 rebase 或 force-push）
- 评论后务必
git appraise push，否则仅存于本地 notes，他人不可见
git appraise pull 和 git pull 混用导致审查状态错乱
团队成员交替执行 git pull 和 git appraise pull 后，发现审查状态（如 accepted 或 rejected）消失，或同一 review 出现多个冲突版本。这是因为 git pull 只拉取 commits 和 refs，而 Git-Appraise 的审查数据存在 refs/notes/reviews 下，需单独拉取；反之，git appraise pull 默认只拉 notes，不更新 commits —— 两者不互补，也不覆盖。
实操建议：
- 日常同步应统一为两步：
git fetch origin && git appraise pull，避免git pull干扰 notes 状态 - 配置自动 fetch notes：
git config --add remote.origin.fetch '+refs/notes/*:refs/notes/*'，这样git fetch就包含 review 数据 - 禁止在未
git appraise pull前执行git appraise push，否则可能覆盖他人最新评论（Git-Appraise 不做并发合并，直接 overwrite） - 定期清理陈旧 notes：
git notes prune，防止历史 review 数据膨胀影响性能
git appraise accept 后无法合并？
git appraise accept 成功执行，git appraise show 显示状态为 accepted，但 git merge 仍提示冲突或拒绝合并。Git-Appraise 本身不触发合并，它只记录决策；是否合并、何时合并、如何合并，完全由团队流程和 Git 命令控制。
实操建议：
-
git appraise accept仅写入 review note，等价于“盖章批准”，不改变工作区或 index - 合并仍需手动操作：
git checkout main && git merge --ff-only feature/x（推荐 fast-forward）或git merge --no-ff feature/x（保留分支结构） - 若要求自动化，需配合 CI 脚本监听
refs/notes/reviews变更，或用git appraise list --status accepted查询后触发 merge - 注意：Git-Appraise 不校验 CI 状态，即使测试失败也能 accept —— 团队需自行约定“accept 前必须 green CI”
git appraise pull，可能让整个团队的审查上下文脱节。
