创建与切换#

1
# 创建并切换到新分支（推荐写法）
2
git checkout -b feature
3

4
# 等价于两步操作
5
git branch feature
6
git checkout feature

HEAD 是什么？#

HEAD 是一个指针，指向你当前所在的分支（或提交）。你做的每一次 checkout 都在移动它。

• HEAD^ — 当前提交的父节点
• HEAD~3 — 往前数 3 个提交
• git branch -f main HEAD~2 — 强制把 main 指针移到前 2 个提交

下面这张图展示了一个典型的分支工作流——从 main 创建 feature 和 bugfix 分支，独立开发后合并回主干：

merge：保留历史轨迹#

1
# 在 main 上执行，合并 feature 分支
2
git checkout main
3
git merge --no-ff feature

--no-ff 强制生成一个合并提交，即使可以快进。这样在历史中能清楚看到「这个功能是从哪里合进来的」。

rebase：保持线性历史#

1
# 在 feature 上执行，把自己的改动「垫」到 main 最新提交之上
2
git checkout feature
3
git rebase main

rebase 的本质是：暂存你的提交 → 应用目标分支的更新 → 重新应用你的提交。注意，它修改的是当前分支，目标分支只是参照物。

黄金法则#

• 个人分支用 rebase：保持干净的线性历史
• 公共分支用 merge：保留合并记录，不改写已推送的历史
• 已推送的分支禁止 rebase：会导致其他人的历史混乱

仅本地：git reset#

1
# 撤销最近一次提交，保留改动在暂存区
2
git reset --soft HEAD^
3

4
# 撤销最近一次提交，保留改动在工作区（默认行为）
5
git reset HEAD^
6

7
# 彻底丢弃改动（不可恢复！）
8
git reset --hard HEAD^

已推送：git revert#

1
# 生成一个新的「反向提交」来撤销指定提交
2
git revert <commit-hash>

revert 不会改写历史，而是创建一个新提交来抵消之前的改动。这在协作中是安全的。

cherry-pick：精确挑选#

1
# 只把 C2 和 C4 这两个提交挪到当前分支
2
git cherry-pick C2 C4

区别于 rebase 拿整个分支，cherry-pick 让你精确选择需要的提交。

交互式 rebase：整理本地提交#

1
git rebase -i HEAD~4

可以重排、合并、删除、编辑最近 4 个提交。在推送前整理提交历史非常有用。

核心概念#

• origin/main（简写 o/main）是本地存储的远程仓库快照
• 它不会自动更新，需要手动 fetch

fetch、pull、push 的关系#

1
# 只更新远程跟踪分支，不动本地分支（安全）
2
git fetch origin
3

4
# 拉取并合并（= fetch + merge）
5
git pull origin main
6

7
# 拉取并变基（= fetch + rebase，推荐）
8
git pull --rebase
9

10
# 推送本地提交到远程
11
git push origin main

Remote Tracking：分支跟踪#

1
# 创建本地分支并跟踪远程分支
2
git checkout -b feature o/main
3

4
# 为已有分支设置跟踪
5
git branch -u o/main feature

设置跟踪后，git push 和 git pull 就知道该推到哪里、从哪里拉了。

为什么需要 worktree？#

在实际开发中，你经常会遇到这样的场景：正在 feature 分支上写代码写到一半，突然线上出了 bug 需要紧急修复。传统做法是 git stash → 切分支 → 修 bug → 切回来 → git stash pop。这个流程有几个痛点：

• stash 恢复时可能产生冲突
• IDE 的构建缓存、运行状态全部丢失
• 频繁切换分支的心智负担很重

git worktree 从根本上解决了这个问题：它允许你从同一个仓库创建多个工作目录，每个目录检出不同的分支，彼此完全独立。

核心设计理念#

worktree 的设计哲学是共享存储，隔离工作区：

• 所有工作树共享同一个 .git 对象库（commits、blobs、trees）
• 每个工作树有独立的 HEAD、index（暂存区）和工作目录
• 磁盘开销极小——只多了一份工作区文件，不会复制整个仓库

这意味着你在任何一个工作树中做的提交，其他工作树都能立即看到（通过 git log），因为底层数据是共享的。

实战场景对比#

下面这张图对比了传统方式和 worktree 方式处理「开发中途需要修 bug」的流程差异：

常用命令速查#

1
# 创建一个新的工作树，检出 hotfix 分支
2
git worktree add ../project-hotfix hotfix
3

4
# 创建工作树的同时创建新分支
5
git worktree add -b emergency-fix ../project-fix main
6

7
# 查看所有工作树
8
git worktree list
9

10
# 完成后移除工作树（先删目录再清理引用）
11
git worktree remove ../project-hotfix
12

13
# 清理已失效的工作树引用
14
git worktree prune

使用注意事项#

• 同一分支不能同时被两个工作树检出——这是 Git 的硬性限制，防止两个工作区同时修改同一分支导致混乱
• 不要直接 rm -rf 删除工作树目录——应该用 git worktree remove，否则 .git/worktrees 中会残留失效引用
• 子模块在链接工作树中的支持有限，复杂项目需要测试验证
• worktree 非常适合 CI/CD 场景——可以同时构建多个分支而不互相干扰

什么时候该用 worktree？#

日常开发流程#

1. git fetch origin — 先看看远程有什么变化
2. git rebase o/main — 在个人分支上变基到最新
3. 解决可能的冲突
4. git push — 推送到远程
5. 在 main 上 merge --no-ff — 合并功能分支

版本标记#

1
# 给特定提交打标签
2
git tag v1.0.0 <commit-hash>
3

4
# 查看离当前位置最近的标签
5
git describe main

常见陷阱#

记住两条核心原则：个人分支随便折腾，公共分支只做加法。掌握了 merge/rebase 的选择和 reset/revert 的区分，日常 Git 操作就不会出大问题。