Git进阶技巧

1. 分支管理

分支是Git的核心特性，允许开发者在不影响主代码的情况下进行功能开发或问题修复。

1.1 创建与切换分支


# 创建新分支（不切换）
git branch 分支名

# 创建并切换到新分支（等价于 git branch + git checkout）
git checkout -b 分支名

# 查看所有分支（当前分支前有*号）
git branch

1.2 合并分支

在目标分支（如main）执行合并操作：


git checkout main   # 切换到主分支
git merge 功能分支    # 合并功能分支到主分支

冲突解决：合并时若有冲突，Git会标记冲突文件，手动修改后执行git add 冲突文件，最后git commit完成合并。

1.3 变基（Rebase）操作

变基是另一种合并分支的方式，通过将当前分支的提交记录复制到目标分支的末尾，使提交历史更线性。


# 在功能分支执行，将提交记录复制到main分支末尾
git rebase main

与merge的区别：

  • merge会生成新的合并提交，保留分支历史
  • rebase重写提交历史，使分支更简洁（适合清理本地分支）

注意事项：

  • 避免对已推送至远程的分支执行rebase（会导致协作冲突）
  • 冲突解决与merge类似，修改后执行git rebase --continue

1.4 删除分支


# 删除已合并的分支
git branch -d 分支名

# 强制删除未合并的分支（谨慎使用）
git branch -D 分支名

2. 交互式变基（Interactive Rebase）

交互式变基允许开发者在变基过程中手动调整提交记录，是清理提交历史、合并无关提交的强大工具。

2.1 基本用法


# 对最近3次提交进行交互式变基（HEAD~3表示最近3次提交）
git rebase -i HEAD~3

执行后会打开编辑器，显示类似以下内容：


pick 123abc 修复登录按钮样式
pick 456def 添加用户注册功能
pick 789ghi 优化表单验证逻辑

可通过修改命令（如将pick改为squash合并提交）调整提交顺序和操作：


pick 123abc 修复登录按钮样式
squash 456def 添加用户注册功能
squash 789ghi 优化表单验证逻辑

2.2 常用操作指令

  • pick (p): 保留提交
  • reword (r): 修改提交信息
  • edit (e): 暂停变基以修改提交
  • squash (s): 合并到前一个提交
  • fixup (f): 类似squash但丢弃当前提交信息

注意：仅对未推送至远程的分支使用交互式变基，避免破坏协作历史。

3. 标签管理

标签用于标记重要版本（如发布版本），方便后续快速定位到特定提交。

3.1 创建标签


# 创建轻量标签（仅记录提交哈希）
git tag v1.0.0

# 创建注释标签（包含标签说明）
git tag -a v1.0.0 -m "1.0版本正式发布"

# 为历史提交打标签（指定提交哈希）
git tag -a v0.9.0 123abc456 -m "0.9测试版本"

3.2 查看与推送标签


# 查看所有标签
git tag

# 查看特定标签详情
git show v1.0.0

# 推送单个标签到远程
git push origin v1.0.0

# 推送所有标签到远程
git push origin --tags

3.3 删除标签


# 删除本地标签
git tag -d v1.0.0

# 删除远程标签（需先删除本地）
git push origin --delete tag v1.0.0

5. Git钩子（Hooks）

Git钩子是在特定操作（如提交、推送）前后执行的脚本，用于实现自动化代码检查、格式校验等工作流。

5.1 钩子类型与位置

钩子脚本存储在仓库的.git/hooks目录下，常见钩子包括：

  • pre-commit：提交前触发（可用于代码格式化）
  • commit-msg：提交信息输入后触发（可校验提交规范）
  • pre-push：推送前触发（可运行测试用例）

5.2 自定义钩子示例

以pre-commit钩子实现ESLint代码检查为例：


# 进入钩子目录
cd .git/hooks

# 创建pre-commit文件（去掉.sample后缀启用）
cp pre-commit.sample pre-commit

# 编辑脚本内容（使用#!/bin/sh开头）
echo '#!/bin/sh
npm run lint' > pre-commit

# 赋予执行权限
chmod +x pre-commit

效果：每次执行git commit时会自动运行ESLint，若检查失败则阻止提交。

5.3 共享钩子（推荐新方法） 通过`git config core.hooksPath 路径`设置全局钩子目录，团队只需维护一个钩子仓库，所有项目自动同步（无需子模块）。

团队协作时可通过以下方式共享钩子：

  • 将钩子脚本存入子模块，通过git submodule同步
  • 使用git init.templatedir配置模板目录，初始化新仓库时自动复制钩子

4. 子模块（Submodules）管理

子模块用于在主项目中引用其他独立Git仓库，适合管理大型项目的第三方库或公共组件。

4.1 添加子模块


# 将外部仓库作为子模块添加到项目的libs目录下
git submodule add https://github.com/第三方/仓库名.git libs/仓库名

操作后会生成.gitmodules文件，记录子模块路径和仓库地址。

4.2 克隆含子模块的项目


# 普通克隆不会自动获取子模块代码
git clone 主项目地址

# 递归克隆（自动初始化并获取子模块）
git clone --recurse-submodules 主项目地址

# 已克隆项目后初始化子模块
git submodule init
# 获取子模块代码
git submodule update

4.3 更新子模块

当子模块仓库有新提交时，需在主项目中更新引用：


# 进入子模块目录，切换到目标分支并拉取更新
git -C libs/仓库名 checkout main
/git -C libs/仓库名 pull

# 返回主项目，提交子模块的新引用
git add libs/仓库名
/git commit -m "更新子模块到最新版本"

4.4 移除子模块


# 从.gitmodules中删除子模块配置
git config --file .gitmodules --remove-section submodule.仓库名

# 移除工作区的子模块目录
git rm --cached libs/仓库名
/rm -rf libs/仓库名

# 提交变更
git commit -m "移除子模块"

2. 交互式变基（Interactive Rebase）

交互式变基允许开发者在变基过程中手动调整提交记录，是清理提交历史、合并无关提交的强大工具。

2.1 基本用法


# 对最近3次提交进行交互式变基（HEAD~3表示最近3次提交）
git rebase -i HEAD~3

执行后会打开编辑器，显示类似以下内容：


pick 123abc 修复登录按钮样式
pick 456def 添加用户注册功能
pick 789ghi 优化表单验证逻辑

可通过修改命令（如将pick改为squash合并提交）调整提交顺序和操作：


pick 123abc 修复登录按钮样式
squash 456def 添加用户注册功能
squash 789ghi 优化表单验证逻辑

2.2 常用操作指令

  • pick (p): 保留提交
  • reword (r): 修改提交信息
  • edit (e): 暂停变基以修改提交
  • squash (s): 合并到前一个提交
  • fixup (f): 类似squash但丢弃当前提交信息

注意：仅对未推送至远程的分支使用交互式变基，避免破坏协作历史。

3. 标签管理

标签用于标记重要版本（如发布版本），方便后续快速定位到特定提交。

3.1 创建标签


# 创建轻量标签（仅记录提交哈希）
git tag v1.0.0

# 创建注释标签（包含标签说明）
git tag -a v1.0.0 -m "1.0版本正式发布"

# 为历史提交打标签（指定提交哈希）
git tag -a v0.9.0 123abc456 -m "0.9测试版本"

3.2 查看与推送标签


# 查看所有标签
git tag

# 查看特定标签详情
git show v1.0.0

# 推送单个标签到远程
git push origin v1.0.0

# 推送所有标签到远程
git push origin --tags

3.3 删除标签


# 删除本地标签
git tag -d v1.0.0

# 删除远程标签（需先删除本地）
git push origin --delete tag v1.0.0

5. Git钩子（Hooks）

Git钩子是在特定操作（如提交、推送）前后执行的脚本，用于实现自动化代码检查、格式校验等工作流。

5.1 钩子类型与位置

钩子脚本存储在仓库的.git/hooks目录下，常见钩子包括：

  • pre-commit：提交前触发（可用于代码格式化）
  • commit-msg：提交信息输入后触发（可校验提交规范）
  • pre-push：推送前触发（可运行测试用例）

5.2 自定义钩子示例

以pre-commit钩子实现ESLint代码检查为例：


# 进入钩子目录
cd .git/hooks

# 创建pre-commit文件（去掉.sample后缀启用）
cp pre-commit.sample pre-commit

# 编辑脚本内容（使用#!/bin/sh开头）
echo '#!/bin/sh
npm run lint' > pre-commit

# 赋予执行权限
chmod +x pre-commit

效果：每次执行git commit时会自动运行ESLint，若检查失败则阻止提交。

5.3 共享钩子（推荐新方法） 通过`git config core.hooksPath 路径`设置全局钩子目录，团队只需维护一个钩子仓库，所有项目自动同步（无需子模块）。

团队协作时可通过以下方式共享钩子：

  • 将钩子脚本存入子模块，通过git submodule同步
  • 使用git init.templatedir配置模板目录，初始化新仓库时自动复制钩子

2. 远程仓库操作

以GitHub为例，讲解远程仓库的连接与协作。

2.1 关联远程仓库


# 添加远程仓库地址（origin为默认别名）
git remote add origin https://github.com/用户名/仓库名.git

# 查看远程仓库信息
git remote -v

2.2 推送与拉取


# 推送本地分支到远程仓库（首次推送需关联）
git push -u origin 分支名

# 拉取远程仓库更新（合并到本地当前分支）
git pull origin 分支名

注意：若远程仓库有新提交未拉取，直接推送会失败，需先执行git pull同步。

2. 交互式变基（Interactive Rebase）

交互式变基允许开发者在变基过程中手动调整提交记录，是清理提交历史、合并无关提交的强大工具。

2.1 基本用法


# 对最近3次提交进行交互式变基（HEAD~3表示最近3次提交）
git rebase -i HEAD~3

执行后会打开编辑器，显示类似以下内容：


pick 123abc 修复登录按钮样式
pick 456def 添加用户注册功能
pick 789ghi 优化表单验证逻辑

可通过修改命令（如将pick改为squash合并提交）调整提交顺序和操作：


pick 123abc 修复登录按钮样式
squash 456def 添加用户注册功能
squash 789ghi 优化表单验证逻辑

2.2 常用操作指令

  • pick (p): 保留提交
  • reword (r): 修改提交信息
  • edit (e): 暂停变基以修改提交
  • squash (s): 合并到前一个提交
  • fixup (f): 类似squash但丢弃当前提交信息

注意：仅对未推送至远程的分支使用交互式变基，避免破坏协作历史。

3. 标签管理

标签用于标记重要版本（如发布版本），方便后续快速定位到特定提交。

3.1 创建标签


# 创建轻量标签（仅记录提交哈希）
git tag v1.0.0

# 创建注释标签（包含标签说明）
git tag -a v1.0.0 -m "1.0版本正式发布"

# 为历史提交打标签（指定提交哈希）
git tag -a v0.9.0 123abc456 -m "0.9测试版本"

3.2 查看与推送标签


# 查看所有标签
git tag

# 查看特定标签详情
git show v1.0.0

# 推送单个标签到远程
git push origin v1.0.0

# 推送所有标签到远程
git push origin --tags

3.3 删除标签


# 删除本地标签
git tag -d v1.0.0

# 删除远程标签（需先删除本地）
git push origin --delete tag v1.0.0

5. Git钩子（Hooks）

Git钩子是在特定操作（如提交、推送）前后执行的脚本，用于实现自动化代码检查、格式校验等工作流。

5.1 钩子类型与位置

钩子脚本存储在仓库的.git/hooks目录下，常见钩子包括：

  • pre-commit：提交前触发（可用于代码格式化）
  • commit-msg：提交信息输入后触发（可校验提交规范）
  • pre-push：推送前触发（可运行测试用例）

5.2 自定义钩子示例

以pre-commit钩子实现ESLint代码检查为例：


# 进入钩子目录
cd .git/hooks

# 创建pre-commit文件（去掉.sample后缀启用）
cp pre-commit.sample pre-commit

# 编辑脚本内容（使用#!/bin/sh开头）
echo '#!/bin/sh
npm run lint' > pre-commit

# 赋予执行权限
chmod +x pre-commit

效果：每次执行git commit时会自动运行ESLint，若检查失败则阻止提交。

5.3 共享钩子（推荐新方法） 通过`git config core.hooksPath 路径`设置全局钩子目录，团队只需维护一个钩子仓库，所有项目自动同步（无需子模块）。

团队协作时可通过以下方式共享钩子：

  • 将钩子脚本存入子模块，通过git submodule同步
  • 使用git init.templatedir配置模板目录，初始化新仓库时自动复制钩子

8. 交互式暂存（git add -i）

交互式暂存允许开发者逐块选择要暂存的代码更改，适合需要精细控制提交内容的场景（如拆分大修改为多个小提交）。

8.1 启动交互模式


git add -i  # 启动交互式界面

界面会列出所有修改文件，并提供操作选项（1-7对应不同功能）。

8.2 核心操作选项

  • 1: 暂存（Stage）文件/块
  • 2: 取消暂存（Unstage）文件/块
  • 3: 查看（View）当前更改
  • 5: 补丁模式（Patch）：逐块选择更改（最常用）

8.3 补丁模式示例

场景：文件app.js有3处修改，但只想提交前两处。


git add -p  # 等价于git add --patch

Git会逐块显示更改，输入'y'暂存当前块，'n'跳过，'s'拆分块（若块过大），最终仅暂存需要的部分。

8.4 最佳实践

  • 拆分大提交为多个小提交，保持提交粒度清晰
  • 配合git commit --amend修改最近提交（未推送到远程时）

9. Reflog（引用日志）

Reflog记录了所有分支和HEAD的历史操作（包括提交、重置、合并等），是恢复丢失提交的最后一道防线。即使提交被删除，也能通过Reflog找回。

9.1 查看Reflog


git reflog  # 显示所有操作记录（包含简短哈希和操作描述）
git reflog show HEAD  # 仅显示HEAD的操作历史

9.2 恢复丢失提交

场景：误执行git reset --hard HEAD~3导致3次提交丢失。


# 查看reflog找到丢失的提交哈希（如abc123）
git reflog

# 恢复到该提交
git reset --hard abc123

9.3 注意事项

  • Reflog默认保留30天（可通过git config gc.reflogExpire调整）
  • 强制推送（git push --force）会覆盖远程仓库的reflog，需谨慎操作

10. 子树合并（Subtree Merge）

子树合并用于将外部项目作为子目录集成到当前项目中，适合需要深度整合外部代码（如第三方库定制版）的场景，相比子模块无需额外配置文件。

10.1 基本用法


# 添加外部项目到当前项目的子目录（如libs/external）
git subtree add --prefix=libs/external 外部仓库URL 分支名 --squash

# 同步外部项目的最新更改
git subtree pull --prefix=libs/external 外部仓库URL 分支名 --squash

# 推送当前项目的子目录更改到外部仓库
git subtree push --prefix=libs/external 外部仓库URL 分支名

10.2 与子模块对比

特性子树合并子模块
代码存储嵌入主仓库（单仓库）独立仓库（多仓库）
依赖管理自动同步（无需额外操作）需手动更新（git submodule update）
适合场景深度定制外部代码使用稳定第三方库

10.3 实战建议

  • 添加时使用--squash参数合并外部提交历史，保持主仓库干净
  • 同步更改前先拉取主仓库最新代码，避免冲突

11. 工作树（git worktree）

工作树允许在同一个Git仓库中创建多个独立的工作目录，每个目录关联不同分支，适合需要并行开发多个功能或修复不同分支bug的场景。

11.1 核心操作


# 创建新工作树并检出指定分支（自动创建目录：worktrees/分支名）
git worktree add -b 新分支名 worktrees/分支名 基础分支

# 列出所有工作树
git worktree list

# 删除工作树（需先提交/ stash更改）
git worktree remove worktrees/分支名

11.2 实战场景

场景：同时开发feature-A（main分支）和修复bug（hotfix分支）。


# 为main分支创建工作树（开发feature-A）
git worktree add -b feature-A worktrees/feature-A main

# 为hotfix分支创建工作树（修复bug）
git worktree add -b hotfix worktrees/hotfix origin/hotfix

11.3 注意事项

  • 工作树共享同一个.git目录，删除主工作树会影响所有子工作树
  • 跨工作树修改相同文件可能导致冲突，需谨慎操作

12. 部分克隆（git clone --filter）

部分克隆用于下载大型仓库时仅获取必要的提交历史，减少磁盘占用和下载时间，适合处理包含大文件或长历史的仓库（如Linux内核仓库）。

12.1 基础用法


# 仅克隆最近20次提交的历史
git clone --filter=blob:none --depth=20 仓库URL

# 按需获取完整历史（后续需要时下载）
git fetch --unshallow

12.2 过滤类型

  • blob:none：不下载大文件（blob对象），仅保留指针
  • tree:0：仅下载最新提交的目录结构
  • sparse：稀疏检出（仅获取指定目录的文件）

12.3 性能对比

以10GB的大型仓库为例：

  • 完整克隆：下载10GB，耗时约30分钟
  • 部分克隆（depth=20）：下载约200MB，耗时约2分钟

10. 子树合并（Subtree Merge）

子树合并用于将外部项目作为子目录集成到当前项目中，适合需要深度整合外部代码（如第三方库定制版）的场景，相比子模块无需额外配置文件。

10.1 基本用法


# 添加外部项目到当前项目的子目录（如libs/external）
git subtree add --prefix=libs/external 外部仓库URL 分支名 --squash

# 同步外部项目的最新更改
git subtree pull --prefix=libs/external 外部仓库URL 分支名 --squash

# 推送当前项目的子目录更改到外部仓库
git subtree push --prefix=libs/external 外部仓库URL 分支名

10.2 与子模块对比

特性子树合并子模块
代码存储嵌入主仓库（单仓库）独立仓库（多仓库）
依赖管理自动同步（无需额外操作）需手动更新（git submodule update）
适合场景深度定制外部代码使用稳定第三方库

10.3 实战建议

  • 添加时使用--squash参数合并外部提交历史，保持主仓库干净
  • 同步更改前先拉取主仓库最新代码，避免冲突

8. 交互式暂存（git add -i）

交互式暂存允许开发者逐块选择要暂存的代码更改，适合需要精细控制提交内容的场景（如拆分大修改为多个小提交）。

8.1 启动交互模式


git add -i  # 启动交互式界面

界面会列出所有修改文件，并提供操作选项（1-7对应不同功能）。

8.2 核心操作选项

  • 1: 暂存（Stage）文件/块
  • 2: 取消暂存（Unstage）文件/块
  • 3: 查看（View）当前更改
  • 5: 补丁模式（Patch）：逐块选择更改（最常用）

8.3 补丁模式示例

场景：文件app.js有3处修改，但只想提交前两处。


git add -p  # 等价于git add --patch

Git会逐块显示更改，输入'y'暂存当前块，'n'跳过，'s'拆分块（若块过大），最终仅暂存需要的部分。

8.4 最佳实践

  • 拆分大提交为多个小提交，保持提交粒度清晰
  • 配合git commit --amend修改最近提交（未推送到远程时）

6. Cherry-pick（挑选提交）

Cherry-pick用于将指定分支的单个或多个提交复制到当前分支，适合从其他分支移植特定修复到主分支。

6.1 基础用法


# 复制指定提交到当前分支（提交哈希可通过git log获取）
git cherry-pick 提交哈希

# 复制多个连续提交（起始哈希^..结束哈希）
git cherry-pick 起始哈希^..结束哈希

6.2 实战示例

场景：main分支需要紧急修复一个在dev分支已修复的bug（对应提交哈希为abc123）。


# 切换到main分支
git checkout main

# 复制dev分支的修复提交
git cherry-pick abc123

# 解决可能的冲突（若有）
手动修改冲突文件后执行：git add 冲突文件
/git cherry-pick --continue

6.3 注意事项

  • 若目标提交已存在于当前分支，Cherry-pick会跳过（可通过--allow-empty强制应用）
  • 批量操作时建议使用git cherry-pick --no-commit暂不提交，确认所有更改后统一提交

7. Git Bisect（二分查找）

Git Bisect用于通过二分法快速定位导致bug的提交，适合在历史版本中排查问题根源。

7.1 使用场景

当发现某个功能在新版本中失效，但不清楚是哪个提交导致时，可通过Bisect逐步缩小问题范围。

7.2 操作步骤


# 启动bisect流程（指定已知坏版本和已知好版本）
git bisect start 坏版本哈希 好版本哈希

# 标记当前版本为坏（问题存在）
git bisect bad

# 标记当前版本为好（问题不存在）
git bisect good

# 自动查找并显示导致问题的提交
git bisect reset

7.3 实战示例

场景：v1.0正常，v1.1出现崩溃，需找到导致崩溃的提交。

  1. 启动bisect：git bisect start v1.1 v1.0
  2. Git会自动检出中间版本，测试后标记： - 若崩溃：git bisect bad - 若正常：git bisect good
  3. 重复标记直到定位到问题提交，最后执行git bisect reset回到原分支。

7.4 自动化检查

可编写脚本自动执行测试，加速排查过程：


# 定义测试脚本（返回0表示正常，非0表示失败）
git bisect run ./test-script.sh

3. 版本回退与恢复

### 3. Git 2.49 新增特性（2024年更新） #### 3.1 `git rebase --autosquash` 增强 自动识别以`squash!`或`fixup!`开头的提交说明，在变基时自动调整顺序，无需手动拖拽提交位置。配合全局配置： ```bash git config --global rebase.autoSquash true ``` 示例：提交说明为`squash! 修复登录逻辑`的提交会自动合并到前一个提交。 #### 3.2 `git switch --detach` 简化分离HEAD 直接通过`git switch --detach 提交哈希`进入分离HEAD状态，替代原`git checkout 提交哈希`，命令更符合语义（`switch`专注分支切换，`checkout`功能拆分后更清晰）。 #### 3.3 `git gc --aggressive` 性能优化 垃圾回收时启用更深度的压缩（如重写大对象为delta格式），显著减少仓库体积。建议大型项目每季度执行一次： ```bash git gc --aggressive ```

3.1 查看提交历史


git log       # 详细提交记录（含哈希值、作者、时间）
git log --oneline  # 简化显示（仅哈希前7位和提交说明）

3.2 回退版本


# 软回退（保留工作区修改，回退到指定提交）
git reset --soft 提交哈希

# 硬回退（丢弃工作区修改，彻底回退）
git reset --hard 提交哈希

3.3 恢复已删除的提交

若误操作删除提交，可通过git reflog查看所有操作记录，找到丢失的哈希值后使用git reset恢复。

2. 交互式变基（Interactive Rebase）

交互式变基允许开发者在变基过程中手动调整提交记录，是清理提交历史、合并无关提交的强大工具。

2.1 基本用法


# 对最近3次提交进行交互式变基（HEAD~3表示最近3次提交）
git rebase -i HEAD~3

执行后会打开编辑器，显示类似以下内容：


pick 123abc 修复登录按钮样式
pick 456def 添加用户注册功能
pick 789ghi 优化表单验证逻辑

可通过修改命令（如将pick改为squash合并提交）调整提交顺序和操作：


pick 123abc 修复登录按钮样式
squash 456def 添加用户注册功能
squash 789ghi 优化表单验证逻辑

2.2 常用操作指令

  • pick (p): 保留提交
  • reword (r): 修改提交信息
  • edit (e): 暂停变基以修改提交
  • squash (s): 合并到前一个提交
  • fixup (f): 类似squash但丢弃当前提交信息

注意：仅对未推送至远程的分支使用交互式变基，避免破坏协作历史。

3. 标签管理

标签用于标记重要版本（如发布版本），方便后续快速定位到特定提交。

3.1 创建标签


# 创建轻量标签（仅记录提交哈希）
git tag v1.0.0

# 创建注释标签（包含标签说明）
git tag -a v1.0.0 -m "1.0版本正式发布"

# 为历史提交打标签（指定提交哈希）
git tag -a v0.9.0 123abc456 -m "0.9测试版本"

3.2 查看与推送标签


# 查看所有标签
git tag

# 查看特定标签详情
git show v1.0.0

# 推送单个标签到远程
git push origin v1.0.0

# 推送所有标签到远程
git push origin --tags

3.3 删除标签


# 删除本地标签
git tag -d v1.0.0

# 删除远程标签（需先删除本地）
git push origin --delete tag v1.0.0

5. Git钩子（Hooks）

Git钩子是在特定操作（如提交、推送）前后执行的脚本，用于实现自动化代码检查、格式校验等工作流。

5.1 钩子类型与位置

钩子脚本存储在仓库的.git/hooks目录下，常见钩子包括：

  • pre-commit：提交前触发（可用于代码格式化）
  • commit-msg：提交信息输入后触发（可校验提交规范）
  • pre-push：推送前触发（可运行测试用例）

5.2 自定义钩子示例

以pre-commit钩子实现ESLint代码检查为例：


# 进入钩子目录
cd .git/hooks

# 创建pre-commit文件（去掉.sample后缀启用）
cp pre-commit.sample pre-commit

# 编辑脚本内容（使用#!/bin/sh开头）
echo '#!/bin/sh
npm run lint' > pre-commit

# 赋予执行权限
chmod +x pre-commit

效果：每次执行git commit时会自动运行ESLint，若检查失败则阻止提交。

5.3 共享钩子（推荐新方法） 通过`git config core.hooksPath 路径`设置全局钩子目录，团队只需维护一个钩子仓库，所有项目自动同步（无需子模块）。

团队协作时可通过以下方式共享钩子：

  • 将钩子脚本存入子模块，通过git submodule同步
  • 使用git init.templatedir配置模板目录，初始化新仓库时自动复制钩子