Git 高级技巧与团队协作工作流 2026

🌿 Git 是开发者最重要的协作工具。 掌握 Git 基础只是开始，真正的高效协作需要掌握高级技巧和规范的工作流。本文涵盖从进阶操作到团队协作的最佳实践，帮助你成为 Git 高手。

本文将带你系统掌握：

• ✅ 变基（rebase）与合并（merge）的选择
• ✅ 历史重写与提交整理
• ✅ 储藏（stash）与挑选（cherry-pick）
• ✅ 子模块与子树
• ✅ Git Hooks 与自动化
• ✅ 常见分支策略（Git Flow / GitHub Flow / Trunk-Based）
• ✅ 代码审查最佳实践
• ✅ 常见问题处理

---

一、变基（Rebase）

1.1 什么是变基

变基将一个分支的提交"搬"到另一个分支之上，使提交历史变成一条直线。

变基前：
  A---B---C  main
       \
        D---E  feature

变基后：
  A---B---C---D'---E'  feature
          main

1.2 基本用法

# 将 feature 分支变基到 main 之上
git checkout feature
git rebase main

# 或一步完成
git rebase main feature

1.3 交互式变基

交互式变基可以修改、合并、删除提交：

# 对最近 3 个提交进行交互式变基
git rebase -i HEAD~3

会出现编辑器：

pick f7f3f6d 提交信息1
pick 310154e 提交信息2
pick a5f4a0d 提交信息3

# 命令：
# p, pick = 使用该提交
# r, reword = 使用该提交，但修改信息
# e, edit = 使用该提交，但暂停修改
# s, squash = 合并到上一个提交
# f, fixup = 合并到上一个提交，丢弃信息
# d, drop = 删除该提交

常用操作：

操作	命令
修改提交信息	reword 或 r
合并多个提交	squash 或 s
删除提交	drop 或 d
重新排序	调整行顺序

1.4 解决变基冲突

# 冲突时，修改文件后
git add <file>
git rebase --continue

# 放弃变基
git rebase --abort

# 跳过当前提交
git rebase --skip

1.5 merge vs rebase

特性	merge	rebase
历史记录	保留所有合并	线性历史
冲突处理	一次解决	逐个提交解决
公共分支	✅ 推荐	❌ 禁止
私有分支	可用	✅ 推荐
追溯问题	更真实	更清晰

⚠️ 黄金法则： 永远不要在公共分支（如 main/master）上使用 rebase！

---

二、储藏（Stash）

2.1 基本用法

当工作区有未提交的修改，但需要切换分支时：

# 储藏当前修改
git stash

# 储藏并添加说明
git stash save "work in progress on login feature"

# 查看储藏列表
git stash list
# stash@{0}: On feature/login: work in progress on login feature
# stash@{1}: On main: WIP

# 应用最近的储藏并删除
git stash pop

# 应用指定储藏（不删除）
git stash apply stash@{1}

# 删除指定储藏
git stash drop stash@{0}

# 清空所有储藏
git stash clear

2.2 高级用法

# 只储藏暂存区的内容
git stash --staged

# 同时储藏未跟踪的文件
git stash -u
# 或
git stash --include-untracked

# 查看储藏内容
git stash show stash@{0}
git stash show -p stash@{0}  # 显示 diff

# 从储藏创建新分支
git stash branch new-branch stash@{0}

---

三、挑选（Cherry-pick）

3.1 基本用法

将某个分支的特定提交应用到当前分支：

# 挑选一个提交
git cherry-pick <commit-hash>

# 挑选多个提交
git cherry-pick <hash1> <hash2> <hash3>

# 挑选一个范围的提交（不包含 start）
git cherry-pick start..end

# 包含 start
git cherry-pick start^..end

3.2 处理冲突

# 解决冲突后
git add <file>
git cherry-pick --continue

# 放弃 cherry-pick
git cherry-pick --abort

# 跳过当前提交
git cherry-pick --skip

3.3 只修改不提交

# 只应用更改，不创建提交
git cherry-pick --no-commit <hash>

3.4 使用场景

• 修复了 main 上的 bug，需要同步到其他版本分支
• 错误地在错误的分支上提交了代码
• 只需要某个分支的特定功能

---

四、提交历史管理

4.1 修改最近提交

# 修改提交信息
git commit --amend -m "新的提交信息"

# 将暂存区的修改加入最近一次提交（不改信息）
git add <file>
git commit --amend --no-edit

⚠️ 如果已经推送到远程，需要 git push --force-with-lease 强制推送（仅私有分支）

4.2 重置（Reset）

# 三种模式

# soft: 仅移动 HEAD，更改保留在暂存区
git reset --soft HEAD~1

# mixed (默认): 移动 HEAD，更改保留在工作区
git reset HEAD~1
git reset --mixed HEAD~1

# hard: 移动 HEAD，丢弃所有更改（危险！）
git reset --hard HEAD~1

模式	HEAD	暂存区	工作区
--soft	✅ 移动	不变	不变
--mixed	✅ 移动	✅ 重置	不变
--hard	✅ 移动	✅ 重置	✅ 重置

4.3 撤销操作指南

场景	命令
撤销工作区修改	git checkout -- file
撤销暂存	git reset HEAD file
撤销最近提交（保留更改）	git reset HEAD~1
撤销最近提交（丢弃更改）	git reset --hard HEAD~1
撤销已推送的提交	git revert <hash>
撤销 merge	git reset --hard ORIG_HEAD

4.4 Revert（反向提交）

# 创建一个反向提交，撤销指定提交的更改
git revert <commit-hash>

# 撤销 merge 提交
git revert -m 1 <merge-commit-hash>

revert 不会修改历史，适合公共分支上的撤销操作。

4.5 Reflog 找回丢失的提交

# 查看引用日志
git reflog

# 找回丢失的提交
git reset --hard <hash-from-reflog>

# 找回被删除的分支
git checkout -b recovered-branch <hash-from-reflog>

💡 reflog 保留 90 天，是救命稻草！

---

五、子模块与子树

5.1 Git Submodule

将另一个仓库作为子目录嵌入：

# 添加子模块
git submodule add https://github.com/user/repo.git path/to/submodule

# 克隆包含子模块的仓库
git clone --recursive https://github.com/user/main.git
# 或克隆后初始化
git submodule update --init --recursive

# 更新所有子模块
git submodule update --remote --merge

# 进入子模块操作
cd path/to/submodule
git checkout main
git pull

# 删除子模块
git submodule deinit path/to/submodule
git rm path/to/submodule
rm -rf .git/modules/path/to/submodule

5.2 Git Subtree

子树将另一个仓库的内容合并为当前仓库的一部分：

# 添加子树
git subtree add --prefix=path/to/subtree https://github.com/user/repo.git main

# 拉取子树更新
git subtree pull --prefix=path/to/subtree https://github.com/user/repo.git main

# 推送子树更改
git subtree push --prefix=path/to/subtree https://github.com/user/repo.git main

5.3 Submodule vs Subtree

特性	Submodule	Subtree
仓库独立性	各自独立	合并到主仓库
克隆体验	需要 --recursive	直接克隆
更新方式	submodule update	subtree pull
贡献回去	简单	较复杂
历史记录	分开	合并
适合场景	依赖第三方库	自己维护的共享代码

---

六、Git Hooks

6.1 常用钩子

钩子	触发时机	用途
pre-commit	提交前	代码检查、格式化
commit-msg	提交信息	校验提交信息格式
pre-push	推送前	运行测试
pre-receive	接收前	服务器端校验
post-receive	接收后	触发部署

6.2 pre-commit 示例

#!/bin/sh
# .git/hooks/pre-commit

# 检查代码格式
if ! npx prettier --check "**/*.{js,ts,md}" 2>/dev/null; then
  echo "❌ 代码格式错误，请运行 npx prettier --write"
  exit 1
fi

# 运行 lint
if ! npm run lint 2>/dev/null; then
  echo "❌ Lint 检查失败"
  exit 1
fi

echo "✅ 检查通过"
exit 0

# 赋予执行权限
chmod +x .git/hooks/pre-commit

6.3 使用 Husky 管理钩子

# 安装
npm install -D husky
npx husky init

# 添加 pre-commit 钩子
echo "npx lint-staged" > .husky/pre-commit

package.json 配置：

{
  "lint-staged": {
    "*.{js,ts,vue}": ["eslint --fix", "prettier --write"],
    "*.{md,json}": ["prettier --write"]
  }
}

---

七、分支策略

7.1 Git Flow

适用于有明确发布周期的项目：

main (生产)
  ↑ 合并发布
release-x.x
  ↑ 合并功能
develop
  ↑ 合并功能分支
feature/xxx  feature/yyy

hotfix/xxx  ←  从 main 分出修复后合并回 main 和 develop

命令速查：

# 安装 git-flow
brew install git-flow-avh

# 初始化
git flow init

# 开始功能
git flow feature start my-feature

# 完成功能
git flow feature finish my-feature

# 开始发布
git flow release start 1.0.0

# 完成发布
git flow release finish 1.0.0

# 开始修复
git flow hotfix start bugfix-1

# 完成修复
git flow hotfix finish bugfix-1

7.2 GitHub Flow

更简单，适合持续部署：

main (可随时部署)
  ↑
feature/xxx → Pull Request → Code Review → Merge

流程：

1. 从 main 创建功能分支
2. 开发并提交
3. 提交 Pull Request
4. 代码审查 + CI 通过
5. 合并到 main
6. 自动部署

7.3 Trunk-Based Development

最敏捷，适合小团队：

main (trunk)
  ├── 小功能直接提交
  └── Feature Flag 控制未完成功能

特点：

• 没有长期功能分支
• 频繁合并（每天至少一次）
• 使用 Feature Flag 控制功能开关
• CI/CD 必须完善

7.4 选择建议

项目类型	推荐策略
有版本发布周期	Git Flow
持续部署的 SaaS	GitHub Flow
小团队、快速迭代	Trunk-Based
开源项目	GitHub Flow + Fork PR

---

八、代码审查最佳实践

8.1 提交 PR 前检查清单

• 代码是否通过 lint 和测试
• 提交信息是否规范
• 是否有不必要的更改
• 是否添加了必要的注释
• PR 描述是否清晰
• 是否关联了 Issue

8.2 好的 PR 描述模板

## 变更类型
- [ ] Bug 修复
- [ ] 新功能
- [ ] 性能优化
- [ ] 代码重构
- [ ] 文档更新

## 变更内容
简要描述这次变更做了什么。

## 关联 Issue
Closes #123

## 测试方法
1. 运行 `npm test`
2. 访问 `/page` 验证功能

## 截图（可选）

8.3 审查代码时关注什么

必须检查：

• 逻辑正确性
• 安全漏洞
• 边界情况处理
• 错误处理

应该检查：

• 代码风格
• 命名规范
• 重复代码
• 测试覆盖

建议检查：

• 性能优化
• 架构设计
• 文档完整性

8.4 评论礼仪

• ❌ "这里写错了"

• ✅ "这里我理解是 xxx，对吗？如果是 xxx 的话，建议用 yyy 方式"

• ❌ "变量名不好"

• ✅ "这个变量能不能叫 xxx，更清晰地表达它的用途？"

原则：

1. 对事不对人
2. 提问而非指责
3. 给出建议而非要求
4. 肯定好的做法

---

九、常用高级技巧

9.1 Bisect 二分查找 bug

# 开始 bisect
git bisect start

# 标记当前版本为坏
git bisect bad

# 标记某个已知好的版本
git bisect good v1.0.0

# Git 会自动切换到中间版本
# 测试后标记
git bisect good   # 如果版本是好的
git bisect bad    # 如果版本是坏的

# 重复直到找到引入 bug 的提交

# 结束 bisect
git bisect reset

9.2 Blame 追溯修改

# 查看某文件每一行最后是谁修改的
git blame file.js

# 查看特定行范围
git blame -L 10,50 file.js

# 显示作者邮箱
git blame -e file.js

9.3 Grep 搜索历史

# 搜索所有提交中包含某关键词的
git log -S "关键词"

# 使用正则搜索
git log -G "正则表达式"

# 搜索提交信息
git log --grep="关键词"

9.4 Worktree 多分支同时工作

# 创建新的 worktree（在不同目录同时工作在不同分支）
git worktree add ../project-feature feature-branch

# 列出所有 worktree
git worktree list

# 删除 worktree
git worktree remove ../project-feature

9.5 自定义别名

# 添加别名
git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.lg "log --oneline --graph --all"

# 更复杂的别名
git config --global alias.last "log -1 HEAD"
git config --global alias.unstage "reset HEAD --"
git config --global alias.visual "!gitk"

---

十、常见问题处理

10.1 不小心 commit 了大文件

# 安装 git-filter-repo
pip install git-filter-repo

# 从历史中删除文件
git filter-repo --path large-file.zip --invert-paths

# 强制推送
git push --force --all

10.2 merge 冲突太多

# 使用 ours/theirs 策略
git merge main -X ours    # 冲突时使用当前分支的
git merge main -X theirs  # 冲突时使用对方的

# 或使用 rebase 逐个解决
git rebase main

10.3 错误地 reset --hard

# 用 reflog 找回
git reflog
git reset --hard <hash>

10.4 提交信息写错了

# 最近一个提交
git commit --amend -m "新信息"

# 更早的提交
git rebase -i HEAD~3
# 把 pick 改成 reword

---

十一、总结

Git 高级技巧是团队高效协作的基础：

1. 变基让历史更清晰，但不要在公共分支使用
2. 储藏帮你在分支间无缝切换
3. cherry-pick选择性同步提交
4. 分支策略选择适合团队的工作流
5. 代码审查提升代码质量和团队成长
6. reflog是你的救命稻草

🌿 好的 Git 工作流让团队协作如丝般顺滑。

---

相关文章推荐：

• Git 命令操作指南
• Git 重置提交
• VS Code 使用技巧
• ESLint + Prettier 代码规范最佳实践