为什么人们不善用Git？

# 为什么人们不会正确使用 Git？| deadSimpleTech 来源：https://deadsimpletech.com/blog/why-dont-people-use-git-properly *我念叨了有一阵子的那个教育项目，现在有了名字，还有了落地页。快来认识一下 Arca (https://deadsimpletech.com/arca)。抢先体验版有望下周发布：与此同时，我仍在通过给写作项目捐款的方式，赠送个别体验名额。* Git 是一款深刻影响软件世界面貌的工具。它最初是为了满足 Linux 内核开发者的需求而开发的，如今已成为软件领域最流行的版本控制系统，并且，无论好坏，几乎每个人都在使用它。GitHub 是微软目前业务的重要组成部分，而它基本上就是一个公开的 Git 远程仓库。大多数 PaaS 系统都将 Git 仓库视为其部署业务的基本构件，而大多数 CI/CD 系统首先期望的也是一个 Git 仓库。 这就引出了一个令人担忧的事实：科技界有相当多的人，以及在各种场景下编写代码的人中更大比例的人，根本不能很好地使用 Git。他们一遇到合并冲突就惊慌失措。他们用 Claude Code 提交 12,000 行代码，并附上糟糕的提交信息。他们不知道如何创建分支。他们未能保护远程仓库中的 `main` 分支，然后另一个也不懂 Git 的人推送到上面，意外清空了生产数据库。极端情况下，他们通过手动上传文件来“提交”，或者根本不使用版本控制，因为那是新奇且可疑的技术。人们确实以各种方式，在正确使用这项技术上苦苦挣扎。理解为什么会这样可能很有用，这就是本文的主题。 （说明：这里我主要从单个开发者的角度来写，这意味着我没有过多谈论分支、拉取请求或大型团队真正需要的那些工具。部分原因是这方面我经验不多，部分原因是我认为这些对于阐述我的核心论点来说并非直接必要。） ## 问题的本质 幸运的是，如今很少有靠写软件谋生的人完全没有使用任何版本控制（尽管这种情况发生的频率，比我们任何一个人愿意接受的都要高 (https://softwareengineering.stackexchange.com/questions/112270/is-it-unusual-for-a-small-company-15-developers-not-to-use-managed-source-vers)）。在以编写软件为核心业务的公司里，这几乎是闻所未闻的。然而，这并不能排除在使用这些工具时出现的各种失败模式，总体而言，人们使用 Git 的方式非常糟糕。 我见过的最糟糕的失败模式，是一个团队为一个分析脚本集合维护了一个“Git 仓库”，那其实只是一个共享驱动器上的目录。严格来说，它确实被初始化为一个 Git 仓库，但实际上并没有被当作仓库来使用：相反，这个目录里包含了代码的压缩副本，并用修改时间戳做了标记。几乎看不到任何提交，说实话，我也不敢尝试从它们那里创建任何有意义的分支。当然，也没有命令行界面之类的东西，他们可用的 Git GUI 软件混乱到连我都感到困惑。在这种情况下，是的，*技术上*他们在使用 Git，但任何实际意义上都显然不是这样。 这个团队是怎么陷入这种境地的呢？首先，他们严格来说不是一个软件团队：他们是一个大量处理数据、需要编写代码（主要是 R 语言）的团队，但并不是一个严格意义上的软件团队。重要的是，这也意味着他们没有机构层面的支持（即使有也很少），这种支持本可以让他们学会如何正确使用已有的基础设施，或者获得更合适的工具。Git 是一个相对简单的工具，但它有很多非直观的地方，这使得要跨越最初持续使用它所需的激活能变得非常困难：你需要一个远程仓库，需要让人们通过身份验证访问它，还需要向人们展示如何推送和拉取代码，以及如何不费太多力气地进行提交。这对我们来说已经是第二天性了，但在没有人刻意鼓励的情况下，学习起来难度不小：我从意识到需要开始使用版本控制，到真正熟练使用这些工具，花了几年时间。如果没有人提供必要的推动力，这件事非常难以实现，这样的结果也是意料之中的：人们半吊子地使用版本控制，却没有真正认真对待。 我在几个不同地方遇到的类似失败模式是，很多人一谈到 Git，就会自动想到 GitHub/GitLab。我确实在一家自称是软件初创公司（尽管他们的商业模式与软件关系不大）里见过这种情况：那里的模式是人们把东西上传到 GitHub，进行提交，做所有那些时髦的事情，但全部通过 GitHub 的界面完成，有时甚至到了通过手动上传文件来“推送”的程度。本地工具基本用不上。这通常是因为很多现代 PaaS 工具（Netlify、Vercel，对我们这些老家伙来说还有 Heroku）主要通过接收仓库来工作，而很多现代框架（Flask、Django、Next.js 之类的）允许你即使对版本控制一窍不通，也能很快搭建出一个能用的应用（我很庆幸自己不了解 Supabase/Fly.io 的情况，也不知道 LLM 工具如何加速了这一过程，但我猜情况不妙）。这意味着有很多人“构建了一个应用”，想知道如何部署它，却不知道任何相关工具。他们阅读指南，看到需要将代码放到 GitHub 仓库里，于是注册 GitHub 并创建项目，看到“上传文件”按钮，就以为事情就是这样运作的。 这显然是一种异常糟糕的情况：大多数人还是会以一种相对合理的方式进行提交。无论如何，单点登录、IT 人员和一些非正式指导，最终能让公司至少拥有一个可以正常使用的远程仓库。即便如此，很多人还是没能很好地掌握，比如如何处理合并冲突，当冲突出现时就会惊慌。同样，分支或变基也可能让人困惑，人们为了想办法让东西跑起来，经常会做一些非常奇怪的事情。通常我还会抱怨提交信息，但老实说，我主要做个人项目，提交信息通常都很简短，有些地方不尽如人意，所以那样抱怨可能有点虚伪。无论如何，你明白我的意思：很多科技行业的人，尤其是在非软件核心领域但仍大量编写代码的领域工作的人，确实很难正确使用 Git。 这就引出了一个问题：为什么？鉴于 Git 在如此多的现代技术实践中占据核心地位，为什么大多数编写软件的人和团队还不能熟练使用他们工作的核心工具呢？ ## 命令行之殇 一个首要的解释与命令行有关。Git 首先是一个命令行工具，虽然也可以为其编写可视化界面，但这些界面通常效果不佳，因为该工具的逻辑期待在 shell 中使用。即使在 VSCodium（我认为它有最好的图形工具之一）这样的应用中，我发现任何比简单提交更复杂的操作，我还是得用命令行（我倾向于用图形工具或 Lazygit 做简单提交，因为能直观看到正在提交的内容很方便，而且记得在提交前检查哪些文件被追踪了哪些没有，这有点麻烦）。在特定提交或标签处创建新分支、创建分支或尝试进行变基，这些操作你都不会想用可视界面来尝试。这就是说，如果你不能很好地仅通过命令行来理解 Git 的工作原理，那么在使用 GUI 版本时，你几乎一定会发现自己在处理除了最基本任务之外的任何事情时遇到真正的麻烦。 而相当多实际存在的软件专业人士，却对命令行完全不知所措。尽管我的读者可能不愿相信或不愿去想，但大多数软件开发工作仍然发生在 Windows 机器上，虽然这种情况比以前少了，但开发者实际上无法访问命令行的现象仍不罕见：所有事情都通过某个定制的 IDE “运行”按钮、Excel 电子表格或类似东西完成。正如威廉·吉布森曾说的：“未来已来，只是分布不均。” 大量的人仍在使用的工具、文化和流程的复杂程度，是软件前沿领域十多年前就已经超越的水平。 这自然导致很多使用 Git 的人既缺乏理解 Git GUI 所必需的知识，也缺乏轻松学习其原理的能力（他们必须通过命令行使用 Git 直到融会贯通）。这意味着，即使是单人开发者在个人项目上可能使用的最基本的工作-暂存-提交-推送工作流（没有分支之类，就在 main 上提交，满意后就推送到远程仓库），也变得很痛苦：在标准的企业工作流中，你可能需要切换到另一个不同的软件，等待它更新你的更改，找到提交按钮，等待另一个弹窗出现，写下提交信息，提交，然后切换回你的 IDE 继续工作。这一切都非常不直观（当代码相关的事情发生在 IDE 中时，为什么还要切换到一个完全不同的工具来做这些事？），这使得人们很容易敷衍了事，或者尽力避免做这件事。一个好的 IDE 至少可以通过避免上下文切换来缓解这个问题，但正如我们之前所说，我们谈论的很多软件公司*不会投资好的 IDE，也不会允许他们的员工安装一个好的免费 IDE*。 在现代软件世界里，即使对命令行一无所知，你也能走得很远：这自然导致很多科技行业的人不会费心去学习如何使用命令行，或者除了最基本任务之外不在 shell 中做任何事情。在这种情况下，你自然会看到人们在使用 Git 时挣扎：无论你是坚持使用 Git 的命令行版本，还是最终回到 GUI，你都必须拥有相当多的 CLI 版使用经验，才能真正领会其中奥妙。如果我们能鼓励命令行素养的大幅提升，这可能会对改善现状大有帮助，但当然，人们也不会觉得有必要学习如何使用 CLI。这意味着我们需要解决更深层的问题，那就是…… 成为第一个知道新文章发布的人！也请订阅新闻通讯，获取关于我思考的独家更新（和一些轻度营销）。 获取新文章发送到您的收件箱 → 同时给我发送每月新闻通讯 ## 人们看不到 Git 解决的那类问题 当你教别人一项新技能或新知识时，有两个原则至关重要。首先，你必须从对工具的具体理解逐步构建到抽象理解：除非你绝对*知道*某人已经有了可以直接应用于当前情况的抽象概念（这样你就可以在此基础上进行），否则你必须从一个具体案例开始，逐步构建到抽象概念。其次，所教技能或知识的前几步必须对人们*立即*产生明显的作用。在更开明的时代，这甚至适用于数学（人们经常抱怨它没用或不相关）：在一个货币化的社会里，学会加减乘除对于*找零*或*做预算*之类的事情非常重要，所以，尽管学习过程不愉快，但即时需求是存在的。同样地，我通过十几岁时玩万智牌和战锤40K，概率计算能力得到了很大提升：当时有即时需求去做概率计算，所以我学会了。 Git 和其他版本控制的问题在于，随着时间的推移，编写软件的工作中，能够让人发展出理解抽象概念所需的具体理解，或者能够让人明显看到这项技能对自己有直接用途的工作比例，正在稳步下降。这一切始于对软件生命周期整体缺乏理解。 根据痛苦的经验，我认识到，用一个尚未发布到某处且未被使用的项目来教别人版本控制的重要性是非常困难的。毕竟，版本控制的主要价值不只是能够恢复丢失的工作或查看以前的代码版本，而是能够*快速且以自动化的方式*做到这一切。这也是命令行问题的一部分：Git 的很大一部分价值在于你可以将其集成到自己编写的 shell 脚本中来自动化工作，而通过 UI 使用它则失去了很多使用它的乐趣。即使是像 shell 自动补全或滚动 shell 历史找到之前运行的命令并编辑它这样的功能，也算是一种脚本和自动化，我猜很多读者一想到不得不没有这些功能就已经开始皱眉了：这就是通过 GUI 使用 Git 的人不得不经常面对的情况。但回到最初的观点，如果你从未遇到过*必须非常快速地回滚到旧版本代码*的情况，你可能永远不会理解人们为什么费心使用版本控制。这意味着，首先，在教育环境中很难学到版本控制为什么重要：你几乎从不需要从一个代码版本回滚到之前的可用版本，因为作业通常很小，即使丢失了之前版本也能很快重新创建，而且第一个能用的代码版本通常就是你交上去的版本。这也意味着你不太可能作为初级开发者在现有代码库上学到这些技能：你可能会了解到，例如，克隆并在某个分支上提交是你交付工作和保住饭碗的方式，但就实际功能而言呢？考虑到交给初级人员的任务类型，你编写的代码有很大可能几乎永远不会被执行，或者即使崩溃了也无所谓，甚至如果有点重要，高级人员可能也会在某个时候介入，在问题进入 main 之前将其修复。作为一名现有项目上的初级人员，你几乎没有机会犯一个足以……