6 个灵光乍现的时刻

2025-06-07

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 新手有所帮助。

文章来源:https://dev.to/henrikwarne/6-git-aha-moments-3097
PREV
使用 NodeJS 拦截 HTTP 请求
NEXT
使用 Angular、NestJS 和 Nx 构建全栈 Web 应用程序 - 天作之合 为什么要写这篇文章?搭建脚手架 运行项目 调整应用程序以进行开发 从单个服务器提供前端和后端以进行生产 打包应用程序以进行部署