惊魂一刻！我竟用git rebase让同事代码消失，最后如何化险为夷？

前言

事情的起因是这样的：上周我在项目里用 git rebase 整理分支，结果把同事的提交“消失”了，虽然最后救回来了，但大家吓出一身冷汗。这次事件让我彻底搞清楚了 rebase 和 merge 的区别，以及它们各自适合的场景。

一、先还原“事故现场”

假设我们有这样一个场景：

提交历史长这样：

main:    A --- B --- C (bug 修复)
           \
feature:    D --- E (你的新功能)

你用 git rebase main

git checkout feature
git rebase main

这会变成这样：

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

看起来很整齐，但如果你本地的 feature 没有先拉同事的最新提交，或者在 rebase 过程里解决冲突时手滑丢掉了同事的改动，push 上去时可能直接覆盖掉远程历史，让同事的代码凭空消失。

这就是我当时踩的坑。

二、rebase 和 merge 到底有什么区别？

1. git merge —— 历史完整，简单安全

示例：

git checkout feature
git merge main

结果：

A --- B --- C ------ M (merge commit)
 \              /
  D --- E -----

特点：

2. git rebase —— 历史干净，但会改动历史

示例：

git checkout feature
git rebase main

结果：

A --- B --- C --- D' --- E'

特点：

三、各自的安全使用场景

本地分支开发，还没 push 给别人

rebase

整理历史，方便以后合并

拉取远程更新并保持历史干净

pull --rebase

避免多余的 merge commit

已经 push，且有同事基于它开发

merge

避免改写历史导致冲突

大型团队的主分支合并

merge

保留历史，方便追溯

个人项目或短期功能分支

rebase

历史整洁，美观

四、如何避免 rebase 导致代码丢失？

1. 不要在公共分支上 rebase（例如 main、dev）

2. 如果必须 rebase，先确保拉取远程最新代码：

   git fetch origin
   git rebase origin/main
   

3. 解决冲突时仔细检查改动，确保同事的提交没有被覆盖

4. rebase 失败或出错时，可以用：

   git rebase --abort
   

5. 养成推送前检查差异的习惯：

   git log --oneline --graph --decorate
   git diff
   

五、我的经验总结

结语

写在最后，这次的事故让我明白：Git 是个很宽容的工具，但对历史的操作必须敬畏。代码丢失不可怕，可怕的是我们连为什么丢都不知道。理解 merge 和 rebase 的底层行为，才能在团队里安全高效地用好它们。