专业工具与问题解决

到目前为止我们讨论的是理想场景：你写代码、做 commit、创建 Pull Request。但在真实情况中经常会出错：你可能在代码里犯了错误、提交了错误的消息，或者只是意识到自己走错了方向。在本讲我们会讲如何解决最常见的问题。

1. Rollback — 在提交前撤销更改

场景：你修改了文件，但发现所有改动都是错的，想快速把文件恢复到上一次 commit 后的状态。

使用 Rollback 功能：

1. 打开 Commit 面板。
2. 在列表中找到你想要“回滚”的被修改文件。
3. 右键点击它并选择 Rollback。

IDE 会提示你更改将被丢弃。确认后，文件会立即恢复到 Git 中最后一次保存的版本。这是撤销本地更改最简单且最安全的方式。

2. Reset — 删除本地提交

场景：你做了一个或多个 commit，但还没有做 push。你发现这些 commit 是错误的，想彻底删除它们，就好像它们从未存在过。

使用 Reset 功能：

1. 打开 Git -> Log 面板，以查看提交历史。
2. 找到你想回到的最后一个“正确”提交（就是在错误提交之前的那个）。
3. 右键点击它并选择 Reset Current Branch to Here...。

在打开的窗口中会让你选择重置模式。最激进的是 Hard。

注意！ Hard 模式会不可恢复地删除所选提交之后的所有提交，以及那些提交中包含的所有代码更改。请非常小心地使用它，并且仅对那些还没有被任何人看到的提交使用（也就是还没被推到 GitHub 的提交）。

3. Push 之后怎么办？

场景：你做了 push，之后才发现里面有错误。

一旦提交到了远程服务器，它就成为项目共同历史的一部分。试图改写这段历史可能会给同事带来巨大的麻烦。想象一下，他们已经拉取了你的更改并在此基础上工作。

正确且安全的做法：

直接做一个新的提交来修复错误并推送它。这是完全正常的做法。这样历史保持诚实且对所有人都清晰。

4. 回顾过去：进阶的 log 使用

我们已经熟悉了 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。这可以帮你避免很多将来合并冲突，并保证你从最新的代码版本开始工作。