第 2 卷

◦ git merge：提交历史是非线性的，会保留分支的分叉记录（可清晰看到何时创建分支、何

时合并分支）；

◦ git rebase：提交历史是线性的，会“抹平”分支分叉，看起来当前分支是在目标分支最

新版本后直接开发的（重写了提交的父节点）。

1. 使用场景差异

◦ git merge：适合**公共分支（如master/main、develop）**的合并，保留完整的分支历

史，便于追溯和回滚（不破坏公共提交历史）；

◦ git rebase：适合**个人分支/功能分支（如feature/*）**整合公共分支更新，或在合并到

公共分支前整理提交历史（使公共分支历史更整洁）；禁止在公共分支上使用rebase（会重写公共提交历史，导致其他开发者协作异常）。

1. 示例对比

• 合并（merge）：分支A → 合并分支B → 生成新合并提交C（A和B的历史均保留）；

◦ 变基（rebase）：分支A → 基于分支B最新版本变基 → 分支A的提交依次排在B最新提交之后

（无新合并提交）。

五、git pull 与 git fetch 的区别

git pull 和 git fetch 均用于获取远程仓库的最新版本，但核心差异在于是否自动合并，具体区别如下：

1. 核心行为差异（关键区别）

◦ git fetch：仅拉取，不合并。将远程仓库的最新提交、分支信息拉取到本地的远程跟踪分

支（如 origin/main），本地当前工作分支（如 main）不会发生任何变化，开发者可先对比差异再手动合并；

◦ git pull：拉取 + 自动合并。 git pull 本质上是 git fetch + git merge（默

认）的组合操作：先拉取远程最新版本到本地远程跟踪分支，再自动将远程跟踪分支的更新合并到本地当前工作分支。

1. 安全性与灵活性差异

◦ git fetch：更安全、更灵活。由于不自动合并，开发者可以通过 git diff <本地分支

> <远程跟踪分支>（如 git diff main origin/main）查看远程更新与本地分支的差异，自主决定是否合并、如何合并，避免自动合并导致的意外冲突；

◦ git pull：更便捷，但灵活性低、风险略高。适合本地分支无未提交修改、且确认远程更新

不会与本地冲突的场景；若本地有未提交修改，或远程更新与本地修改冲突，会直接触发合并冲突，增加解决成本。

• git fetch：适合谨慎的开发流程（如公共分支同步、先验证差异再合并）；

◦ git pull：适合个人开发分支快速同步远程更新（如个人feature分支拉取远程develop分

支的最新代码）。

六、Git钩子（hook）的定义与用途

1. Git钩子（hook）的定义

Git钩子是嵌入在Git工作流程中的自动化脚本（Shell、Python、Node.js等语言编写），存储在本地仓库的 .git/hooks 目录下（默认包含多个示例脚本，后缀为 .sample，移除后缀即可启用）。

Git钩子由特定的Git事件触发，无需手动执行，是Git提供的内置自动化扩展机制。

1. Git钩子的核心用途

钩子按触发时机可分为“客户端钩子”（本地操作触发）和“服务器端钩子”（远程仓库操作触发），各自用途如下：

◦ 客户端钩子（常用）

1. 提交前钩子（ pre-commit）：提交前触发，用于校验本地代码（如代码格式检查、语法

校验、是否存在调试代码、文件大小限制等），若脚本返回非0值，Git会阻止本次提交；

1. 提交信息校验钩子（ commit-msg）：提交时触发，用于校验提交说明的格式（如是否符

合“类型: 描述”的规范，是否长度达标等），不符合规范则阻止提交；

1. 合并前钩子（ pre-merge-commit）：合并操作前触发，用于校验合并的合法性，避免

无效合并。

◦ 服务器端钩子（常用）

1. 推送前钩子（ pre-receive）：远程仓库接收推送时触发，用于校验推送的提交（如是

否包含敏感信息、提交者是否有权限、代码是否通过CI校验等），不符合规则则拒绝接收推送；

1. 接收后钩子（ post-receive）：远程仓库成功接收推送后触发，用于执行后续自动化操

作（如自动部署项目、发送推送通知、同步到其他仓库、触发CI/CD流水线等）。

七、撤销Git最后一次提交的方法

根据“是否保留最后一次提交的修改”，有两种常用方案，适用于本地未推送远程的场景（若已推送远程，不建议直接撤销，避免破坏公共历史）：

1. 方案1：保留修改（仅撤销提交记录，修改保留在工作区/暂存区）

适用于提交说明写错、或遗漏部分文件需要补充提交的场景，有两种细分命令：

◦ 保留修改在暂存区（可直接重新commit）：

◦ 保留修改在工作区（需重新add再commit）：

Code block

1git reset --mixed HEAD~1# --mixed是默认参数，可省略，即 git reset HEAD~1

1. 方案2：丢弃修改（彻底撤销最后一次提交，删除所有变更）

适用于最后一次提交存在严重错误，需要完全丢弃的场景（谨慎使用，不可恢复）：

Code block

1git reset --hard HEAD~1

1. 补充：已推送远程的最后一次提交撤销（不推荐，特殊场景使用）

若已将最后一次提交推送到远程公共分支，不可使用 git reset（会重写公共历史），可使用 git revert 创建一个“反向提交”，抵消最后一次提交的修改：

Code block

八、Git大型仓库的性能优化方法

大型仓库（文件数量多、历史提交久、体积大）容易出现 git clone、 git status、 git log 等操作缓慢的问题，优化方案如下：

1. 克隆优化：减少本地仓库体积

◦ 浅克隆（Shallow Clone）：仅克隆最近的N次提交，不下载完整历史，大幅减少克隆时间和磁

盘占用：

Code block

1git clone --depth <N> <远程仓库地址># N为提交次数，如 --depth 1 仅克隆最新一次提交

◦ 单分支克隆：仅克隆指定分支，不下载其他无关分支：