6 个灵光乍现的时刻

四年前我换工作的时候，从使用 Subversion（SVN）换成了使用 Git 作为版本控制系统。虽然我学得很快，但还是花了很长时间才真正理解 Git。我读了很多关于 Git 工作原理的资料，但即便如此，我并不总是意识到这些资料对 Git 的使用究竟意味着什么。以下是我在使用 Git 过程中遇到的六个“顿悟时刻”。

顿悟时刻

现在回想起来，这些顿悟的时刻都感觉显而易见。但我记得，当我理解了一个概念，并意识到可以用 git 来做什么时，我的确会想到“啊哈”。

1. 本地和远程更改是独立的。我经常使用“svn status -u”来查看运行 svn update 后会得到哪些更改。一开始，我对 git 中的等效操作感到困惑。你可以运行 git status，它会显示本地更改与上次拉取的更改的对比情况。但要查看服务器上的更改，我首先需要执行 git fetch。“存在两组独立的更改——本地更改和服务器上的更改（由其他人推送到服务器上）”这个概念，我花了一段时间才真正理解。

2. 合并使旧提交可访问。我花了很长时间才意识到，合并只是使已经存在的提交可访问。最初，我对合并的理解是，合并分支中的所有更改在合并时都成为提交。意识到一个分支的提交仍然存在，而合并只是让它们在另一个分支中“可见”，这有助于解释一些奇怪的事情。例如，显示文件的 git log（例如在 PyCharm 中）可以显示来自两个不同分支的交错提交。显示两个提交（时间相邻，但在两个不同的分支上）之间的差异可能会产生非常大的差异。

3. 合并提交的含义。由于我对合并的理解并不完整，合并提交对我来说曾经有点神秘。我把提交仅仅看作“这次提交的代码有什么不同”，从这个角度来看，合并提交毫无意义。它们通常都是空的，没有任何代码差异。现在我当然明白了，查看另一个分支的提交在什么时候通过合并变得可访问是很重要的。

4. 您可以双向合并。如果您有一个长期运行的分支b，最终想要将其合并回 master，您可以通过定期将 master 合并到 b 来逐步解决合并冲突（并修复任何出现的合并冲突）。最终，我希望将b中的所有更改合并到 master，但这只有在b正常运行时才能实现。当我意识到不必等到b完成后再解决某些合并冲突时，我顿悟了。定期将 master 合并到b意味着，当我最终将b合并到 master 时，大多数合并冲突已经得到处理。

5. 合并失败后可以重新开始。我使用 SVN 时，经常使用 –dry-run 来查看执行某个操作（但实际上不执行）后会发生什么。在 git 中，我花了一段时间才意识到同样的功能存在，只是没有明确定义。例如，如果我合并了一些更改，但在解决合并冲突时遇到了麻烦，我只需返回上一步，然后重新执行即可。只要我没有推送到服务器，执行“git reset –hard HEAD~”就可以返回。现在我只需再次执行合并，并希望这次能够正确解决冲突。知道几乎我用 git 做的所有事情都可以轻松地恢复、撤销或重做，这让我感到非常轻松。

6.已提交的更改可以重新重置为本地更改。有时我在分支b上进行本地更改工作，需要检出另一个分支并在那里做一些工作。过去，我经常会存储本地更改。但现在我经常提交本地更改，并附带一条提交消息，说明工作正在进行中 (WIP)。我不会将这些更改推送到服务器。当我回到分支b时，我会执行“git reset HEAD~”以将已提交的更改重新重置为本地更改。在分支上进行 WIP 提交意味着我不必跟踪存储的更改是针对哪个分支的。当我意识到我可以再次将提交“撤消”为本地更改时，我恍然大悟。

结论

我记得我读过很多关于如何使用 git 以及 git 是如何组织的教程。但即使了解了 git 的工作原理，也并不意味着我就能理解如何使用 git。上述顿悟时刻仅仅依赖于理解一些事情——本地变更，以及分支和合并的工作原理。以我现在所了解的，所有这些见解似乎都微不足道。然而，我清楚地记得，当我开始学习 git 时，这些对我来说并不明显。希望这些顿悟时刻能对其他 git 新手有所帮助。