Git 协作实战与 Gerrit 评审流程

Git 协作实战与 Gerrit 评审流程

适用场景：公司内网仓库 + Gerrit 评审流程；服务器上 Git 版本较老（无 git switch、git restore）。
示例仓库：/home/aaa/bbb/ccc，远端别名 origin。

---

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 快速定位

1. git status -sb：是否有改动/暂存？
2. git ls-files --others --exclude-standard：是否全是未跟踪新文件？
3. .gitignore 命中？用 git check-ignore -v <path>；必要时 git add -f <path>。
4. 追加 Patchset 记得 git commit --amend 生成新提交。

---

8. 总结

把协作动作的语义与评审机制分开理解：fetch 只拉消息、rebase 线性对齐、refs/for/* 进入评审、--amend 产出新 Patchset。
落地层面，坚持三件事：
1）任何对齐动作前先 fetch --prune；
2）个人分支优先 rebase，共享分支用 merge；
3）评审始终通过 refs/for/*，更新用 --amend。
这样能在团队内形成低冲突、可审计、可复现的开发闭环。