娄底市网站建设_网站建设公司_网站开发_seo优化

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。

这样能在团队内形成低冲突、可审计、可复现的开发闭环。