我就想跟大家伙儿聊聊我这实践过程中踩过的那些“交换”的坑，特别是那些一旦操作了，就跟泼出去的水一样，收不回来的版本控制状况。这可都是血泪教训，希望能给大伙儿提个醒。
一、本地分支的“激情”删除
我刚开始用版本控制那会儿，手特快，脑子有时候跟不上。有一次，我本地搞了个新功能分支，写了一堆代码，当时脑子一抽，觉得这个分支名字取得不好，想换一个。我想当然地就直接把这个分支给删了，想着重新建一个，把代码复制过去。
具体操作我记得是这样的：
- 我先切换到主分支。
- 然后，咔嚓一下，就把那个新功能分支给强制删除了。我寻思着，反正代码还在我编辑器里开着，不怕。
小编温馨提醒：本站只提供游戏介绍，下载游戏推荐89游戏，89游戏提供真人恋爱/绅士游戏/3A单机游戏大全，点我立即前往》》》绅士游戏下载专区
结果？我编辑器刚好没设置自动保存，或者是我手贱关了没保存。等我新建好分支，准备粘贴代码的时候，傻眼了，之前写的东西，大部分都没了！ 那叫一个悔，找了半天，本地历史记录也翻了，就是找不回完整的。那感觉，真是想抽自己。从那以后，我删除任何东西之前，都会再三确认，特别是没提交、没推送的东西。
二、远程分支的“强行”推送
这个就更刺激了。有一次，我跟同事合作一个项目。我本地改了些东西，提交了。然后准备推送到远程共享分支。结果，提示我远程分支有新的提交，我需要先拉取合并。
当时我年轻气盛，觉得我的代码才是最新的，最牛的。我就不想去处理那些冲突，觉得麻烦。然后我就上网搜，怎么强制让远程分支跟我本地的一样。搜到了一个命令，大概意思就是“强制推送”。
我想都没想，直接就用了。`git push --force` 一敲，世界清净了。
过了一会儿，同事就找过来了，说他刚提交的代码怎么不见了？我当时还纳闷，后来一合计，才反应过来，我那一把“强行推送”，直接把他辛辛苦苦写的代码给覆盖了！那场面，一度非常尴尬。虽然通过一些手段找回了一部分，但那种破坏了别人劳动成果的负罪感，还有团队协作中造成的麻烦，真是让我记忆犹新。从那以后，但凡涉及到 `--force` 这个词的操作，我都会把手放在键盘上空悬停至少十秒钟，问自己三遍：你确定吗？你知道后果吗？
三、变基操作的“一去不复返”
后来学聪明了点，知道用 `rebase` 能让提交历史变得干净漂亮。有一次，我在一个特性分支上开发，提交了好几次。在准备合并到主分支之前，我想着用 `rebase` 把这些零散的提交合并成一个，显得专业点。
我就开始操作了：
- 找到我要合并的那些提交的父提交。
- 开始交互式变基，`git rebase -i HEAD~N` 这样。
- 然后在编辑界面里，把好几个 `pick` 改成了 `squash` 或者 `fixup`。
结果手一抖，或者理解错了，不小心把一个重要的提交给弄没了，或者合并错了。等变基完成，我一看提交历史，跟我预想的完全不一样，有些关键改动不见了！因为变基是会重写历史的，一旦操作完成，原先的那些提交对象就成了“游离”的，如果不记得它们的哈希值，想找回来就非常困难。尤其是如果这个变基操作之后，你又做了其他提交，那就更难回溯了。那次我折腾了好久，用 `reflog` 才勉强恢复，但也是一身冷汗。变基这玩意儿，本地自己玩玩可以，千万别在已经推送到共享仓库的提交上搞，不然队友会疯的。
四、不小心重置到“远古”版本
还有一次，我想回退本地的修改，就用了 `git reset`。当时我可能没太仔细看参数，一不小心用了 `git reset --hard`，而且后面跟的那个版本号，也不是我想要的最近的那个，而是不知道怎么选的一个比较早的版本。
敲下回车的那一刻，我还没意识到问题的严重性。等我再看工作区和暂存区，哇，一片干净，我最近几天的活儿全没了！ 那种感觉，就好像电脑突然断电，文档没保存一样。因为 `--hard` 参数会直接丢弃工作区和暂存区的所有更改，直接让你的本地回到指定的那个版本状态。如果你那些更改没有提交过，那就真的很难找回来了。
那次教训之后，我用 `reset` 命令时，一般都先用 `--soft` 或者不带参数的（默认是 `--mixed`），这样至少工作区的改动还在，我可以再考虑要不要保留。至于 `--hard`，我现在用得非常非常谨慎，除非我百分之二百确定我知道我在干什么。
版本控制是个好东西，但有些操作确实是“高危”的。我这些“一旦做了就回不去”的经历，都是真金白银（时间、精力，甚至同事关系）换来的教训。希望大家在做类似操作前，一定多想想，多确认，备份别像我当年那么莽撞。小手一抖，一天白干，甚至几天白干，那滋味可不好受！
