Git 协作实战与 Gerrit 评审流程
1. 背景与目标
协作开发的痛点集中在：分支基线不一致导致冲突、评审链路混乱、历史不可追溯。本文给出一套可直接落地的 Git×Gerrit 流程：进入仓库 → 同步远端 → 正确进入分支 → 体检 → 差异审视 → 提交策略 → 评审推送（refs/for/*）。重点兼容旧版 Git 环境，所有命令均可一键复制。
2. Git 协作的最小心智模型
三层结构
工作区（Working Tree）：你在编辑器里看到/修改的文件。
暂存区（Index，.git/index）：下一次提交的“变更清单”，由 git add 写入。
本地仓库（.git/）：对象库（objects/）+ 引用（refs/），存放所有历史提交与分支指针。
两类分支指针
本地分支：refs/heads/<branch>，你提交时前移它。
远程跟踪分支：refs/remotes/origin/<branch>，git fetch 更新，只读，反映远端状态。
上游（upstream / tracking）
给本地分支绑定一个“默认对齐对象”（通常是 origin/<branch>）。绑定后：
git pull/git push 可省略分支名；
git status -sb 能显示 [ahead X, behind Y]。
3. 关键动作与语义
git fetch：更新远程跟踪分支与对象库，不改工作区与本地分支；加 --prune 清理远端已删引用，避免“幽灵分支”。
git pull：fetch + 合并策略（默认 merge，可设为 rebase）。
git merge：生成合并提交，保留分叉历史，适合多人共享分支。
git rebase：把你相对基线的提交“重放”到基线最新头上，线性历史、评审更清晰；不应用于已公开（共享）的历史。
git branch -u：设置/修改当前分支的上游（--set-upstream-to）。
建议：个人特性分支跟主干同步时优先 rebase；共享分支避免改写历史，用 merge。
4. 标准作业流程（SOP，含命令清单）
S1 进入仓库与校验
cd /home/aaa/bbb/ccc
git rev-parse --show-toplevel # 确认在仓库根
S2 同步远端（幂等，安全）
git fetch --prune origin
# 只更新远程跟踪分支与对象库，不覆盖你的文件与本地分支
（可选）确认默认基线：
git symbolic-ref refs/remotes/origin/HEAD # e.g., refs/remotes/origin/master
S3 分支进入策略
远端已存在，本地还没有 → 一步到位建立跟踪
git checkout -t origin/cp-jinwei06-1102
本地已存在但未绑定上游 → 补绑
git checkout cp-jinwei06-1102
git branch -u origin/cp-jinwei06-1102
远端还没有 → 基于最新基线新建
git checkout -b cp-jinwei06-1102 origin/master # 或 origin/main
# 首次推送时加 -u 建立上游：git push -u origin cp-jinwei06-1102
S4 开发前体检
git status -sb # 当前分支与工作区摘要
git branch -vv # 上游绑定、ahead/behind 统计
git fetch --prune origin
git rebase origin/master # 或 git merge origin/master
S5 提交前差异审视
git diff --name-status origin/cp-jinwei06-1102 # 已跟踪文件改/删
git ls-files --others --exclude-standard # 新建但未跟踪（受 .gitignore）
git check-ignore -v path/to/file # 为何被忽略（可用 -f 强制）
S6 暂存与提交策略
# 精准选块（推荐）：只提交需要审阅的改动
git add -p
# 或一次性纳入新增/修改/删除
# git add -A
# 首次提交（已装 hook 会自动写入 Change-Id）
git commit -m "feat: 本次变更的目的/范围简述"
# 更新同一评审（生成新 Patchset）
git commit --amend --no-edit
S7 推送评审
git push origin HEAD:refs/for/cp-jinwei06-1102
5. 提交前差异审视（细化示例）
只看文件清单（对比远端分支）：
git diff --name-only origin/cp-jinwei06-1102
摘要统计（变更多寡）：
git diff --stat origin/cp-jinwei06-1102
仅查看已暂存的内容（提交面貌）：
git diff --staged --stat
未跟踪文件与忽略诊断：
git ls-files --others --exclude-standard
git check-ignore -v path/to/file
建议：只提交脚本/配置/必要的小样例；大体量运行产出保持在 .gitignore 中，通过脚本可复现。
6. 冲突处理与回滚策略
Rebase 冲突三步
git rebase origin/master
# 解决冲突 → 标记解决
git add <冲突文件或目录>
git rebase --continue
放弃/跳过
git rebase --abort # 放弃这次重放
git rebase --skip # 跳过当前提交（极少使用）
回退到 Rebase 之前的状态：--abort；
已公开历史不要 rebase（会制造分叉），继续 merge 更安全。
评审误改：在本地修正后 git commit --amend 生成新 Patchset 覆盖旧内容。
7. 速查表（Cheat Sheet）
目的 命令
取回远端并清理 git fetch --prune origin
进入远端已有分支并建跟踪 git checkout -t origin/<branch>
本地已有分支补绑定上游 git branch -u origin/<branch>
基于最新基线新建分支 git checkout -b <branch> origin/master
跟主干对齐（线性历史） git fetch --prune origin && git rebase origin/master
查看相对远端的改动清单 git diff --name-status origin/<branch>
查看未跟踪新文件 git ls-files --others --exclude-standard
暂存策略（精准/全量） git add -p / git add -A
首次提交 / 追加 Patchset git commit -m "..." / git commit --amend --no-edit
推送到评审 git push origin HEAD:refs/for/<branch>
rebase vs merge 快速指引
个人特性分支：rebase（清爽线性）。
共享/已公开历史：merge（避免改写历史）。
no new changes 快速定位
git status -sb：是否有改动/暂存？
git ls-files --others --exclude-standard：是否全是未跟踪新文件？
.gitignore 命中？用 git check-ignore -v <path>；必要时 git add -f <path>。
追加 Patchset 记得 git commit --amend 生成新提交。
8. 总结
把协作动作的语义与评审机制分开理解：fetch 只拉消息、rebase 线性对齐、refs/for/* 进入评审、--amend 产出新 Patchset。
落地层面，坚持三件事：
1）任何对齐动作前先 fetch --prune；
2）个人分支优先 rebase，共享分支用 merge；
3）评审始终通过 refs/for/*，更新用 --amend。
这样能在团队内形成低冲突、可审计、可复现的开发闭环。