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）

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。
這樣能在團隊內形成低沖突、可審計、可復現的開發閉環。