Git 高级操作指南#

方案一：Merge（合并）#

Merge 是最直观的解决方案，它将两个分支的提交历史合并在一起，创建一个新的合并提交。

配置与执行命令：

1
# 设置 pull 行为为合并（默认行为）
2
git config pull.rebase false
3

4
# 执行合并
5
git pull --no-rebase

原理图示：

合并前：

1
      A---B---C  (本地分支 feature)
2
     /
3
D---E---F---G  (远程分支 origin/feature)

合并后：

1
      A---B---C
2
     /         \
3
D---E---F---G---H  (合并提交 M)

特点：

• 保留完整的提交历史
• 创建一个合并提交（M），记录合并信息
• 不会改变已有的提交 hash
• 适用于需要保留完整历史的项目

适用场景：

• 团队协作时
• 需要保留完整历史记录
• 已发布的分支
• 不介意产生额外合并提交

方案二：Rebase（变基）#

Rebase 将本地分支的提交「重放」到目标分支的顶部，从而创造出一条线性历史。

配置与执行命令：

1
# 设置 pull 行为为变基
2
git config pull.rebase true
3

4
# 执行变基
5
git pull --rebase

原理图示：

变基前：

1
      A---B---C  (本地分支 feature)
2
     /
3
D---E---F---G  (远程分支 origin/feature)

变基后：

1
              A'--B'--C'  (本地分支 feature)
2
             /
3
D---E---F---G  (远程分支 origin/feature)

重要警告：

1
注意：Rebase 会改变提交历史！
2
这意味着原有的 A、B、C 提交会被重新创建为 A'、B'、C'，
3
它们的 hash 值将与原来完全不同。

特点：

• 创造线性、整洁的提交历史
• 不产生额外的合并提交
• 会改变提交 hash
• 危险：不要对已发布的分支进行变基

适用场景：

• 个人开发分支
• 未推送的提交
• 清理本地提交历史（如 squash）
• 渴望整洁的线性历史

方案三：Fast-Forward Only#

如果你希望保持分支历史的纯净，只接受能够快速前推的更新，可以配置 Git 仅允许 fast-forward 合并。

配置与执行命令：

1
# 设置仅允许 fast-forward 合并
2
git config pull.ff only
3

4
# 执行拉取
5
git pull

当存在分叉时，此命令会失败并报错：

1
fatal: Not possible to fast-forward, aborting.

特点：

• 强制保持线性历史
• 不会产生合并提交
• 不会产生变基提交
• 分叉时直接拒绝操作
• 适用于严格的分支管理策略

适用场景：

• 要求绝对线性历史的团队
• 使用 git flow 的项目
• 需要避免所有合并记录的场景

问题的本质#

分叉（divergence）发生在两条独立的历史线同时推进时。当你执行 git commit 创建新提交时，这条历史线是基于你当时的本地分支状态。与此同时，如果远程分支在其他地方有新提交，这两条历史线就走向了不同的方向。

1
commit 之后 pull 产生分叉的典型场景：
2

3
时间线：
4
┌─────────────────────────────────────────────────────────────┐
5
│                                                             │
6
│  你（本地）                    同事（远程）                   │
7
│     │                            │                          │
8
│     ├─ A ← 你做了 commit        │                          │
9
│     │                            ├─ B ← 同事先 push 了      │
10
│     │                            │                          │
11
│     └─ 此时 pull 会怎样？        │                          │
12
│                                   │                          │
13
└─────────────────────────────────────────────────────────────┘

为什么 Git 无法自动合并#

当你执行 git commit 时，Git 创建了一个新提交对象，它的父提交指向你之前的 HEAD。这个提交对象有一个唯一的 SHA-1 哈希值，基于当时的文件状态和历史。

当你随后执行 git pull 时，Git 发现：

• 你的本地分支有一个新提交（你知道的那个）
• 远程分支也有一个新提交（你不知道的）
• 这两个提交没有直接的父子关系

Git 不知道如何将两条独立的历史合并在一起，因此它需要你的介入来做出选择。

关键误解：pull 不会推送暂存区#

这里有一个常见的误解需要澄清：

git pull 是从远程获取并合并到本地，它永远不会推送任何内容。

无论你执行多少次 git pull，本地暂存区的内容都不会被推送到远程。如果你有暂存的文件，需要：

1
git add .           # 添加到暂存区
2
git commit -m "xxx" # 创建提交
3
git push            # 推送到远程

方式一：git pull —no-rebase（Merge）#

Merge 方式会创建一个合并提交（merge commit），将两条历史线合并在一起。

1
# 默认的 pull 行为（取决于配置）
2
git pull
3

4
# 或者显式指定 merge 方式
5
git pull --no-rebase

结果图示：

1
      A  (你的提交)
2
     /
3
...-M  (远程提交 B)      ← merge commit 有两个父提交
4
     \
5
      B' (合并后的状态)

Merge 的特点：

适用场景：

• 共享分支（main、develop）需要保留完整历史
• 需要清晰看到团队的协作轨迹
• 已推送的提交不希望被修改

方式二：git pull —rebase（Rebase）#

Rebase 方式会将你的提交重写到远程分支最新提交之上，形成线性历史。

1
# 执行 rebase 方式的 pull
2
git pull --rebase

结果图示：

1
              A'  (重放后的提交，全新 hash)
2
             /
3
...-B  (远程提交)

Rebase 的特点：

重要警告：

不要对已推送的提交执行 rebase！

Rebase 会重写提交历史。如果其他人基于你原来的提交工作，这会造成严重的问题。

适用场景：

• 个人开发分支，保持历史整洁
• 本地未推送的提交
• 需要线性历史便于排查问题时

实际效果对比#

假设你基于 commit B 创建了一个功能分支，然后你做了 commit A：

1
初始状态：
2
...-B  (main 分支最新提交)
3
   │
4
   └─ A  (你的功能分支上的提交)

与此同时，main 分支上有人推送了新的 commit C：

1
远程更新后：
2
...-B-C  (main 分支)
3
   │
4
   └─ A  (你的功能分支上的提交，还不知道 C 的存在)

使用 Merge 合并后：

1
       A
2
      / \
3
...-B-C---M  (merge commit)

使用 Rebase 合并后：

1
...-B-C-A'  (A 被重放到 C 之上，变成全新的提交 A')

最佳实践：先 fetch，后决策#

与其等分叉发生了再处理，不如在 commit 之前就了解远程状态：

1
# 1. 先获取远程最新状态（不合并）
2
git fetch origin
3

4
# 2. 查看远程分支的状态
5
git log --oneline origin/main -5
6

7
# 3. 如果远程有更新，再决定如何处理
8
# 个人分支：用 rebase
9
git pull --rebase
10
# 共享分支：用 merge
11
git pull --no-rebase

配置默认 pull 行为#

根据你的工作场景，配置合适的默认行为：

1
# 对于大多数仓库，默认使用 merge
2
git config --global pull.rebase false
3

4
# 对于个人项目较多的仓库，可能更喜欢 rebase
5
git config --global pull.rebase true

在 commit 前检查远程状态#

养成在 commit 之前检查远程状态的习惯：

1
# 查看当前分支与远程分支的差异
2
git status
3

4
# 如果显示 "Your branch is ahead of origin/main by X commits"
5
# 说明你本地的提交还没有同步到远程

使用 pull —ff-only 强制快进#

如果你确定本地没有独立的工作，只想同步远程更新：

1
git fetch origin
2
git pull --ff-only

如果无法快进（例如存在分叉），这个命令会失败并提示你，而不是创建 merge commit 或 rebase。

情况一：刚发生分叉，本地没有其他提交#

如果分叉刚刚发生，你还没有基于这个状态做更多开发，最简单的方式是：

方案 A：Reset 到远程状态，重新来过

1
# 先查看分叉状态
2
git status
3

4
# 放弃本地提交（谨慎操作！）
5
git reset --hard origin/main
6

7
# 然后重新做你的修改
8
git add .
9
git commit -m "你的提交"

方案 B：用 rebase 挽救本地提交

1
# fetch 最新状态
2
git fetch origin
3

4
# 尝试 rebase
5
git rebase origin/main
6

7
# 如果有冲突，解决后继续
8
git add .
9
git rebase --continue
10

11
# 或者放弃 rebase，恢复原状
12
git rebase --abort

情况二：分叉后已经做了多个提交#

如果你已经在一个分叉的状态下做了多个提交，处理起来需要更谨慎：

保留历史用 merge：

1
git fetch origin
2
git merge origin/main
3
# 解决可能的冲突
4
git add .
5
git commit -m "Merge remote changes"
6
git push

整理历史用 rebase（仅限未推送的提交）：

1
git fetch origin
2
git rebase origin/main
3
# 逐个解决冲突
4
# ...
5
git push --force-with-lease

注意：--force-with-lease 比 --force 更安全，它会检查是否有其他人也在推送，避免覆盖别人的工作。

情况三：不确定如何处理，先备份#

在尝试任何修复之前，先备份当前状态：

1
# 创建备份分支
2
git branch backup/my-feature-$(date +%Y%m%d%H%M%S)
3

4
# 然后再尝试修复

日常开发推荐流程#

1
1. 开始新任务前
2
   git fetch origin              # 获取最新状态
3
   git pull origin main          # 同步 main 分支
4
   git checkout -b feature/xxx   # 创建功能分支
5

6
2. 开发过程中
7
   git add .
8
   git commit -m "feat: 完成功能"
9
   git fetch origin              # 再次 fetch 检查远程是否有更新
10

11
3. commit 之前发现远程有更新
12
   git pull --rebase             # 个人分支用 rebase
13
   git push
14

15
4. commit 之后发现分叉
16
   git fetch origin
17
   git pull --rebase             # 或 --no-rebase，看需求
18
   git push

分叉处理决策树#

1
发现分叉
2
    │
3
    ├── 这是个人开发分支？
4
    │       ├── 是 → git pull --rebase → git push
5
    │       └── 否 → git pull --no-rebase → git push
6
    │
7
    ├── 已推送的提交需要保留完整历史？
8
    │       └── 是 → git pull --no-rebase → git push
9
    │
10
    └── 想保持历史整洁且只有本地提交？
11
            └── 是 → git pull --rebase → git push

Q: 为什么我用 git pull 报错了？#

可能的原因：

1. 分支存在分叉，Git 不知道如何合并
2. 存在未解决的冲突
3. 凭证过期（对于 HTTPS 连接）

Q: merge 和 rebase 哪个更好？#

没有绝对的好坏，只有适用场景：

• 公共分支用 merge：保留完整历史，便于追溯
• 个人分支用 rebase：保持历史整洁

Q: 误操作导致分叉，能恢复吗？#

大多数情况下可以：

1
# 查看 reflog 找到之前的 HEAD 状态
2
git reflog
3

4
# 恢复到某个之前的状态
5
git reset --hard HEAD@{5}

Q: 如何避免强制 push？#

配置保护规则：

1
# 在 Git 配置中禁止非快进的推送
2
git config --global push.default simple

在 GitHub/GitLab 等平台也可以在仓库设置中强制启用分支保护。

Q: rebase —continue 和 —skip 区别？#

1
# 解决冲突后
2
git add .
3
git rebase --continue
4

5
# 跳过当前提交（如果冲突无法解决或不需要）
6
git rebase --skip
7

8
# 取消变基，恢复原状态
9
git rebase --abort

Q: force-with-lease 和 force 区别？#

推荐：始终使用 --force-with-lease，它会在有他人新提交时拒绝推送。

Q: 长裤提交历史太多，导致全量clone时的文件太大，拉取失败，如何操作？#

执行 git clone 时，Git 默认会拉取整个仓库的快照，包括所有分支、标签以及完整的历史提交记录。

1. 历史包袱：即使当前仓库很小，但如果历史提交中曾经存在过大文件，或者积累了成千上万次的提交，Git 都需要下载并重建这些历史数据。

2. 压缩与解包：Git 在传输时会对数据进行打包压缩，客户端下载后需要消耗大量内存和 CPU 进行解包（index-pack）和校验。这个过程中，内存占用可能是下载包大小的 3-5 倍，极易触发超时或内存溢出。

解决方法：浅克隆（Shallow Clone） 如果只需要最新的代码，不需要查看历史提交记录，可以使用浅克隆。这会把下载的数据量降到最低：

1
# 只克隆最近一次提交，不拉取任何历史记录
2
git clone --depth=1 https://github.com/用户名/仓库名.git