当 Git Pull 把工作区搅成一锅粥：理解 Merge 与 Abort

1. 一个很常见、也很吓人的场景

想象一下，你正在本地开发一个功能分支：

git status

输出大概是这样：

On branch feature/order-refactor

Changes not staged for commit:
  modified:   src/order/service.js
  modified:   src/order/validator.js

Untracked files:
  src/order/debug-helper.js

你还没提交，因为功能没写完。 这时候你想看看远程有没有新代码，手一快执行了：

git pull

然后灾难来了：

Auto-merging src/order/service.js
CONFLICT (content): Merge conflict in src/order/service.js
Automatic merge failed; fix conflicts and then commit the result.

你再打开文件，发现里面变成了这样：

function calculateOrder(order) {
<<<<<<< HEAD
  return calculateByLocalRule(order)
=======
  return calculateByRemoteRule(order)
>>>>>>> origin/feature/order-refactor
}

这时你的大脑开始混乱：

"这是我的代码还是远程代码？"

"我本地没提交的修改还在吗？"

"现在这个仓库到底处在什么状态？"

"我能不能撤销这次 pull，回到 pull 之前？"

答案是：大多数情况下可以。

你需要了解的是：

git merge --abort

但在真正使用它之前，我们先把 git merge 本身讲明白。

---

2. git pull 和 git merge 到底是什么关系？

很多人以为 git pull 是一个单独的神秘动作，其实它通常可以拆成两步：

git fetch
git merge

也就是说：

git pull

大致等价于：

git fetch origin
git merge origin/当前分支

当然，如果你的配置启用了 rebase，那么 git pull 可能等价于：

git fetch
git rebase

所以，遇到冲突后，第一件事不是乱敲命令，而是先看状态：

git status

如果你看到：

You have unmerged paths.

并且提示：

fix conflicts and run "git commit"
use "git merge --abort" to abort the merge

说明你现在处于 merge 冲突状态。

如果你看到：

You are currently rebasing

说明你现在处于 rebase 状态 ，那就不是 git merge --abort，而是：

git rebase --abort

本文重点讲 merge，因此我们继续看 git merge。

---

3. git merge 是什么？

git merge 的作用是：把另一个分支的提交合并到当前分支。

比如你当前在 feature/order-refactor：

git branch

输出：

* feature/order-refactor
  main

现在你想把 main 的最新代码合进来：

git merge main

这句话的意思是：

Git，请把 main 分支里的变化合并到我当前所在的分支。

注意： merge 永远是合并到当前分支。

也就是说：

git merge main

不是把当前分支合并到 main，而是把 main 合并到当前分支。

这是很多 Git 初学者最容易弄反的地方。

---

4. Git 合并时在比较什么？

Git 的合并通常不是简单地把两个文件拼起来。

它会尝试做"三方合并"。

三方分别是：

1. 当前分支的版本
2. 要合并进来的分支版本
3. 两个分支共同的祖先版本

举个例子：

        A---B---C  feature
       /
D---E---F---G      main

如果你在 feature 分支上执行：

git merge main

Git 会找到 feature 和 main 的共同祖先，比如 E。

然后比较：

E -> C  当前分支做了什么
E -> G  main 分支做了什么

如果两边改的是不同文件，或者同一个文件的不同位置，Git 通常能自动合并。

如果两边改了同一个文件的同一块区域，Git 就不知道该听谁的，于是产生冲突。

---

5. 什么是 Fast-forward Merge？

先看一个简单情况：

A---B---C  main
         \
          D---E  feature

如果 main 没有新提交，而 feature 只是接在 main 后面，那么把 feature 合进 main 时，Git 不需要创建新的合并提交。

它只需要把 main 指针往前移动：

A---B---C---D---E  main, feature

这叫 fast-forward merge，中文常说"快进合并"。

命令：

git checkout main
git merge feature

如果可以快进，Git 会提示类似：

Fast-forward

这种合并没有分叉，也通常不会生成新的 merge commit。

---

6. 什么是真正的 Merge Commit？

再看另一个情况：

        D---E  feature
       /
A---B---C---F  main

现在 main 和 feature 都向前发展了。

你在 main 上执行：

git merge feature

Git 不能简单地移动指针，因为 main 上也有自己的新提交 F。

于是 Git 会创建一个新的合并提交：

        D---E
       /     \
A---B---C---F---M  main

这里的 M 就是 merge commit。

merge commit 有两个父提交：

1. F：当前分支原来的最新提交
2. E：被合并分支的最新提交

这就是 Git 历史里常见的"分叉又汇合"的形状。

---

7. Merge 为什么会冲突？

冲突不是 Git 坏了。

冲突的意思是：

Git 无法确定应该保留哪一边的修改，需要人来判断。

比如共同祖先文件是：

function getPrice(product) {
  return product.price
}

你的分支改成：

function getPrice(product) {
  return product.discountPrice
}

远程分支改成：

function getPrice(product) {
  return product.salePrice
}

这时 Git 没法知道哪个才是业务正确答案。

于是文件中会出现：

function getPrice(product) {
<<<<<<< HEAD
  return product.discountPrice
=======
  return product.salePrice
>>>>>>> origin/main
}

这里：

<<<<<<< HEAD

表示当前分支的内容。

=======

是分隔线。

>>>>>>> origin/main

表示被合并进来的分支内容。

这不是 Git 在胡乱污染文件，而是 Git 在告诉你：

我不知道该怎么合，请你来决定。

---

8. 冲突状态下，Git 仓库发生了什么？

当 merge 出现冲突时，Git 不会立刻创建 merge commit。

它会让仓库停在一个"合并进行中"的状态。

你可以执行：

git status

看到类似：

On branch feature/order-refactor
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  both modified:   src/order/service.js

这时仓库里通常存在一些合并相关的内部状态，比如：

.git/MERGE_HEAD
.git/MERGE_MSG

你不需要手动编辑这些文件，但知道它们存在有助于理解：

Git 不是"忘了自己在干什么"，它清楚地知道现在正处于一次未完成的 merge 中。

在这个状态下，你通常有三条路：

1. 解决冲突，然后提交 merge commit
2. 放弃这次 merge，回到 merge 之前
3. 先备份，再手动抢救某些文件

而 git merge --abort 对应的是第二条路。

---

9. git merge --abort 是什么？

git merge --abort 的作用是：

取消当前正在进行的 merge，并尽量恢复到 merge 开始之前的状态。

命令很简单：

git merge --abort

它常用于这种场景：

git pull
# 出现冲突
git status
# 确认处于 merge 状态
git merge --abort

执行成功后，Git 会退出合并状态。

也就是说：

• .git/MERGE_HEAD 等 merge 状态会被清理
• 已经应用到工作区的合并结果会被撤销
• 当前分支 HEAD 回到 merge 开始之前的位置
• 原本在 merge 前已经存在的本地修改，Git 会尽量保留

注意这句里的关键词：尽量。

---

10. 为什么说"尽量恢复"？

因为你执行 merge 之前，工作区可能本来就不是干净的。

比如 merge 之前你已经有本地修改：

modified: src/order/service.js
untracked: src/order/debug-helper.js

然后你执行：

git pull

Git 尝试把远程变更叠进来，结果冲突了。

这时工作区里同时混有：

1. 你 pull 前自己的修改
2. 远程拉下来的修改
3. Git 标记出来的冲突内容
4. 可能还有自动合并成功的文件修改

git merge --abort 会尝试撤销第 2、3、4 部分，把你带回 pull 前。

但如果你在冲突之后又手动编辑了很多文件，情况就复杂了。

比如：

git pull
# 出冲突
# 你打开文件改了一堆
git merge --abort

这时 Git 要判断哪些是 merge 产生的，哪些是你后来手动改的，并不总是完美。

所以在复杂冲突现场，建议先备份。

---

11. 最稳妥的事故现场处理流程

当你发现误执行了 git pull，并且冲突内容和本地修改混在一起时，不要慌，也不要马上重置。

推荐流程如下。

第一步：不要继续操作

先停下来。

尤其不要急着执行：

git add .
git commit

也不要随便执行：

git reset --hard

git reset --hard 很危险，因为它会丢弃工作区和暂存区里的修改。

如果你本地有未提交代码，贸然执行可能直接丢掉。

---

第二步：先看状态

git status

如果输出里明确有：

You have unmerged paths.

并提示：

use "git merge --abort" to abort the merge

那基本可以判断你在 merge 状态。

---

第三步：备份当前目录

在仓库根目录执行：

backup_dir="../$(basename "$PWD")-backup-before-abort-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$backup_dir"
rsync -a --exclude='.git' ./ "$backup_dir"/
echo "backup saved to $backup_dir"

这一步会把当前工作区文件复制到仓库外的一个备份目录中，但不复制 .git。

为什么不复制 .git？

因为我们主要想保留"文件内容现场"，不是复制整个 Git 数据库。

如果系统没有 rsync，也可以用普通复制方式，比如：

cp -R . ../repo-backup-before-abort

但要注意 .git 目录可能很大，而且复制它没有必要。

---

第四步：执行 abort

git merge --abort

如果成功，它通常不会输出太多内容。

然后再看状态：

git status

你希望看到的是：

Changes not staged for commit:
  modified: ...

Untracked files:
  ...

而不是：

You have unmerged paths.

也就是说，仓库已经离开 merge 状态，只剩下你原来的本地修改。

---

12. git merge --abort 和 git reset --merge ORIG_HEAD

有时候你会看到别人建议：

git reset --merge ORIG_HEAD

这条命令和 git merge --abort 有关系。

当一次 merge 开始时，Git 通常会记录 merge 前的 HEAD 到 ORIG_HEAD。

你可以粗略理解为：

ORIG_HEAD 是 Git 给你留的一张"出发前的位置快照"。

如果 merge 出问题，可以用它回到 merge 前：

git reset --merge ORIG_HEAD

git merge --abort 在很多普通场景下可以理解为更语义化、更直观的撤销 merge 命令。

也就是说：

git merge --abort

表达的是：

Git，请取消这次正在进行的合并。

而：

git reset --merge ORIG_HEAD

表达的是：

Git，请把当前状态重置回 merge 前记录的位置，同时尽量保留本地修改。

日常使用时，优先推荐：

git merge --abort

当它失败或不可用时，再考虑：

git reset --merge ORIG_HEAD

---

13. git merge --abort 和 git reset --hard 的区别

这两个命令千万不要混淆。

git merge --abort

作用：

取消正在进行的 merge

特点：

• 用于 merge 冲突状态
• 目标是回到 merge 前
• 尽量保留 merge 前已经存在的本地修改
• 相对安全

git reset --hard

作用：

强制把 HEAD、暂存区、工作区全部重置到指定提交

比如：

git reset --hard HEAD

意味着：

把当前分支恢复到 HEAD 对应的提交，丢弃工作区和暂存区修改。

它会删除已跟踪文件的本地修改。

但通常不会删除未跟踪文件。

如果你还执行了：

git clean -fd

那未跟踪文件也会被删。

所以危险组合是：

git reset --hard
git clean -fd

这对未提交工作区来说非常危险。

在冲突现场，除非你非常确定自己不要任何本地修改，否则不要用它们。

---

14. git merge --abort 会删除未跟踪文件吗？

一般不会。

比如你 pull 前有：

Untracked files:
  src/order/debug-helper.js

执行：

git merge --abort

这个未跟踪文件通常还会保留。

因为它不属于 Git 已跟踪内容，Git merge 本身不会把它当作合并对象处理。

但是仍然建议备份，原因是：

1. 你可能在冲突后手动改过它
2. 某些构建工具可能生成或覆盖文件
3. 你可能后续误执行其他清理命令
4. 真实项目里文件状态往往比想象复杂

Git 本身相对可靠，人类手滑才是最大风险。

---

15. git merge --abort 什么时候会失败？

它并不是万能命令。

常见失败原因包括：

1. 当前不在 merge 状态

比如你执行：

git merge --abort

结果：

fatal: There is no merge to abort

说明当前没有正在进行的 merge。

这时候你应该先看：

git status

如果是 rebase，就用：

git rebase --abort

如果是 cherry-pick，就可能需要：

git cherry-pick --abort

如果是 revert，就可能需要：

git revert --abort

不同操作有不同的 abort。

---

2. 冲突后你又改了太多内容

例如：

git pull
# 出冲突
vim src/order/service.js
vim src/order/validator.js
git merge --abort

Git 可能发现某些文件已经不是它能安全恢复的状态。

这时它可能拒绝操作，避免覆盖你的修改。

解决方式通常是：

1. 先手动备份当前文件
2. 再尝试 git merge --abort
3. 如果仍失败，使用 git status、git diff、git diff --staged 分析
4. 必要时从备份中手动恢复

---

3. 你已经 git add 了一部分冲突文件

git add 表示你告诉 Git：

这个文件我已经处理好了。

如果你处理到一半又想 abort，一般仍可以尝试：

git merge --abort

但如果期间又混入了额外修改，恢复难度会增加。

所以冲突处理时要养成习惯：

• 要么明确解决冲突
• 要么立刻 abort
• 不要在冲突状态下同时做新功能开发

---

16. 场景一：误执行 git pull，想回到 pull 前

这是最贴近日常的场景。

当前状态：

git status

输出：

On branch feature/order-refactor
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

推荐操作：

# 1. 备份
backup_dir="../$(basename "$PWD")-backup-before-abort-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$backup_dir"
rsync -a --exclude='.git' ./ "$backup_dir"/

# 2. 取消 merge
git merge --abort

# 3. 查看状态
git status

如果成功，你会回到 pull 前的状态。

接下来，你可以更安全地处理：

git stash push -u -m "WIP before pulling remote changes"
git pull
git stash pop

或者先提交本地修改：

git add .
git commit -m "WIP: order refactor"
git pull

是否使用 WIP commit 取决于团队规范。

---

17. 场景二：合并错了分支

你本来想在 feature/login 上合并 main，结果手滑合并了 feature/payment：

git merge feature/payment

如果没有冲突，并且 merge commit 已经生成，那 git merge --abort 就不能用了。

因为 merge 已经结束了。

这时你看到的可能是：

Merge made by the 'ort' strategy.

再执行：

git merge --abort

会得到：

fatal: There is no merge to abort

因为已经没有"正在进行的 merge"。

如果 merge commit 还没推送，通常可以用：

git reset --hard ORIG_HEAD

但这会丢弃 merge 之后的工作区修改，所以必须非常小心。

更稳妥的做法是先看历史：

git log --oneline --graph --decorate -n 10

确认刚刚的 merge commit 是否就是最新提交。

如果已经推送到远程共享分支，就不要随便 reset，应考虑：

git revert -m 1 <merge_commit_hash>

这个话题属于"撤销已完成 merge"，和 git merge --abort 是不同问题。

一句话总结：

git merge --abort 只能取消正在进行中、还没完成提交的 merge。

---

18. 场景三：合并冲突太多，想先撤退重来

你执行：

git merge main

结果几十个文件冲突。

这时你可能意识到：

"我不应该直接 merge，我应该先整理本地提交，或者先找同事确认。"

此时非常适合：

git merge --abort

撤退之后，你可以选择更有计划的方式。

比如先看 main 和当前分支差了什么：

git fetch origin
git log --oneline --graph --decorate HEAD..origin/main

或者看哪些文件会受影响：

git diff --name-only HEAD origin/main

再决定是：

git merge origin/main

还是：

git rebase origin/main

或者先拆小提交、先提 PR、先和团队同步。

git merge --abort 的价值就在这里：

它允许你在发现合并成本过高时，安全撤退，而不是硬着头皮在冲突泥潭里越陷越深。

---

19. 场景四：正在合并时，发现工作区本来就不干净

这是最容易出事故的情况。

比如你一开始就有：

modified: src/foo.js
untracked: scripts/bar.js

然后执行：

git pull

出现冲突。

此时你的目标不是"回到远程最新"，而是：

回到 pull 之前，我本地改了哪些文件就还是哪些文件。

最佳操作是：

git merge --abort

执行前建议备份：

backup_dir="../$(basename "$PWD")-backup-before-abort-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$backup_dir"
rsync -a --exclude='.git' ./ "$backup_dir"/

执行后：

git status

确认只剩原来的修改。

然后你可以选择：

git stash push -u -m "WIP before sync"
git pull
git stash pop

这里的 -u 很重要。

普通：

git stash

默认不会保存未跟踪文件。

而：

git stash push -u

会把未跟踪文件也一起保存。

---

20. 合并前更好的习惯

git merge --abort 是安全绳，但最好的事故是不要发生。

合并或 pull 前，建议先执行：

git status

如果工作区不干净，可以选择三种方式。

方式一：提交当前修改

git add .
git commit -m "WIP: describe local changes"
git pull

优点：

• 修改进入 Git 历史
• 不容易丢
• 后续可以 reset、revert、cherry-pick

缺点：

• WIP 提交可能污染历史
• 团队可能不喜欢无意义提交

可以后续用交互式 rebase 整理。

---

方式二：stash 当前修改

git stash push -u -m "WIP before pull"
git pull
git stash pop

优点：

• 不产生提交
• 适合临时保存现场
• 可以包含未跟踪文件

缺点：

• stash pop 也可能产生冲突
• stash 多了容易忘

查看 stash：

git stash list

恢复但不删除 stash：

git stash apply stash@{0}

恢复并删除 stash：

git stash pop

---

方式三：新建临时分支保存现场

git switch -c wip/order-refactor-backup
git add .
git commit -m "WIP backup before pulling"

然后回到原分支操作。

这种方式看起来笨，但非常稳。

尤其是多人协作、大改动、复杂冲突场景下，它比 stash 更直观。

---

21. git merge --abort 不是什么？

为了避免误用，需要明确几个边界。

它不是撤销所有本地修改

如果你本地原来就修改了文件，git merge --abort 的目标不是清空这些修改，而是回到 merge 前。

所以 abort 后仍看到：

Changes not staged for commit

这不一定是坏事，可能正是你原来的代码。

---

它不是撤销已经完成的 merge commit

如果 merge 已经成功并提交了：

Merge made by the 'ort' strategy.

那就没有 merge 可以 abort。

这时要考虑：

git reset

或：

git revert

具体取决于是否已经推送、是否是共享分支、团队协作规则是什么。

---

它不是解决冲突

git merge --abort 不会帮你选当前版本或远程版本。

它只是说：

这次合并我不做了。

如果你想完成合并，需要手动解决冲突：

# 编辑冲突文件
git add <file>
git commit

---

22. 冲突文件里的 ours 和 theirs

处理 merge 冲突时，经常会看到：

git checkout --ours <file>
git checkout --theirs <file>

或者新版本写法：

git restore --source=HEAD -- <file>

这里简单解释一下。

在 merge 冲突中：

• ours：当前分支的版本
• theirs：被合并进来的分支版本

比如你当前在 feature：

git merge main

那么：

ours   = feature 里的版本
theirs = main 里的版本

如果你想对某个冲突文件完全保留当前分支版本：

git checkout --ours src/order/service.js
git add src/order/service.js

如果你想完全采用被合并分支版本：

git checkout --theirs src/order/service.js
git add src/order/service.js

不过这已经是"继续完成 merge"的路线，不是 abort 路线。

---

23. Merge、Rebase、Cherry-pick 都有自己的 Abort

很多 Git 操作都有"进行中"的状态。

不同操作要用不同 abort。

当前状态	查看方式	取消命令
merge 中	git status 显示 merging / unmerged paths	git merge --abort
rebase 中	git status 显示 rebasing	git rebase --abort
cherry-pick 中	git status 显示 cherry-picking	git cherry-pick --abort
revert 中	git status 显示 reverting	git revert --abort

所以遇到问题先看：

git status

不要凭感觉猜命令。

git status 是 Git 给你的现场报告。

---

24. 一个完整演示：从制造冲突到安全撤销

下面用一个简化例子演示。

初始化仓库：

mkdir merge-demo
cd merge-demo
git init

创建文件：

echo "version=base" > config.txt
git add config.txt
git commit -m "initial config"

创建功能分支：

git switch -c feature
echo "version=feature" > config.txt
git commit -am "change config in feature"

回到主分支修改同一行：

git switch main
echo "version=main" > config.txt
git commit -am "change config in main"

现在合并：

git merge feature

出现冲突：

Auto-merging config.txt
CONFLICT (content): Merge conflict in config.txt
Automatic merge failed; fix conflicts and then commit the result.

查看文件：

cat config.txt

可能看到：

<<<<<<< HEAD
version=main
=======
version=feature
>>>>>>> feature

查看状态：

git status

输出会提示可以：

git merge --abort

执行：

git merge --abort

再看文件：

cat config.txt

回到：

version=main

再看状态：

git status

仓库已经退出 merge 状态。

这个演示说明：

git merge --abort 会放弃这次未完成的合并，让当前分支回到合并前。

---

25. 一张心智图：merge 冲突后怎么选？

当你看到冲突，不要慌，按下面判断：

出现 merge 冲突
    |
    v
git status
    |
    +-- 是 merge 状态？
    |       |
    |       +-- 想继续合并？
    |       |       |
    |       |       +-- 编辑冲突文件 -> git add -> git commit
    |       |
    |       +-- 想放弃这次合并？
    |               |
    |               +-- 先备份 -> git merge --abort
    |
    +-- 是 rebase 状态？
    |       |
    |       +-- git rebase --abort
    |
    +-- 是 cherry-pick 状态？
            |
            +-- git cherry-pick --abort

核心永远是：

git status

---

26. 团队协作中的建议

在多人项目中，merge 不只是技术操作，也涉及协作习惯。

1. 不要在脏工作区里随手 pull

脏工作区指的是：

modified files
untracked files
staged but uncommitted changes

执行 pull 前先看：

git status

这是最简单但最有效的习惯。

---

2. 合并前先 fetch

相比直接：

git pull

更稳的做法是：

git fetch origin

然后查看远程变化：

git log --oneline --graph --decorate HEAD..origin/main
git diff --name-only HEAD origin/main

确认之后再：

git merge origin/main

这样你知道自己合进来的是什么。

---

3. 大冲突不要硬解

如果冲突几十个文件，先停下来。

可能说明：

• 分支落后太久
• 两个人改了同一块核心逻辑
• 合并方向不对
• 应该拆分提交
• 应该先和相关同事沟通

这时：

git merge --abort

是一种成熟的工程判断，不是失败。

优秀的开发者不是永远不遇到冲突，而是知道什么时候继续、什么时候撤退。

---

27. 常见问答

Q1：git merge --abort 会丢代码吗？

它的目标是回到 merge 前，并尽量保留 merge 前已有的本地修改。

但如果你在冲突后又手动改了很多内容，或者现场很复杂，仍建议先备份。

保险命令：

backup_dir="../$(basename "$PWD")-backup-before-abort-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$backup_dir"
rsync -a --exclude='.git' ./ "$backup_dir"/

---

Q2：我已经解决了一部分冲突，还能 abort 吗？

通常可以尝试：

git merge --abort

但它会放弃整个 merge，而不是只撤销未解决部分。

如果你已经花了很久解决冲突，建议先备份当前文件，再决定是否 abort。

---

Q3：git pull 后冲突，应该用 merge --abort 还是 rebase --abort？

看：

git status

如果提示 merge：

git merge --abort

如果提示 rebase：

git rebase --abort

不要猜。

---

Q4：abort 后远程代码还在本地吗？

如果你是通过 git pull 拉下来的，fetch 取得的远程引用通常仍然存在，比如：

origin/main

merge --abort 取消的是"把远程变更合进当前工作区"的过程，不等于把远程引用删掉。

你之后仍然可以重新 merge：

git merge origin/main

---

Q5：我想彻底不要本地所有修改，怎么做？

这不是 git merge --abort 的任务。

如果你非常确定本地修改都不要了，可以考虑：

git reset --hard HEAD

如果还想删除未跟踪文件：

git clean -fd

但这两个命令危险程度很高，执行前一定确认没有需要保留的文件。

更稳的方式是先备份。

---

28. 总结

git merge 的本质，是把另一个分支的提交合入当前分支。

它可能有三种结果：

1. 快进合并：直接移动分支指针
2. 自动合并成功：生成 merge commit
3. 出现冲突：进入 merge 进行中状态

当你处于第三种状态，并且想放弃这次合并时，就可以使用：

git merge --abort

它的意义不是"清空本地修改"，而是：

取消当前未完成的 merge，尽量回到 merge 开始之前。

在误执行 git pull、冲突过多、合错分支、工作区本来就不干净等场景下，git merge --abort 是非常重要的撤退命令。

最后记住这几条 Git 生存法则：

git status

永远先看状态。

git merge --abort

用于取消正在进行的 merge。

git rebase --abort

用于取消正在进行的 rebase。

git reset --hard

很危险，不要在没备份时乱用。

git stash push -u

能在 pull 前保存包含未跟踪文件的工作区现场。

Git 的强大不在于永远不出错，而在于大多数错误都有撤退路线。 学会 git merge --abort，就是学会在合并事故里优雅地按下"撤退"按钮。