Git 与协作速查
提交与分支命令、分支模型（GitFlow / Trunk-Based）、合并变基与冲突解决、PR/MR 评审、子模块与大仓实践：团队版本控制速查。
Git 基础与命令88 条
工作区/暂存区/提交、日志检索与回退
git commit 创建提交热门
把暂存区内容记录为提交：默认打开编辑器撰写信息，-m 直接给出，-a 跳过手动暂存直接提交已跟踪文件的修改。
git clone 克隆仓库热门
把远端仓库复制到本地：自动配置 origin、拉取默认分支并建立跟踪关系，支持指定分支、目录名与子模块递归。
git add 暂存改动热门
把改动加入暂存区，是提交的前置步骤；可整目录、按路径或按补丁块暂存，-A 与 -u 对新增、删除的处理范围不同。
git log 查看提交历史热门
浏览提交历史：-n 限制条数、--oneline 简洁输出、--no-merges 过滤合并提交；是定位改动与复盘的起点命令。
git status 查看仓库状态热门
查看工作区与暂存区差异：哪些改动已暂存、哪些未暂存、哪些文件未跟踪；是提交前确认改动范围的固定动作。
git push 推送提交热门
把本地提交送到远端：默认推当前分支到其上游（push.default=simple）；支持 refspec 映射与 --dry-run 演练。
git diff 查看未暂存差异
比较工作区与暂存区的改动；git diff HEAD 则显示工作区相对 HEAD 的全部差异，是提交前自查的基本视角。
git config 配置读写与常用项
读写 Git 配置的入口命令：管理提交身份、编辑器、换行符与别名等，支持 local、global、system 三级作用域，可用 --show-origin 追踪配置来源。
git pull 拉取并集成
pull 等价于 fetch 加集成（默认 merge，可配置 rebase）；--ff-only 只允许快进，能避免不在预期内的合并提交。
.gitignore 忽略规则
声明无需纳入版本控制的文件：按目录生效、支持通配与否定；忽略规则只对未跟踪文件生效，已跟踪文件需要先移出索引。
git stash 保存工作现场
把已跟踪文件的改动与暂存状态存入 stash 栈，工作区回到干净状态；默认不含未跟踪文件，可用消息标记用途。
git init 初始化仓库
在当前目录创建 Git 仓库：生成 .git 目录与初始配置；-b 可指定初始分支名，也可用 init.defaultBranch 设定默认值。
git restore 复原文件与暂存区
复原工作区或暂存区：默认丢弃工作区改动，--staged 取消暂存，--source 从历史版本取回内容。
git commit --amend 修补上一条提交
改写上一条提交：补文件或改信息，生成新的提交哈希；默认保留作者与作者时间，更新提交者信息与时间。
git fetch 只下载不合并
从远端取回对象与引用更新而不动工作区：把远端变化安全地拿到本地，评审后再决定合并或变基。
git clone --depth 浅克隆
浅克隆只取有限条提交：--depth=N 控制深度，明显减少拉取体积与时间，适合 CI 与只需要新近代码的场景；代价是历史不完整。
git diff --staged 复核待提交内容
检查即将进入提交的改动：--staged 等价 --cached，比较暂存区与 HEAD，是提交前的一道复核。
git show 查看对象内容
查看单个对象：提交（默认包含补丁）、标签、树；--stat 只看摘要，-s 只看提交信息。
git revert 反向提交回退
用新提交抵消既有改动：不改写历史，适合已推送内容的安全回退；-n 只应用不提交，-m 用于撤销合并提交。
git add -p 交互式暂存
逐块选择改动进入暂存区：-p 按补丁块询问是否暂存，是拆分提交、保持提交粒度的常用工具；-e 可手工编辑补丁块。
git log 图形化速览组合
--oneline --graph --decorate --all 组合成分支拓扑视图：一行一条提交，显示引用名与分叉合并关系。
git reset 默认模式（--mixed）
默认行为：重置暂存区但保留工作区改动；用于取消全部暂存，或回退提交后重新挑拣文件。
git remote 管理远端仓库
查看与维护远端：-v 显示地址，add/rename/remove 管理条目；克隆产生的默认远端名为 origin。
git blame 逐行追溯变更
逐行显示最后一次改动该行的提交与作者：-L 限定行区间、-C 探测跨文件复制来源、--show-email 显示邮箱。
git config 作用域与优先级
理解三级配置的覆盖关系：local 覆盖 global、global 覆盖 system；同名键按就近原则生效，排查配置问题时先确认读取来源。
git log 按作者时间关键词筛选
精炼历史查询：--author 查作者、--grep 查信息、--since/--until 限定时间窗，多个条件默认取交集。
git tag 标签基础
给提交打标签：列出、创建、删除与推送；标签默认不随 push 自动上传，需要显式推送目标标签。
提交信息结构与多段写法
提交信息约定：首行主题句、空行、正文说明动机；可用多个 -m 拼段落，或用 -F 从文件读取，-v 在编辑器中附带 diff 预览。
git reset --hard 硬重置
回退到指定提交并同步丢弃暂存与工作区改动；未提交的改动无法找回，只适合放弃明确的本地实验。
git push -u 建立跟踪关系
推送新分支时用 -u/--set-upstream 记录上游：之后 git push、git status 与 git pull 都能直接对应远端分支。
git reflog 引用日志
记录 HEAD 与分支指针的每次移动：误重置、误删分支后的找回线索，默认保留 90 天（可配置）。
git status --short 短格式与脚本解析
面向脚本的稳定输出：--short 简洁显示，--porcelain=v1/v2 格式稳定；两列 XY 分别对应暂存区与工作区状态。
git rm 删除文件并记录
删除文件并暂存删除动作；--cached 只把文件移出版本库、保留磁盘内容，适合把误提交文件停止跟踪。
git diff --stat 差异摘要
变更规模概览：--stat 输出每个文件的增删行数，--numstat/--name-only/--name-status 供脚本与评审流程使用。
git stash pop 与 apply 的区别
取回现场：pop 恢复后把记录从栈中删除，apply 恢复但保留副本；list/show 查看，drop/clear 删除记录。
git bisect 二分定位回归
手动二分：start 进入流程，标记 good/bad 后逐次检出中点，收敛到引入问题的提交；结束时 reset 退出。
git init --bare 裸仓库
创建不含工作区的裸仓库，作为团队共享的服务端仓库或迁移中转站；--shared 控制组用户写权限，服务端钩子放在 hooks 目录。
git mv 移动与重命名
移动或重命名文件并同步索引；Git 按内容相似度识别重命名，先 mv 再 add 与 git mv 的最终效果接近。
git log -S / -G 检索内容变更
按内容检索历史：-S 记录某字符串出现次数的变化（新增或删除），-G 对 diff 文本按正则匹配，用来定位代码或配置何时引入。
git log 按路径过滤历史
只看影响指定路径的提交：git log -- <路径>；对单个文件用 --follow 可穿透重命名继续追历史。
git clean 清理未跟踪文件
删除未跟踪文件与目录：-n 先演练列出将删项，-f 执行，-d 处理目录，-x 连忽略文件一起清、-X 只清忽略文件。
git push --force-with-lease 带租约强推
有条件强推：当远端引用仍是你预期的位置时才允许覆盖，比 --force 多一层防误覆盖保护，适合 rebase 后推个人分支。
git clone --single-branch 单分支克隆
只抓取指定分支的引用，进一步压缩传输数据；默认与 --depth 组合使用。后续需要其他分支时可调整 remote 的 refspec 再拉取。
提交区间 A..B 与 A...B
区间语法查差异：A..B 是「在 B 不在 A」，A...B 是两分支的对称差，配 --left-right 标出每个提交属于哪一侧。
git reset 取消单个文件的暂存
带路径参数时只把该文件移出暂存区、不移动分支指针，等价于 git restore --staged 的效果。
git grep 在版本库中搜索
在已跟踪文件里搜索内容：默认搜索工作区，-n 显示行号、-l 只列文件、--count 计数，也可直接在指定提交上搜索。
git alias 命令别名
把高频命令缩写为短命令：alias.* 配置项，! 前缀定义执行 shell 的别名，可组合多步逻辑。
git clone --mirror 镜像克隆
镜像克隆得到包含全部引用（分支、标签与远端配置）的裸仓库，常用于仓库迁移与站点镜像，配合 push --mirror 整体推送。
git reset --soft 只移动分支指针
撤销提交但保留暂存区与工作区：改动原样停留在暂存状态，适合把多条提交合并为一条或重写提交内容。
git stash -u 纳入未跟踪文件
扩展入栈范围：-u 连未跟踪文件一起保存，-a 连被忽略文件也纳入，-k 在保存时保留暂存区状态。
git fetch --prune 清理远端跟踪引用
删除远端已清除的本地下游引用：git fetch --prune 或 git remote prune origin；可设 fetch.prune=true 作为默认行为。
git gc 仓库整理与打包
整理仓库：打包松散对象、压缩引用与清理临时文件；--auto 由日常操作自动触发，无需频繁手动调用。
git add -N 记录新增意图
intent-to-add 把新文件登记进索引但不暂存内容，让 git diff 能看到未暂存的新文件差异，便于走补丁式暂存流程。
git show 查看某版本文件内容
git show <rev>:<path> 直接输出指定提交中的文件内容，不需要切换分支；可重定向导出后与当前版本比对。
git remote set-url 修改远端地址
更换远端地址：HTTPS 与 SSH 互转、域名迁移都用它；--push 可以为推送单独指定地址。
git push --tags 推送标签
推送标签到远端：--tags 推全部本地标签，--follow-tags 只推送被已推提交可达的附注标签，发布流程更可控。
找回悬空提交与误删数据
恢复流程：fsck --lost-found 或 reflog 定位无引用提交，git show 核对内容后用 branch/reset 接回历史。
全局忽略文件 core.excludesFile
个人级忽略清单：用 core.excludesFile 指定（默认路径在用户配置目录下），适合编辑器临时文件与系统文件，不随仓库分发。
附注标签与签名标签
-a 创建带说明的标签对象（记录打标签者与日期），-s 使用 GPG 签名；发布标记建议使用附注标签。
git push --delete 删除远端分支或标签
删除远端引用：git push origin --delete <名称>；等价写法为 push origin :<名称>，需要相应写权限。
Git 传输协议与接入方式
常见协议：本地路径、SSH（git@）、HTTPS 与 git://；认证方式、端口与适用网络环境各不相同。
git check-ignore 排查忽略原因
定位「为什么这个文件被忽略了」：-v 显示命中的规则与来源文件；--no-index 可检查未被跟踪的路径。
git diff --word-diff 词级比较
以单词为粒度标记增删：--word-diff 输出词级标记、--color-words 用颜色呈现，适合长行或文档类修改的阅读。
git tag 过滤与排序
标签查询：-l 通配过滤、-n 附带说明行、--sort 指定排序（版本自然序用 v:refname）、--contains 反查提交所属标签。
git archive 导出发布包
把指定版本打包为 tar/zip：不含 .git 目录，--prefix 添加顶层目录，.gitattributes 中 export-ignore 的路径会被排除。
git credential 凭据管理
用 credential.helper 管理远端认证凭据：cache 缓存在内存、store 写入明文文件、系统钥匙串集成方案更安全。
.git/info/exclude 本地私有忽略
只在当前克隆生效的忽略清单，适合「仅我不想提交」的临时文件；不随仓库分发，优先级低于目录内的 .gitignore。
git shortlog 贡献统计
汇总提交者与提交数量：-sn 按数量排序、-e 显示邮箱、可指定区间统计发布周期内的贡献。
git stash 部分路径与交互块
只存一部分改动：stash push -p 交互挑选块，或 git stash push -- <路径> 限定目录，其余改动留在工作区继续用。
git describe 生成可读版本号
用标签描述任意提交：输出「标签-距离-短哈希」形式，--dirty 标记工作区有改动，常用于构建号与版本标识。
git bisect run 自动化二分
无人值守二分：让脚本对每个候选版本执行验证，按退出码判定好/坏，自动收敛并输出结果。
git rev-parse 解析引用与路径
脚本取值的常用命令：--show-toplevel 取仓库根、--abbrev-ref 取分支名、--short 取短哈希、--verify 校验引用。
core.autocrlf 换行符策略
控制检出与提交时的 CRLF/LF 转换；跨平台项目更推荐在 .gitattributes 声明 text=auto，让规则随仓库分发。
git diff --check 空白错误检查
检查新增行中的空白问题（行尾空白、tab 前空格等）；接入 CI 可把这类噪音拦在合并之前。
refspec 引用映射语法
refspec 描述「抓取什么、放在哪」：[+]<源>:<目标>；默认把远端分支映射到 refs/remotes/<远端>/ 下形成跟踪分支。
git blame 忽略批量格式化提交
让 blame 穿透格式噪音：把重格式化提交哈希写进清单文件，配置 blame.ignoreRevsFile 或临时 --ignore-rev 指定。
git fsck 仓库一致性检查
扫描对象库与引用：报告缺失对象、悬空对象与结构问题，是仓库体检与故障排查的入口命令。
git difftool 调用外部比较工具
把差异交给图形化工具逐文件浏览：配置 diff.tool 后执行 git difftool，-d 进入目录比较模式，--staged 比较待提交内容。
git ls-files 列出索引文件
查看暂存区（索引）中的跟踪文件：--stage 显示模式与对象哈希，-o 列未跟踪、-m 列已修改，适合核对提交范围。
git count-objects 对象库统计
查看对象数量与磁盘占用：-v 详细、-H 人类可读；区分松散对象与打包体积，是仓库瘦身排查的起点。
git bundle 离线打包传递
把对象与引用打包成单一文件：clone、fetch 可直接把它当远端使用，适合隔离网络环境搬运仓库。
git cat-file 查看 Git 对象
检视对象库内容：-t 类型、-s 大小、-p 按类型美化输出；--batch-check 批量查询对象元信息。
git rev-list 遍历提交集合
输出可达提交的哈希列表：--count 计数、--all 覆盖全部引用、区间语法与 log 一致，是统计脚本的基础。
git 编辑器配置 core.editor
交互场景（提交信息、交互变基）打开的编辑器由 core.editor 决定，GIT_EDITOR 环境变量可临时覆盖。
git prune 清理不可达对象
删除没有任何引用可达的对象；先用 git fsck --unreachable 查看清单，用 -n 演练确认范围。
git ls-tree 查看提交内容清单
列出树对象（提交快照）中的文件与子目录：-r 递归、-l 附对象大小、--name-only 只看路径。
git help 获取帮助
查阅文档：git help <命令> 打开手册页，git <命令> -h 快速查看选项，git help -a 列出全部命令。
git mailmap 归并作者署名
用 .mailmap 把同一人的多个姓名与邮箱映射到一个规范署名，影响 shortlog、log 等展示结果。
分支模型与工作流49 条
分支策略、保护规则与版本发布
git branch 分支基础操作
列出、创建、改名与删除分支；分支本身只是指向提交的轻量指针，创建与切换成本都很低。
git switch 切换分支
Git 2.23 起的新式切换命令：-c 创建并切换、-C 覆盖创建、--detach 进入分离头指针，- 回到上一个分支。
git checkout -b 创建分支（经典写法）
旧式建分支写法：git checkout -b <分支> [起点]；理解 checkout 的双重职责，是读懂历史文档与老脚本的前提。
Semantic Versioning 语义化版本
版本号含义约定：MAJOR.MINOR.PATCH；不兼容改动升主版本、兼容新增升次版本、兼容修复升修订号。
分支上游跟踪关系
维护本地分支与远端分支的对应关系：--set-upstream-to 设置、-vv 查看领先落后、--unset-upstream 取消。
GitFlow 分支模型
经典模型：长期维护 main 与 develop，配合 feature/release/hotfix 短分支；合并常用 --no-ff 保留分支聚合痕迹。
短生命周期分支实践
分支存活时间越短，与主线的偏离越小、集成风险越低；按小任务拆分并频繁同步主线是核心要点。
发布分支维护
从主线切出 release/x.y 冻结发布范围；缺陷修复先合主线，再挑回发布分支，保证后续版本不留坑。
检出远端分支建立跟踪
把远端分支拿到本地：switch <名称> 在唯一匹配时自动建立跟踪（DWIM）；显式写法为 switch -c <本地> origin/<远端>。
GitHub Flow 工作流
轻量流程：只保留一条长期分支，改动走「开分支 → 提交 → 开 PR → 评审 → 合并」，前提是 main 始终可部署。
删除本地与远端分支
清理分支：-d 安全删除（要求已合并）、-D 强制删除、远端用 push --delete；先用 --merged 核对清单。
GitLab Flow 工作流
在 GitHub Flow 上补充环境分支（如 production）或发布分支，用「上游优先」原则保证修复先落主线再回挑发布线。
查看远端分支列表
git branch -r 列出远端跟踪分支、-a 合并展示；列表来自本地缓存，保持新鲜要先 fetch/prune。
Trunk-Based Development 主干开发
开发者以小批量、高频次把改动合入主干：分支极短（小时到天）或直接提交主干，配套自动化测试与特性开关。
发布打标签流程
发布动作的顺序：确认分支与版本号 → 打附注标签 → 推送标签 → 触发流水线 → 生成发布说明；标签是发布点的可追溯锚点。
Fork 协作模型
外部贡献不直接写入上游仓库：Fork 到自己的命名空间开发，再向上游提 PR/MR，权限边界清晰。
分支命名约定
给分支起可检索的名字：前缀 + 简短描述（如需带工单号），常见前缀有 feat/ fix/ hotfix/ release/。
热修复分支流程
线上紧急修复的专用通道：从发布标签切分支、最小改动、加急评审、打补丁标签，并把修复回流主线。
GitHub 分支保护规则
对主干等分支设置保护：要求 PR 合并、必需评审、必需状态检查与线性历史，阻止直接推送绕过评审。
按合并状态与包含关系筛选分支
反查分支与提交关系：--contains 列出包含某提交的分支、--merged/--no-merged 按合并状态过滤，发布排查常用。
主干开发与持续集成配合
每次合入都触发完整流水线，主干保持绿色；失败立即修复或回滚，是主干模式成立的前提条件。
变更日志规范（Keep a Changelog）
给使用者看的版本化说明：按版本分组，用 Added/Changed/Fixed 等类型记录可感知变化，而不是流水账式提交罗列。
同步上游分支
让本地与 Fork 跟上上游：fetch upstream → 快进本地 main → 推送 Fork → 在特性分支上变基到上游基线。
git branch -m 分支改名
修改本地分支名：-m <新名> 或 -m <旧名> <新名>；远端同步需要「推新分支 + 删旧分支」两步。
分支模型选择参考
按交付节奏、并行版本数与回滚要求选模型：持续部署偏轻量流程，版本化交付用发布分支，复杂场景再考虑完整 GitFlow。
回滚策略与决策
回滚有两层：代码层用 revert 生成反向提交，部署层回退到上一版本制品；同时明确触发条件与决策人。
发布说明与平台 Release
GitHub/GitLab 的 Release 把标签、说明与制品绑定：可先自动生成候选说明，再人工补充升级注意事项与已知问题。
GitLab 保护分支与合并控制
控制谁能推送、谁可合并以及是否允许强推；与合并请求审批、流水线门禁组合，约束主干合入路径。
分支与标签的区别
分支是可移动指针（继续接收提交），标签是固定锚点（指向某次提交不变）；开发用分支、发布用标签。
分支列表排序
git branch --sort 按提交日期、作者等排序，配合 -v 显示最新提交；巡检时快速发现长期未动的分支。
环境分支模式
用 pre-production、production 等分支对应部署环境，代码逐级合并推进；结构直观，但合并链路会变长。
版本号提升规则落地
把提升规则变成团队例行动作：修复升 PATCH、兼容新增升 MINOR、不兼容改动升 MAJOR；破坏性改动显式标注。
分支清理例行化
合并即删、过期即查：本地与远端分支定期清理，控制列表规模，降低推错分支与误合并概率。
发布列车节奏
固定节奏发车：到点验收通过的改动随车发布，未就绪的顺延下一班；计划性强、协调成本可控。
发布冻结期管理
发布前短暂冻结：发布分支只接受阻断级修复，其他改动继续走主干常规流程；窗口要短、规则要明确。
默认分支改名（master → main）
把默认分支改名为 main 类约定：平台侧调整默认分支与保护规则，本地与 CI 脚本同步更新引用。
分支同步策略（rebase 或 merge）
本地分支与主线同步的两种口径：rebase 保持线性、评审差异干净；merge 保留时间线、无需强推；团队需要统一约定。
发布检查单
把发布前必做项列成清单：版本号与标签、变更说明、配置与迁移、回滚方案、通知与值守，逐项确认降低遗漏。
预发布版本号
在版本号后附加连字符标识预发布状态（如 1.0.0-rc.1、2.0.0-beta.2）；按规范其排序低于对应正式版本。
长期支持（LTS）分支维护
为特定版本提供更长维护窗口：用 maint/x.y（或 release/x.y）分支承接安全与阻断级修复，并公开支持截止时间。
孤儿分支（gh-pages 等独立历史）
创建没有父提交的独立分支，用于静态站点发布（gh-pages）或独立制品，与主线历史互不干扰。
签名标签与验证
对发布标签做密码学签名：-s 使用默认密钥、-u 指定密钥；接收方用 git tag -v 验证，发布来源可核验。
特性开关与主干开发
用开关解耦「合入主干」与「对用户放量」：代码尽早合入，功能默认关闭，按灰度逐步打开。
日历版本号 CalVer
用日期构造版本号（如 2026.10.0、2026.10.12）：发布频率高的产品能直观看到时间维度，也可与语义化规则组合。
保护发布标签
在平台将发布标签设为受保护引用：限制创建、删除与覆盖权限，防止发布点被误改或误删。
DORA 交付效能指标
四项指标观察交付效能：部署频率、变更前置时间、变更失败率、恢复时长；用趋势暴露流程与自动化缺口。
GitFlow 工具封装
git-flow（AVH edition 等实现）提供 feature/release/hotfix 子命令封装常见流程；不用工具也能按同一约定手工操作。
里程碑（Milestone）规划
把一批议题与合并请求挂到同一目标（如 v2.5），追踪完成比例与截止时间；发布前核对剩余项决定顺延或移出。
发布审计与追溯
把「标签 + 签名 + 发布说明 + 流水线记录」串成发布链路：出现问题时能回答「当时构建的是哪个提交、经过哪些检查」。
合并变基与冲突71 条
merge/rebase/cherry-pick 与冲突解决
git merge 合并分支热门
把一个或多个分支的提交并入当前分支：可快进时默认移动指针前进，否则生成合并提交；合并前先确认工作区干净，冲突未解决前不要提交。
git rebase 变基重放提交
把当前分支的提交在目标分支顶端逐个重放，得到线性历史；适合个人分支同步主干，不要对已共享的分支做变基。
冲突标记的结构与处理
三方合并失败时 Git 把冲突段落写进文件：<<<<<<< 当前分支、======= 分隔、>>>>>>> 对方分支；解决即人工决定保留内容并删除标记。
git rebase -i 交互式整理提交
在编辑器中列出待重放提交的 todo 清单，可重排、合并、改写、删除提交，是整理分支历史的标准入口。
git merge --abort 中止合并
放弃进行中的合并，把工作区与索引恢复到合并前状态；仅在合并因冲突暂停、尚未提交时可用。
变基还是合并：选择依据
关键判断是「分支是否已共享」与「要不要保留真实集成拓扑」：私有分支重写历史可读性好，公共分支合并更安全。
git merge --continue 完成合并
冲突全部解决并 git add 之后，用它提交合并结果；它与直接 git commit 等价，Semantics 上更明确地表示在推进暂停的合并。
标记冲突已解决并完成操作
冲突文件的解决动作就是 git add（删除文件用 git rm），全部处理后按所处状态收尾：merge --continue 或 rebase --continue。
git cherry-pick 拣选提交
把其他分支的指定提交复制到当前分支，生成内容相同但哈希不同的新提交；常用于把修复同时带到多个版本分支。
git merge --no-ff 保留合并记录
强制生成合并提交，即使可以快进也保留分支拓扑，便于在历史中看出「某组提交作为一个特性」被整体合入；merge.ff=false 可设为默认。
交互式变基 todo 命令表
todo 清单每行可用的指令：pick、reword、edit、squash、fixup、drop、exec、break、label、reset、merge；掌握其中常用几个即可覆盖九成场景。
变基后的安全强推
变基改写了本地分支，推送需要 --force-with-lease：只有在远端仍是你上次看到的位置时才覆盖，降低覆盖他人提交的风险。
git merge --squash 压缩合并
把被合并分支的净差异压成一次「已暂存待提交」的改动，不产生合并提交也不记录父子关系，适合把杂乱的临时分支整理后并入。
变基中断的继续、跳过与放弃
变基过程中遇到冲突或 edit 暂停：解决后 --continue 推进，--skip 放弃当前提交，--abort 回到变基前状态。
git merge --ff-only 只允许快进
当无法快进时直接失败退出，用于保持线性历史或校验「本地分支确实落后于远端」：能快进说明本地没有分叉提交。
冲突时按文件取 ours/theirs
git checkout --ours/--theirs 把单个文件整体取成某一边的版本，用于「整文件以一侧为准」的场景（如锁文件、生成物）。
公共分支不要改写历史
在已推送并被他人拉取的分支上做变基，会让旧提交与重写后的提交并存，制造分叉与重复变更；公共分支只追加提交。
git merge 合并策略选择
git merge 支持多个底层策略：ort（当前默认）、resolve、recursive（历史默认别名）、octopus、ours、subtree；日常几乎只用默认，特殊场景才显式指定。
merge.conflictStyle=diff3 显示共同祖先
默认冲突样式只显示两方版本；切到 diff3 会额外展示 ||||||| 标记后的共同祖先内容，帮助判断双方各自改了什么。
git rebase --autosquash 自动折叠修复提交
与 git commit --fixup/--squash 配合：交互式变基时把 fixup!、squash! 前缀的提交自动排到目标提交之后并标记折叠。
git merge -X ours 冲突块取本分支
双方改到同一区域时，自动选择当前分支一侧的内容而不报冲突；未冲突部分照常合并，是「以我为主」的产线救急手段。
提交前检查冲突标记残留
提交或推送前用 git diff --check 与检索方式扫出 <<<<<<< / >>>>>>> 残留，避免把冲突标记提交进仓库。
git rebase --onto 精确搬移提交
用 --onto 指定新基线与起点，把一段提交从旧位置搬到新位置；典型用途是把误开在错误分支上的提交摘出来。
git pull 的合并与变基配置
pull.rebase 控制 git pull 默认用 merge 还是 rebase：true=变基、false=合并、merges=仅非快进时变基；先想清楚团队策略再设。
git merge --no-commit 预览合并结果
执行合并但因不满足快进条件而暂停在提交之前，便于先检查自动合并是否引入问题，再决定提交或中止。
git merge -X theirs 冲突块取对方版本
双方改到同一区域时自动采用被合并分支一侧的内容，其余改动照常并入；常用于把上游/模板分支更新进本地既有定制。
git pull --ff-only 只快进拉取
拉取时不产生合并提交：远端领先则直接快进，分叉则失败并提示；适合要求线性主干、避免本地随意合并的团队。
git merge 的 ort 策略
ort 是当前默认合并策略，相比 recursive 在重命名、目录改名与长文件列表上更不容易误判，可显著减少「改了却没检测到」的假冲突。
git mergetool 图形化解决冲突
调用外部合并工具逐文件处理冲突；可用 --tool 指定工具，mergetool.keepBackup 控制是否保留 .orig 备份文件。
git commit --fixup 生成修补提交
为指定提交创建 fixup! 前缀的修补提交，之后配合 rebase --autosquash 自动折叠到目标提交，避免反复改写历史。
git merge-base 找共同祖先
计算两个（或多个）提交的合并基础，即分叉点；用于确认分支从哪里分开、构造 rebase --onto 范围与排查合并范围异常。
交互式变基拆分提交
把一个大提交拆成多个：在 todo 中把该行改为 edit，停下后用 git reset HEAD^ 退回到暂存前，再分批暂存提交。
双点与三点差异的区别
git diff A..B 比较两个端点；git diff A...B 比较 A 与「A、B 的共同祖先」到 B 的差异，评审 PR 常用三点视角只看引入的变更。
git merge 忽略空白差异
跨平台协作时行尾与缩进差异会制造大量伪冲突，-X ignore-space-change / ignore-all-space 可在冲突判断时忽略空白变化。
二进制文件冲突处理
二进制文件无法逐行合并，冲突时只能整份二选一；配合 .gitattributes 标记 binary 或为特定类型指定专用合并驱动。
交互式变基重排提交顺序
调整 todo 清单行的顺序即可改变提交应用顺序；用于把相关提交聚在一起，但要注意提交间可能存在依赖。
revert 合并提交（-m）
撤销合并提交必须指定保留哪个父提交：git revert -m 1 <合并提交> 表示「回到主干侧父提交的样子」，之后再要合并该分支需先撤销这次 revert。
git merge --allow-unrelated-histories 合并无共同祖先
两个独立初始化的仓库合并时会因「refusing to merge unrelated histories」被拒；该选项显式放行，常用于把旧仓库历史并入新仓库。
git ls-files -u 查看未合并条目
按索引冲突阶段列出所有未解决文件（stage 1 共同祖先、2 我方、3 对方），适合脚本化统计冲突规模与批量处理。
git log --merge 查看冲突来源
冲突暂停时用 --merge 过滤出「两方历史上真正改过」的提交，快速定位是谁、因为哪些提交引入了冲突。
git rebase --autostash 自动寄存改动
变基前自动把未提交改动暂存、结束后恢复，避免因工作区不干净而中断；结果冲突时需手动处理恢复的改动。
git rebase --exec 逐提交验证
在每条提交重放后执行指定命令（如测试），任一失败即暂停在对应提交；适合清理分支时确认每步都是可用状态。
git range-diff 对比两次变基的结果
比较同一段提交在两个版本（如变基前后、两个 MR 分支）之间的对应关系，回答「这次强制推送改了什么」。
git merge -s ours 记录合并但不取内容
生成一个合并提交、但结果树保持当前分支不变，用来「宣告某分支已被吸收」；旧分支的内容不会进入主干。
merge.conflictStyle=zdiff3 精简版 diff3
zdiff3 在 diff3 基础上把两侧相同的行移出冲突块，冲突段更紧凑；Git 2.35 起可用，适合大段重复代码的仓库。
冲突期间的 diff 用法
冲突暂停时 git diff 的语义与平时不同：默认显示组合差异；--ours/--theirs 比较工作区与某一侧，-1/-2/-3? 走索引阶段对比。
git rerere 重用冲突解决结果
记录冲突片段及其解决方式，之后再遇到相同冲突自动套用；适合长期维护补丁分支、反复同步上游的团队。
git rebase --rebase-merges 保留合并结构
默认变基会拍平合并提交；--rebase-merges 在重放时重建分支与合并结构，适合整理包含合并的复杂分支。
git commit --squash 生成待合并提交
与 --fixup 类似但保留信息：生成 squash! 前缀提交，autosquash 时折叠到目标提交并打开编辑器合并两条信息。
cherry-pick 拣选一段提交
支持单个提交列表、A..B 区间与 A^..B 写法；按顺序逐个应用，任何一步冲突都会暂停等待处理。
git merge 重命名检测选项
合并时 Git 会尝试识别重命名并跨文件名合并；-X find-renames=<阈值> 调整敏感度，merge.renames 可关闭检测（不推荐）。
git show :1:/:2:/:3: 读取冲突三版本
冲突时索引保存三个版本：:1: 共同祖先、:2: 当前分支、:3: 对方；用 git show 可分别查看，配合 diff 精确理解差异。
git rebase --update-refs 同步堆叠分支
变基时同步更新下游分支引用，保持堆叠分支（stacked branches）的父子关系；Git 2.38 起可用。
git cherry-pick -x 记录来源
在生成的提交信息末尾附加 (cherry picked from commit <哈希>) 注记，方便追溯来源，是向维护分支回移补丁时的常见要求。
合并提交信息规范
默认信息形如 Merge branch 'feature/x'；支持在信息中补充来源与单号（如 Merge branch 'feature/x' into 'main'、See merge request !42），便于追溯。
git merge 章鱼式合并多分支
一次把多个分支同时并入当前分支（octopus 策略）；只在没有冲突时可用，适合发布前批量并入互不重叠的分支。
git merge-tree 预演合并与冲突
不改变工作区即可试算两个分支的合并结果：可只输出冲突信息，也可在对象库中写出合并树，用于 CI 或脚本检查「能否干净合并」。
避免「暗改式」合并提交
合并冲突时常有人顺手夹带无关改动（业内称 evil merge），这类内容不体现在任一方提交里，评审与 bisect 都难以发现。
git merge -s subtree 子目录对齐合并
把对方仓库内容对齐到当前仓库的某个子目录进行合并，用于没有子树元数据的「库中库」场景；新项目更推荐 git subtree 或子模块。
git merge 指定差异算法
冲突块的行对齐方式由差异算法决定；-X diff-algorithm=histogram 或 patience 在重复代码较多的文件上通常更易读。
git checkout --conflict 重做冲突标记
解决过程把文件改乱后可让 Git 重新写入冲突标记：--conflict=merge|diff3|zdiff3 指定样式，等同于按当前样式重新生成。
自定义合并驱动：keep-ours
对版本号、锁文件等总是「保留当前分支」的文件类型，可在 .gitattributes 里绑定自定义 merge 驱动，让合并自动保留本地版本。
git cherry-pick -n 只应用不提交
把拣选的改动写入工作区与索引但不生成提交，便于先修改内容、合并多个提交或重新编写提交信息。
自定义合并驱动：union 并集合并
union 驱动把双方新增行都保留，适合变更日志、清单等「累加式」文本；在 .gitattributes 中对目标文件启用 merge=union。
git rebase --root 从首个提交开始整理
以仓库根为基点重放整段历史，用于整理初始提交（如修正首个提交的信息或合并最初几条提交）。
cherry-pick 合并提交（-m）
合并提交有两个父提交，拣选时必须用 -m 指定以哪个父为主线；-m <父编号> 表示相对该父提交重放此合并引入的差异。
git cherry 对比两条分支的提交
按 patch-id 对比，列出哪些提交已在目标分支有等价改动（以 - 标记）或尚未包含（以 + 标记），辅助判断回移是否已做过。
rerere 自动更新与撤销
rerere.autoUpdate=true 时自动把已记录的解决结果写入索引；也可用 rerere-autoupdate 选项临时控制，配合 rerere forget 纠错。
变基中的空提交与 --empty
重放后内容已被上游包含的提交会变成空提交；用 --empty=drop|keep|stop 控制行为，避免历史里出现无意义空提交或意外停下。
git rerere forget 清理错误记录
当某文件的冲突解决方式被错误记录后，用 rerere forget 删除对应缓存，让下一次冲突回到手工判断。
git rebase --keep-base 复用原合并基础
保持原分支的合并基础不变，只重放本分支提交；用于「上游有新提交但不想改变分叉点」的同步场景。
协作与代码评审75 条
PR/MR 流程、评审规范与提交约定
Conventional Commits 提交规范
给提交信息定结构：<type>[scope]: <description>，正文与页脚用空行分隔；让变更可被工具解析，用于自动生成变更日志与版本号。
评审结论的三种状态
GitHub 支持 Comment（仅评论）、Approve（通过）、Request changes（要求修改）；GitLab 对应评论、批准、要求修改（依据版本与设置）。
提交类型（type）常用对照
feat/fix 是规范定义的核心类型，其余 build、chore、ci、docs、style、refactor、perf、test 等来自社区与 Angular 约定，按团队词典统一使用。
gh pr create 创建拉取请求
GitHub CLI 创建 PR：支持指定基分支、标题正文、草稿、评审人；未推送的分支会提示先推送，适合把创建动作放进脚本。
代码评审检查清单
评审先看正确性与安全，再看设计可维护性，最后才是风格细节；用固定清单减少遗漏，也便于新人快速形成评审习惯。
破坏性变更的两种标注
不兼容改动有两种写法：type 或 scope 后加感叹号（feat!、feat(api)!），或在页脚写 BREAKING CHANGE: 描述；两者都可触发主版本号升级。
commitlint 校验提交信息
用 @commitlint/cli 配合 @commitlint/config-conventional 校验提交是否符合约定；本地钩子拦截、CI 全量检查都能用。
PR/MR 描述要素
一份可评审的描述通常包含：变更目的、实现要点、验证方式、影响面与风险、关联单号；写清这些能减少来回追问。
平台合并方式：合并提交 / 压缩 / 变基
GitHub 与 GitLab 都提供多种合并按钮：保留合并提交、squash 合并、rebase 合并；仓库可启用哪些方式属于管理员设置，团队需统一约定。
提交类型到版本号的映射
按规范：fix 对应 PATCH、feat 对应 MINOR、破坏性变更对应 MAJOR；工具据此自动决定下一个发布版本，避免人工拍版本号。
从提交历史生成变更日志
用 git log 按版本区间与提交类型提取条目，快速生成变更日志初稿；配合提交规范可以让分组自动化。
关联与自动关闭 Issue 的关键字
在 PR/MR 描述或提交信息里使用 Closes/Fixes/Resolves 加编号，合并时自动关闭对应 Issue；GitLab 支持 Fixes #、Closes #、Resolves # 等。
请求评审人（reviewers）
创建 PR/MR 时或之后指派评审人：个人、团队/组均可；GitHub 支持 CODEOWNERS 自动请求，GitLab 支持审批规则自动指派。
commit-msg 钩子接入提交校验
在 .git/hooks/commit-msg（或 core.hooksPath 统一目录）里调用校验器，提交信息不合格时直接拒绝提交，把规范前移到本地。
glab mr create 创建合并请求
GitLab CLI 创建 MR：可指定源/目标分支、标题描述、草稿状态、评审人；也支持用 --fill 从提交与分支名生成描述。
CODEOWNERS 语法与位置
CODEOWNERS 文件按路径模式声明负责人：每行「模式 + 所有者」，用 ! 排除路径，后出现的规则优先；GitHub 读取 .github/、根目录或 docs/ 中的该文件。
小批量变更更利于评审
评审质量随 diff 规模下降：几百行以上的一次性审读容易漏问题。把功能拆成可独立合入的小 PR，是提升评审效率的直接手段。
提交页脚与关联信息
页脚用于附加机器可读信息：BREAKING CHANGE、引用 Issue（Refs、Closes）与其他 trailer；token 中的空格用连字符替代。
GitHub 建议修改块（suggestion）
在评论里用 suggestion 代码块给出可直接采纳的替换内容，作者点 Commit suggestion 即可应用，省去手工复制。
Squash 合并的提交信息约定
平台执行 squash 时默认用 PR/MR 标题作提交标题（GitHub 可自定义 Message），正文可包含各条提交摘要与关联单号；标题质量直接影响主干历史。
GPG 提交签名与配置
用 GPG 对提交与标签签名，平台显示 Verified 标识；配置 commit.gpgsign 可自动签名，密钥上传到平台后才显示验证状态。
Conventional scope 范围写法
scope 用括号标注影响范围（模块、包、目录），面向单仓多模块项目尤其有用；范围名建议与目录/包名一致，便于按范围筛选提交。
草稿 PR / Draft MR
未完成的变更先开草稿：GitHub 用 Convert to draft 或 --draft，GitLab 用 Draft: 前缀；草稿状态通常不触发必需评审与合并队列。
GitHub 必需评审与代码所有者评审
受保护分支可要求合并前至少 N 名批准，并可额外要求代码所有者批准；两者叠加时需同时满足。
评审沟通的语气与方式
对事不对人：询问意图、给出依据、提出替代方案；把「你这样不对」换成「这里如果输入为空会怎样？」更容易达成共识。
GitHub 合并队列（merge queue）
高流转仓库用合并队列按序验证待合入 PR：队列为每个 PR 构造临时分支并重跑必需检查，成功后按序合入，避免「各自测试通过、合并后主干失败」。
本地检出 PR 代码做评审
评审复杂改动时在本地检出 PR 分支：运行构建与测试、用熟悉 IDE 看上下文；gh/glab 均提供一条命令检出对应分支。
PR 模板文件（GitHub）
把评审检查项固化为模板：.github/pull_request_template.md 对全部 PR 生效；也可用 .github/PULL_REQUEST_TEMPLATE/ 目录放多个模板按 URL 参数选用。
重新请求评审（re-request review）
按评审意见修改并推送后，点击 Re-request review 或在命令行重新请求，明确告知「有新版本」而不是让对方去猜改动是否完成。
会话解决与会话未解决提示
行内评论形成会话（conversation），处理完成后标记 Resolved；GitHub 可开启合并前必须解决全部会话，GitLab 类似设置按项目配置。
GitLab 审批规则（approval rules）
在项目设置中定义合并请求审批规则：指定审批人数、适用分支、是否重置、是否包含代码所有者，可叠加多条规则。
在评审中标注 nit 与阻塞项
用 nit: 前缀标出不阻塞的小建议，用 must/阻塞 明确合入条件；统一用语能减少「到底要不要改」的反复确认。
GitHub 自动合并（auto-merge）
开启仓库的 Allow auto-merge 后，PR 可在满足全部合并条件时自动合入：适合等待 CI 与审批完成后无需人工点击的场景。
用 gh 查看 PR 状态与检查
命令行巡检 PR：gh pr status 看自己相关的 PR，gh pr checks 看检查结果，gh pr view 看详情；脚本化批量巡检时配合 --json 输出。
DCO：开发者原创声明
DCO（Developer Certificate of Origin）要求每次提交带 Signed-off-by 声明有权提交该代码；许多开源项目用机器人校验，缺失或信息不符会拒绝合入。
评审期间更新 PR 的推送策略
评审期间优先追加提交（保留增量视图），待批准后再整理历史；若必须强推（rebase 同步主干），在 PR 里说明改动范围并请求重新评审。
代码评审中的安全要点
评审时优先看四类高风险面：输入校验与注入、认证授权、密钥与敏感数据处理、依赖引入；发现问题按私下渠道报告而不是公开评论。
revert 提交的写法
回退提交约定用 revert: 前缀，标题引用被回退的提交标题；git revert 默认生成 Revert '...' 信息，可按团队规范调整。
变更日志分组结构
常规做法按「新增 / 修复 / 破坏性变更」分组，必要时补「性能」「文档」「内部」；分组名与提交类型对应，保持长期稳定。
查看「上次评审以来的改动」
评审人复核时只看增量通常更高效：GitHub 有 View changes since last review，GitLab 支持与上一版本对比（Compare with previous version）。
堆叠式 PR（stacked PR）
把大改动拆成一串有先后依赖的 PR，每个都基于前一个分支：评审粒度小、可逐个合入，合并时按顺序从底部向上推进。
Rebase and merge 的行为与限制
GitHub 的 Rebase and merge 把 PR 内提交逐个重放到目标分支（无合并提交）；若提交间存在互相冲突的历史，平台会要求先同步分支。
来自 Fork 的 PR 审批与运行策略
外部贡献者通过 Fork 发起 PR 时，工作流可能默认需要维护者批准后才运行，且密钥不注入：这是防滥用设计，不是配置错误。
用 fetch 拉取 PR 的引用
不依赖 CLI 也能取到 PR 代码：GitHub 把 PR 头部暴露为 refs/pull/<编号>/head，按引用拉取即可用于对比或本地复现。
git commit -s 添加签署行
在提交信息尾部追加 Signed-off-by: 作者名 <邮箱>，与 DCO 配套；也可在 merge、revert 等操作时附带签署。
协作署名 Co-authored-by
两人及以上共同完成一次提交时，在提交信息末尾添加 Co-authored-by: 姓名 <邮箱>；平台会把协作作者计入贡献统计（邮箱需匹配账号）。
审批与合入的角色分工
常见约定：评审人负责批准，维护者或作者按仓库规则执行合入；作者自批、无审批合入需要仓库策略支持，并会留下记录。
MR 模板文件（GitLab）
GitLab 使用 .gitlab/merge_request_templates/ 目录存放模板，新建 MR 时从下拉选择；实例级模板可统一组织规范。
GitLab CODEOWNERS 与代码所有者
GitLab 同样支持 CODEOWNERS 文件定义代码所有者，并可将其接入审批规则与受保护分支，实现按目录强制审批。
推送后撤销过时审批
开启「Dismiss stale pull request approvals when new commits are pushed」后，新提交会清空已有批准，确保批准对应的是评审过的代码版本。
把大型 PR 拆成可评审单元
先梳理改动树，再按「可独立合入且可回滚」的边界切分；常见切法：按提交重排拆分、先落接口与开关、机械改动单独一 PR。
MR 流水线（merge request pipelines）
GitLab 为合并请求单独运行流水线：只在 MR 上下文触发，按规则限定在源分支为目标分支的场景，避免每次推送都跑全量分支流水线。
更新分支以符合「须为最新」要求
目标分支前进后，落后分支会因「需与目标分支同步」被阻塞；用 Update branch（合并方式）或 Rebase branch 更新，并在更新后重跑检查。
用 SSH 密钥签名提交
Git 2.34 起支持 gpg.format=ssh：用已有 SSH 密钥签名，配置 allowedSignersFile 做本地验证，平台侧需上传同一公钥并启用。
验证提交签名
本地用 git log --show-signature 或 git verify-commit 检查签名有效性；平台上的 Verified 徽标表示签名密钥已在账号中登记。
批量评审与一次性提交结论
先把零散意见写成待提交评论（GitHub Start a review / Add review comment），全部看完再一次性提交，避免评审人在半成品结论间反复被打断。
PR/MR 标题规范
以 squash 为主的仓库，PR 标题会成为主干提交标题：沿用提交规范（type(scope): 描述），并在 CI 里用规则校验 PR 标题。
GitLab 建议修改（suggestions）
GitLab 行内评论同样支持 suggestion 代码块，作者可 Apply suggestion 或 Apply suggestions 批量应用；应用后提交会记到 MR 里。
CODEOWNERS 匹配优先级
除「后定义优先」外，模式匹配按路径生效；全局 * 兜底时目录级规则要写在后面才能覆盖，团队与个人可混合指定。
必需状态检查与「分支需最新」
要求指定 CI 检查通过才能合并；勾选 Require branches to be up to date 后，分支落后于目标分支时需先更新再合并，避免脏合并。
评审响应节奏与期望管理
评审是协作瓶颈之一：约定响应时限（如工作日内 4 小时给出初步意见）、标注紧急程度、必要时切换同步沟通，能显著缩短合入周期。
GitLab 合并列车（merge trains）
在目标分支要求快进合并且启用合并列车后，多个 MR 按顺序与前一结果组合验证，减少「前一个合并导致后一个失败」的互相等待。
作者（author）与提交者（committer）的区别
作者是写改动的人，提交者是实际执行提交的人；平台按两者分别展示（committed by / authored by），rebase、打补丁等操作会改变提交者。
PR/MR 标签与分流
用标签表达类型、优先级与状态（kind/bug、priority/P1、status/review-needed），支持按标签筛选与自动化：GitHub 可用 labeler 配置按路径自动打标。
用 gh 批量巡检与分流 PR
命令行按作者、标签、状态过滤 PR，输出列表或 JSON，把「谁在等评审、哪些被阻塞」变成一次查询。
git format-patch 生成补丁文件
把提交导出为邮件格式补丁（含作者、提交信息与差异），用于无平台协作的评审、跨网络传递或离线归档。
CONTRIBUTING 贡献指南
在仓库放 CONTRIBUTING.md 说明提交流程：分支命名、提交规范、测试要求、评审与发布节奏；GitHub 会在新建 Issue/PR 时提示查看它。
拉取 GitLab MR 的引用
GitLab 将 MR 头部暴露为 refs/merge-requests/<iid>/head，合并结果位于 refs/merge-requests/<iid>/merge，命令与 GitHub 类似。
评审署名 Reviewed-by
部分平台与项目在合并记录里保留 Reviewed-by trailer（如 GitLab 在 squash/合并时写入批准者），用于追溯由谁完成评审。
新提交重置审批的设置
GitLab 可配置推送新提交时移除已有批准（Reset approvals on push），确保批准对应评审过的版本；关闭它则需要额外的「最后推送人不可批准」类约束。
git am 应用补丁邮件
把 format-patch 生成的补丁（或 .mbox 邮件）应用到当前分支，保留原作者与提交信息；冲突时用 --3way 或手动解决后 --continue。
Issue 分流与模板
用 Issue 模板收集必要信息（版本、复现步骤、日志），用标签与负责人机制分流；明确「需要更多信息」的闭环，避免 Issue 长期悬空。
CLA：贡献者许可协议
部分项目/公司要求贡献者先签署 CLA，授权项目按特定条款使用贡献；通常由机器人检查并在首次 PR 时提示签署流程。
git interpret-trailers 处理页脚
解析与增删提交信息的 trailer（键值页脚）：--parse 输出结构化结果，--trailer 追加字段，可用于钩子里自动补充关联信息。
git request-pull 生成拉取请求摘要
为基于 Git 地址的协作生成一段可直接发送的摘要：包含区间提交列表、统计与差异，用于邮件列表或工单中请对方拉取。
进阶与大仓实践69 条
子模块、LFS、稀疏检出与仓库性能
git lfs 安装与大文件跟踪
用 Git LFS 把大文件（模型、素材、二进制包）存到外部存储，仓库里只保留指针；git lfs install 配置钩子，git lfs track 声明模式。
git submodule add 引入子模块
把外部仓库以固定提交的形式嵌入当前仓库：父仓库只记录子模块的 URL、路径与提交指针，子模块内容单独克隆。
git sparse-checkout 稀疏检出
只检出仓库的一部分目录到工作区（锥形模式默认按目录），其余文件仍留在版本库中；大仓开发常与部分克隆搭配使用。
历史改写的风险与收尾清单
重写会改变提交哈希并影响所有克隆、分支、标签与 CI 缓存；收尾至少包含：引用更新、reflog 过期、gc 清理与团队通知。
子模块的初始化与更新
克隆后子模块目录默认是空的：git submodule init 登记配置，git submodule update 检出父仓库记录的提交；也可一步 --init --recursive。
gc 与自动回收参数
git gc 合并包与清理不可达对象；gc.auto 控制自动回收阈值，gc.auto 设为 0 可关闭自动触发，大仓改用 maintenance 计划任务更可控。
git-filter-repo 重写历史
官方文档推荐的仓库历史改写工具（独立脚本）：可删除文件、替换文本、按目录拆分；要求尽量在新鲜克隆上操作并复核结果。
大仓日常开发工作流
面向多人共用的单仓：用部分克隆省首次下载、用稀疏检出限定工作目录、用 maintenance 维持性能；提交前注意只影响自己负责的目录。
部分克隆（--filter=blob:none）
克隆时只取提交与树、不取文件内容，检出或读取时再按需下载对应对象；显著降低首次克隆体积，适合大仓与 CI。
commit-graph 加速历史遍历
把提交的父子关系与序号写入图形文件，git log、merge-base 等历史类命令可显著提速；git gc 会顺带生成，也可手动写入与校验。
Git 钩子总览
钩子在提交、推送、合并等关键时刻自动执行：客户端钩子（pre-commit、commit-msg、pre-push 等）与服务端钩子（pre-receive 等）用途不同。
git repack 手动重打包
把松散对象与多个包合并为更少、更紧凑的包；常用 -a -d -b 组合（全量、删除冗余、写位图），大仓可改用 maintenance 的增量重打包。
git worktree 多工作区
同一个仓库同时检出多个工作区：在不同目录并行处理多个分支，共享对象库与配置，省去重复克隆与来回切分支。
仓库体积治理清单
体积治理按「定位 → 归因 → 治理 → 防复发」推进：先找大对象，再决定迁 LFS、移出历史或改为制品管理，最后用规范与检查防止复发。
子模块与子树的选择
子模块保留对方完整仓库与独立历史，适合工具库与可复用组件；子树把代码并入本仓库目录，单仓克隆即可构建，代价是历史合并噪声与更新需要显式命令。
把既有大文件迁移进 LFS
git lfs migrate import 把历史提交中的匹配文件改写为 LFS 指针；先 migrate info 查看候选与体积，再决定是否重写历史。
git maintenance 例行维护
统一的大仓维护入口：注册仓库后按天/小时执行 gc、commit-graph、prefetch、incremental-repack 等任务，替代手工跑 gc。
pre-commit 钩子的典型用法
提交前跑轻量检查：格式化、静态检查、敏感串扫描；原则是快（秒级）且可局部运行，慢检查放 pre-push 或 CI。
替换历史中的文本与凭证
用 --replace-text 按规则文件批量替换历史里的敏感串（如令牌、密钥、内部域名）；替换规则支持字面量、正则与整行替换。
git submodule status 查看子模块状态
输出每个子模块当前提交与父仓库记录的差异：前缀 - 表示未初始化、+ 表示提交不一致、U 表示合并冲突，是排查子模块问题的常用入口。
CI 中拉取子模块
流水线默认浅克隆不含子模块：需要 --recurse-submodules 并按需加深历史；私有子模块要在同一凭据体系下可访问，否则构建会卡在拉取。
LFS 的 .gitattributes 条目
track 生成的条目形如 <模式> filter=lfs diff=lfs merge=lfs -text：filter 负责指针转换，diff/merge 走 LFS 专用逻辑，-text 关闭行尾转换。
浅克隆的加深与补全
浅克隆（--depth）只有部分历史：git fetch --deepen=N 追加 N 层，git fetch --unshallow 取回全部历史；需要标签或 blame 时按需补。
定位历史中的大文件
用 rev-list --objects 列出全部对象并交给 cat-file --batch-check 统计大小，是找出「历史里是谁把仓库撑大」的常规手段。
从历史中删除文件或目录
用 --path 指定目标并用 --invert-paths 反选即可删除该路径的全部历史；误提交的大文件、构建产物、内部资料都可通过此方式清理。
GitHub 大文件限制与应对
GitHub 对单文件推送有硬限制：超过 100 MiB 的推送会被拒绝，超过 50 MiB 会给出警告；大文件应改用 Git LFS 或制品库。
CI 浅克隆与按需加深
流水线常以 depth=1 起步：只取最新提交；依赖历史信息（版本号、变更日志、diff 范围）的任务需要显式加深或切换完整克隆。
git submodule foreach 批量操作
对每个子模块执行同一条命令，适合批量拉取、查看状态或统一切换分支；提供 $name、$path、$sha1 等变量。
子模块的提交指针模型
父仓库中的子模块记录的是「子树对象指向某次提交」，不是分支：切换父仓库分支会带着指针变化，理解这点才能正确更新与回滚子模块。
git subtree add 引入子树
把外部仓库内容合并到当前仓库的指定前缀目录；带 --squash 可只保留一次压缩提交，减少历史噪声。
LFS 内容的拉取与按需获取
克隆/拉取时 LFS 会自动下载所需对象；可用 lfs.fetchinclude/exclude 或 --include/--exclude 控制范围，避免一次拉取全部历史大文件。
锥形模式（cone）的行为
cone 模式按目录层级匹配：set 指定目录及其父级目录内容，支持 add/set/reapply；规则简单可预测，是推荐使用的模式。
部分克隆的过滤级别
过滤参数可选 blob:none、blob:limit=<大小>、tree:0：粒度越粗省得越多，但读取时补下载的请求也越多，按使用场景取舍。
multi-pack-index 合并多包索引
为多个 packfile 维护统一索引（MIDX），让对象查找与仓库操作不必逐个扫描包文件；配合 bitmap 还能加速克隆与取回。
fsmonitor 加速状态查询
文件系统监控让 git status 不再全量扫描工作区：新版 Git 内置 FSMonitor（core.fsmonitor=true），在 Windows/macOS 上对大工作区收益明显。
core.hooksPath 统一管理钩子
把钩子目录指向仓库内的 .githooks，使钩子可提交、可评审；New 版本 Git 支持，切换后 .git/hooks 不再生效。
safe.directory 与 dubious ownership
当仓库目录属主与当前用户不一致（容器、sudo、共享目录常见）时，Git 会拒绝操作并提示 dubious ownership；用 safe.directory 显式放行。
gitattributes 进阶属性
除行尾与 LFS 外，属性还能控制差异显示、合并驱动、导出打包与语言统计：diff、merge、export-ignore、export-subst、linguist 等。
历史查询的性能习惯
历史类命令在超大仓库上差异明显：限定范围与路径、避免无界 --all、善用 --first-parent 与提交图形，能显著缩短等待时间。
完整移除一个子模块
顺序：deinit 清工作区 → git rm 移除 gitlink 与 .gitmodules 条目 → 删除 .git/modules/<name> 残留缓存 → 提交变更。
子模块跟踪分支与 --remote 更新
.gitmodules 中可配置 branch 指定子模块应跟踪的分支（默认跟随远端 HEAD），配合 submodule update --remote 拉取该分支并更新指针。
在 CI 中使用 LFS
CI 有两种取舍：不需要大文件内容时跳过下载（省流量提速），需要时确保 lfs 已安装并完成 fetch，否则检出的是指针文本。
稀疏索引（sparse index）
启用后索引只展开稀疏目录的树条目，git status 等命令在超大仓库更快；配合 cone 模式使用，Git 2.34 起趋于稳定。
git verify-pack 检查包内容
逐个对象列出包内类型与体积，用于定位仓库里体积异常的 blob；配合排序快速找到占用空间的对象。
服务端钩子与策略落地
pre-receive、update、post-receive 在服务端仓库执行，无法被客户端绕过，适合做强制策略（拒绝大文件、校验提交格式、触发通知）。
git submodule deinit 反初始化
移除子模块的工作区内容并清理 .git/config 中的配置（保留 .gitmodules 与 gitlink 记录），常用于临时停用某子模块或为删除做准备。
子模块 URL 变更与 sync
.gitmodules 里的 URL 修改后，各克隆的本地配置仍指向旧地址；用 submodule sync 把新 URL 同步到 .git/config 与 .git/modules 配置。
子树的更新与回推
subtree pull 拉取上游更新到前缀目录；subtree push 把本仓库中该目录的提交生成到目标分支，用于把本地改动回馈上游。
git lfs prune 清理本地缓存
删除工作区当前不需要的历史 LFS 对象，回收 .git/lfs 空间；用 --dry-run 先看将删除的清单，再决定执行。
部分克隆的使用注意点
按需拉取让「历史完整、内容不全」成为常态：离线不可用、批量读文件会触发大量请求、某些工具链需要显式预热对象。
工作区的清理与迁移
删除工作区用 remove（--force 处理有改动的目录）；需要迁移位置时先 remove 再重新 add，避免留下失效引用。
Windows 长路径支持
Windows 默认路径长度限制会让深层目录检出失败；设置 core.longpaths=true（并确认系统长路径策略）可缓解，主要在嵌套依赖与子模块场景遇到。
reflog 过期与对象清理
reflog 记录引用变动，是误操作的恢复通道；确认不再需要恢复时（如完成历史重写），过期 reflog 并 gc 才能让旧对象真正被回收。
git subtree split 拆分目录历史
把前缀目录的历史提取成一个独立分支（保留相关提交），可用于把目录拆成新仓库或作为回推中间产物。
LFS 文件锁定
对不可合并的大文件（设计稿、模型）使用 lfs lock 加锁，避免两人同时修改；locks 列表与 unlock 用于管理锁状态，需服务端支持。
关闭与调整稀疏检出
git sparse-checkout disable 恢复完整工作区并关闭稀疏模式；调整范围用 set/list，无需退出稀疏状态即可切换关注的目录。
promisor 远端与按需对象补齐
部分克隆会把远端登记为 promisor（承诺可补齐对象）；缺对象时 Git 自动从那拉取，理解它才能解释离线报错与补齐行为。
untracked cache 减少目录扫描
把「哪些目录确认没有未跟踪文件」记入索引，让 git status 少扫目录；在文件数多的仓库上对状态命令有直接收益。
git filter-branch 及其替代
旧式历史重写工具：用法复杂、速度慢，官方文档已建议改用 git filter-repo 等工具；存量脚本迁移时注意行为差异。
core.fileMode 与权限位
Git 记录可执行位：core.fileMode 控制是否跟踪文件模式变化；Windows 或跨文件系统挂载时该值常被自动置为 false，避免假性模式差异。
GitLab 仓库 Housekeeping
GitLab 会在推送后自动执行仓库整理（gc、repack 等）以控制体积；管理员也可在项目或实例层面手动触发，排查体积异常时先确认整理是否完成。
git submodule absorbgitdirs 收纳目录
把子模块目录内的 .git（文件或目录）迁移进父仓库的 .git/modules 统一管理，保持子模块目录干净、便于统一备份与迁移。
git lfs env 查看环境与端点
输出 LFS 端点、本地缓存目录与版本等诊断信息，用于排查「推到哪个存储、缓存占多少空间、配置是否被覆盖」。
feature.manyFiles 一键大仓配置
开启对大文件数仓库更合适的索引选项（如索引版本 4、未跟踪缓存等），减少逐项调参成本；可用 git config --show-origin 复核结果。
git notes 附加提交注解
在不修改提交内容的前提下给提交挂注解（评审结论、CI 结果、迁移标记）；注解存放在独立引用空间，默认不随 push 同步。
Trace2 诊断 Git 命令性能
用 GIT_TRACE2_PERF 记录命令内部耗时，定位是网络、索引还是磁盘导致慢；诊断完记得关闭，避免日志影响正常使用。
pack-refs 合并松散引用
分支与标签数量多时，松散引用文件会让引用遍历变慢：git pack-refs --all --prune 把引用打包进 packed-refs，是低风险的基础维护。
git diagnose 收集仓库诊断
一键收集仓库状态、配置与对象库摘要并打包，用于上报疑难问题；输出文件可能包含路径与配置，对外分享前先检查。
Scalar 一键大仓配置
Scalar（Git 自 2.38 起随附）为大仓提供推荐配置：克隆时启用部分克隆、稀疏检出与维护计划，减少手工调参。