到目前为止，我们讨论的是理想场景：你编写代码、进行提交（commit）、创建 Pull Request（拉取请求）。但在现实中常常事与愿违：你可能在代码中犯错、用错误的消息提交，或者只是意识到方向不对。在本讲中，我们将介绍如何解决最常见的问题。
1. Rollback — 在提交前撤销更改
场景：你修改了文件，但发现所有改动都不对，想快速把文件恢复到上一次提交后的状态。
使用 Rollback 功能：
- 打开
Commit选项卡。 - 在列表中找到你想“回退”的已修改文件。
- 右键点击它并选择
Rollback。
IDE 会警告你这些更改将会丢失。确认后，文件会立即恢复到 Git 中最后保存的版本。这是撤销本地更改最简单且最安全的方法。
2. Reset — 删除本地提交
场景：你已经做了一次或多次提交，但尚未执行 push。你意识到这些提交有误，想要把它们彻底删除，就像它们从未存在过。
使用 Reset 功能：
- 打开
Git -> Log查看提交历史。 - 找到你希望回到的最后一个“良好”提交（在错误提交之前的那个）。
- 右键点击该提交，选择
Reset Current Branch to Here...。
在弹出的窗口中，你需要选择重置模式。最激进的是 Hard。
注意！ Hard 模式会不可逆地删除所选提交之后的所有提交，以及这些提交中的所有代码更改。务必格外谨慎，只在尚无人看到的提交上使用（那些尚未推送到 GitHub 的提交）。
3. Push 之后该怎么做？
场景：你已经执行了 push，随后才发现其中有错误。
一旦提交到达远程服务器，它就成为项目公共历史的一部分。试图重写这段历史可能会给同事们带来巨大麻烦。想象一下，他们已经拉取了你的更改并基于它开始了工作。
正确且安全的做法：
直接再做一个修复错误的新提交并推送。这是完全正常的实践。这样一来，历史对所有人都保持真实且清晰。
4. 回溯过去：日志的高级用法
我们已经认识了 Git -> Log 选项卡，它不仅是提交列表，更是强大的溯源工具。
- 提交哈希（Commit Hash）：你可能注意到日志里有一串字母和数字，例如
a1b2c3d。这个哈希是唯一的，它允许你精确地引用项目历史中的任意时点。你很少需要手动使用它，但要知道它就是每个代码“快照”的唯一标识。![]()
- 你可以按分支、作者、日期，甚至按提交消息中的词来筛选历史。这有助于快速找到谁在何时处理了某个功能部件。
- 想找到添加或删除某行代码的那次提交吗？在
Log窗口有搜索框，它不仅能按消息搜索，还能按变更内容本身搜索。 - 在代码编辑器的边距处右键并选择
Annotate with Git Blame。IDE 会在每一行旁显示最后一次修改它的人以及所在的提交。这对于理解代码为何这样编写非常有用。
5. 危险地带: Force Push
我们已经确定，修改已推送的提交是一个坏主意。但如果你确实改写了本地历史（例如使用 Reset），导致它与服务器上的历史不一致，会怎样？当你尝试执行普通的 push 时，Git 会报错，以保护公共历史不被改写。
针对这种情况，有一个选项——force push（强制推送）。这条命令告诉服务器：“忘掉你现有的一切。我的本地历史才是唯一正确的。用我的历史替换你的历史”。
警告！ 在 99% 的情况下，在团队项目中使用 force push都是灾难性的。它可能不可逆地删除同事们已经拉取并基于其开展工作的提交。这就像从公共图书馆的书里撕掉页面并粘上你自己的。
以下情况绝对不能使用 force push：
- 任何公共分支：
main、develop、master。永远不要。 - 任何除了你之外还有他人正在使用的分支。
唯一可接受的场景：
你在个人的 feature 分支上工作，且尚无人看过或使用过它。你做了几个“凌乱”的提交，把它们推送到了服务器，随后决定用 Reset 来“整理”一下。在这种情况下，你可以执行 force push 来在创建 Pull Request 之前更新服务器上的分支。
在 IDE 中，这个选项通常隐藏在 Push 按钮之后。IDE 开发者刻意这样设计，以免你不小心点到。
如果你不能 100% 确定自己在做什么——千万不要使用 force push。更安全的做法是创建一个包含修复的新提交。
6. 更新项目
在开始处理新任务之前，请始终在 main 分支上执行 Update Project。这可以避免大量未来的合并冲突，并确保你从最新的代码版本开始工作。
GO TO FULL VERSION