第一部分：Git 常用命令（示范 + 参数解释）

以下命令覆盖日常使用，<...> 需替换为实际值。

  • git init：初始化仓库。
  • git clone <repo-url> [dir]：克隆远端仓库到本地，可指定目录名。
  • git remote add origin <repo-url>：添加远端；git remote -v 查看；变更地址用 git remote set-url origin <repo-url>。
  • git status -sb：查看状态（-s 简洁，-b 显示分支）。
  • git add <path>：暂存文件，-p 交互式分块。
  • git restore --staged <path>：从暂存区移除，保留工作区改动。
  • git restore <path>（或 git checkout -- <path>）：丢弃工作区改动，慎用。
  • git switch <branch>：切换分支；-c 创建并切换；-C 强制覆盖。
  • git branch：列出分支；-r 远端；-d/-D <branch> 删除分支。
  • git fetch [remote]：抓取更新；-p 清理失效引用。
  • git pull --rebase：拉取并变基，减少合并节点；--autostash 拉取前自动暂存。
  • git push origin <branch>：推送；-u 设上游。
  • git commit -m "<msg>"：提交；-am 跳过 add（仅已跟踪文件）。
  • git log --oneline --graph --decorate -n 20：最近 20 条提交，图示模式。
  • git diff：工作区 vs 暂存区；--cached 暂存区 vs HEAD；git diff <A>..<B> 比较两提交。
  • git stash push -m "note"：暂存现场；list 查看；pop 取出删除。
  • git tag -a v1.0.0 -m "msg"：附注标签；push origin --tags 推送。
  • git revert <commit>：生成反向提交安全回滚；git reset --hard <commit> 强制回滚（慎用）。
  • git cherry-pick <commit>：挑单条提交。

Cheatlist：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# 状态/差异
git status -sb
git diff               # 工作区 vs 暂存区
git diff --cached      # 暂存区 vs HEAD

# 分支与同步
git switch -c feature/x
git fetch -p
git pull --rebase
git push -u origin feature/x

# 提交
git add -p
git commit -m "type(scope): subject"

# 暂存现场
git stash push -m "wip"
git stash list
git stash pop

# 回滚/挑选
git revert <commit>
git cherry-pick <commit>

# 查看历史
git log --oneline --graph --decorate -n 20

第二部分：Git 工作流

常见工作流速览

  • Centralized：直接在 main 工作，简单但易冲突。
  • Feature Branch（推荐）：一需求一分支，完毕合并主干，便于审查和回滚。
  • Gitflow：develop/release/hotfix 多分支，适合节奏固定的大项目。
  • Trunk-Based：主干 + 短分支 + 频繁集成，需强 CI 和特性开关。

详解：Feature Branch 工作流

  1. 开分支：git switch -c feature/brief-topic，小写连字符命名。
  2. 开发自测：按需多次提交；若是 Hexo 站点，生成前可跑 npm run clean && npm run build。
  3. 保持同步：开发中周期性 git fetch -p && git pull --rebase。
  4. 提交规范：原子提交、语义化 message；不要提交 public/ 等生成物。
  5. 推送与 PR：git push -u origin feature/brief-topic，PR 描述改动、测试、影响面。
  6. 合并策略：倾向 squash/rebase 保持历史整洁；冲突先本地解决再推送。
  7. 收尾：合并后删除分支：git push origin --delete feature/brief-topic 与 git branch -d feature/brief-topic。

典型场景速览：

  • 小需求：单人一天内完成，直接 feature 分支 → 自测 → squash 合并。
  • 中型需求：多人协作，分子任务分支（feature/a、feature/b），完成后先合入汇总分支再 PR，减少主干冲突。
  • 热修复：从 main 拉 hotfix/issue-id，修完优先 rebase 确保最新，再合并并打 tag，随后清理分支。
  • 长期特性：周期长的功能开启 feature flag，在主干小步合并，避免长期分叉；必要时周期性 rebase 降低冲突。

第三部分：Git commit message 推荐格式

格式与类型

  • 使用 Conventional Commits：<type>(<scope>): <subject>，scope 可省略，subject 用现在时/祈使句、不加句号。
  • 常用 type：feat（新功能）、fix（修 bug）、docs（文档）、style（格式）、refactor（重构）、test（测试）、chore（杂项）。

书写要点

  • 主题行 ≤ 72 字符，写清对象+动作，避免“update/change”。
  • 需要背景/测试/影响时，主题后空一行写正文；有破坏性改动用 BREAKING CHANGE: 开头描述迁移。

示例 messages

  • feat(post): add bangumi summary block
  • fix(theme): correct navbar logo path
  • docs: document bangumi update flow
  • refactor: extract hexo build helper
  • test: add bangumi data freshness test
  • chore: bump hexo to 8.1.1

模板（含正文示范）

1
2
3
4
5
fix(post): correct bangumi cover url

原因：外链 404，改为站内缓存路径。
影响：仅影响 bangumi 页面封面展示，无兼容性问题。
测试：npm run clean && npm run build；生成后检查 public/bangumis.json 链接可访问。

解决Git合并冲突

git merge 冲突解决（current/incoming/ours/theirs）

  • 准备：先 git fetch -p 更新远端，必要时先 git pull --rebase 同步，减少无意义冲突。
  • 合并命令：git switch target && git merge source。
  • 冲突出现后的完整流程：
    1. git status 查看冲突文件清单。
    2. 打开冲突文件，找到标记：<<<<<<<（current/ours，目标分支）======= 分隔线，>>>>>>>（incoming/theirs，源分支）。
    3. 根据需要选择：
      • 保留当前分支为主 → 选 ours/current 片段；
      • 引入对方改动 → 选 theirs/incoming 片段；
      • 两边都要 → 手工合并，删除标记，确保逻辑正确。
    4. 如需对比，用 git diff 或支持的话 git diff --base <file> 查看共同祖先差异。
    5. 保存后对每个文件 git add <file> 标记已解决，git status 确认干净。
    6. git commit 完成合并（可在 message 中备注冲突点或解决策略）。
  • 常见场景快速决策：
    • 配置/文案被对方更新而本分支未改 → 选 theirs；
    • 本分支大改，对方无关 → 选 ours；
    • 同一函数双方都有逻辑 → 手工合并并本地跑一遍验证。
  • 工具辅助：在支持的编辑器中可用“Accept Current/Incoming/Both”按钮，含义同 ours/theirs/both。
  • 典型场景示例：
    • 场景 A（多人改同文件不同段）：优先用工具对比，分段保留两侧有效逻辑，再跑测试。
    • 场景 B（配置或文档被上游更新）：当前分支未改同处，直接选 theirs/incoming；若本地有调优则手工合并。
    • 场景 C（功能大改 vs 小修）：以大改分支为主（ours），手动引入小修里必要的逻辑和校验，再测试。
    • 场景 D（仅格式冲突）：可选一侧并统一跑格式化，避免重复的格式提交。

merge 与 rebase 的选择

  • merge：保留分支合并节点，历史完整可追溯，适合多人并行、需要看到合流时间点；冲突只处理一次（合并时）。
  • rebase：把你的提交重放到目标分支顶端，历史线性，便于 bisect 和阅读；但每个提交重放时都可能遇到冲突，需逐次解决。公共分支慎用 rebase（避免重写他人历史），本地/短期分支优先使用。
  • 冲突标记的含义一致：rebase 时 current/ours 仍是当前分支正在重放的内容，incoming/theirs 是目标分支已有内容；按需选择或手工合并后 git add，继续 git rebase --continue。

清理 git 历史（含重写与回滚）

场景快速决策：

  • 线上回滚：公共分支用 git revert 生成反向提交，保持历史，紧急时优先。
  • 本地整理提交：未推送前用 git reset --soft/--mixed 或 git rebase -i 重排、squash；推送后谨慎，需团队确认并可能强推。
  • 精选引入：只要某几个提交，用 git cherry-pick；自测后再推。
  • 临时切换任务：用 git stash push -m 暂存工作，回到主线处理其他事，完了再 stash pop/apply。
  • 里程碑标记：发布或重要节点打 git tag -a，推送 --tags 便于回溯。
  • 敏感信息/大批量历史清理：新分支用 git filter-repo 演练，备份后强推，通知协作者 fetch --all 并按指引重置。

回滚与整理（安全到激进）

  • 公共分支安全回滚：git revert <commit> 生成反向提交，保持历史可追溯。
  • 本地未推送的整理：git reset --soft <commit>（保留暂存）或 --mixed（保留工作区）重排提交；--hard 重写工作区+暂存，需团队确认并可能 git push -f。
  • 语义清理：git rebase -i HEAD~N 进行 squash/fixup/重排。rebase 冲突时：current/ours=目标分支当前内容，incoming/theirs=正在重放的补丁；修冲突后 git add、git rebase --continue，跳过用 --skip，放弃用 --abort。

抽取与选择性合并

  • git cherry-pick <commit>（或区间 A..B）提取少量提交，不合并整个分支；冲突处理同 rebase，完成后自测。

暂存现场与里程碑

  • stash：git stash push -m "note" 临时保存未完成改动，便于先切分支/拉更新；恢复用 git stash apply（保留）或 pop（恢复并删除）。
  • tag：git tag -a v1.0.0 -m "release" 标记里程碑，git push origin --tags 推送；删除标签 git tag -d v1.0.0 + git push origin :refs/tags/v1.0.0。

批量重写/删敏

  • 首选 git filter-repo（替代 filter-branch），示例：
    • 删除路径：git filter-repo --path secrets.txt --invert-paths
    • 替换敏感信息：git filter-repo --replace-text replacements.txt
  • 操作流程：在新分支演练 → 备份 → 跑构建/测试 → 团队确认 → 强推 → 通知协作者 git fetch --all 后按指引重置本地。

参考资料