Why don’t people use git properly?

为什么人们无法正确使用 Git？

Author: Iris Meredith
Date published: 2026-07-03
作者： Iris Meredith
发布日期： 2026-07-03

The educational project that I’ve been blathering on about for a while has a name now, and has a landing page! Meet Arca. Early access will hopefully be dropping next week: in the interim, I’m still giving away individual slots for a donation to the writing projects.
我唠叨了很久的那个教育项目现在终于有了名字，也有了落地页！向大家介绍 Arca。希望下周能开放早期访问：在此期间，我依然会为捐赠写作项目的读者提供个人名额。

Git is a tool that’s deeply important in shaping the world of software. Initially developed to serve the needs of developers working on the Linux kernel, it’s become the single most popular version control system for software out there, and one that, for better or worse, almost everyone uses. Github is a massive part of Microsoft’s current operations, and that is, more or less, just a public remote for git repositories. Most PaaS systems rely on git repositories as the fundamental artifact that they’re in the business of deploying, and most CI/CD systems expect, as a first point of reference, a git repository.
Git 是塑造软件世界的重要工具。它最初是为了满足 Linux 内核开发者的需求而开发的，如今已成为全球最流行的软件版本控制系统，无论好坏，几乎每个人都在使用它。GitHub 是微软当前业务的重要组成部分，而它本质上就是一个 Git 仓库的公共远程端。大多数 PaaS 系统都依赖 Git 仓库作为其部署的核心产物，而大多数 CI/CD 系统也将 Git 仓库作为首要参考对象。

Which makes it concerning that an awful lot of people in the tech world, and an even larger proportion of the people writing code in any context simply cannot use git at all well. They panic at a merge conflict. They produce 12,000 line commits with Claude Code and a terrible commit message. They don’t know how to branch. They fail to protect main in their remote repository, and then someone else who also doesn’t know git well pushes to it and accidentally wipes a production database. In extreme cases, they make “commits” by manually uploading files, or they don’t use version control because it’s new and suspect technology. People really struggle, in one way or another, to use this technology properly. Understanding why this happens would probably be useful, and that’s what this essay is about.
令人担忧的是，科技界有相当多的人，甚至在各种环境下编写代码的人中，有更大比例的人根本无法熟练使用 Git。他们遇到合并冲突就会惊慌失措；他们用 Claude Code 生成 12,000 行的代码提交，并附带糟糕的提交信息；他们不知道如何创建分支；他们无法保护远程仓库的 main 分支，导致其他同样不懂 Git 的人推送代码时意外删除了生产数据库。在极端情况下，他们通过手动上传文件来“提交”，或者因为觉得版本控制是新鲜且可疑的技术而拒绝使用。人们在以各种方式挣扎着正确使用这项技术。理解其中的原因或许很有意义，这正是本文要探讨的主题。

(A note: I’ve mostly written here about the perspective of an individual developer, which means I haven’t written much about branching, pull requests or any of the tooling that you really want in a large team. This is partially because I’ve not had an enormous amount of experience in it, and partially because I don’t think it’s directly necessary in order to make my thesis here stick.)
（注：本文主要从个人开发者的角度出发，因此我没有过多讨论大型团队中真正需要的分支管理、合并请求（Pull Requests）或相关工具。这部分是因为我在这方面的经验有限，也因为我认为这些内容对于支撑本文的论点并非直接必要。）

The nature of the problem

问题的本质

Luckily for us, very few people who write software for a living these days don’t have any version control in place at all (though it still happens more often than I think any of us are comfortable with). In companies built around writing software as their core function, it’s more or less unheard of. This doesn’t, however, exclude a whole variety of failure modes when using the tools, and in general, people use git very, very badly.
幸运的是，如今以编写软件为生的人中，几乎没有人完全不使用版本控制（尽管这种情况发生的频率仍比我们预想的要高）。在以软件开发为核心业务的公司里，这种情况几乎闻所未闻。然而，这并不排除在使用这些工具时会出现各种各样的失败模式，总的来说，人们使用 Git 的方式非常、非常糟糕。

I think the worst failure mode I’ve ever seen is one team that maintained a “git repository” for a collection of analysis scripts that was simply a directory on a shared drive. It was technically speaking initiated as a git repository, but practically speaking it wasn’t used as one: rather, the directory contained zipped copies of the code timestamped with when they were modified. There were very few commits to be seen, and I honestly hesitated to try and branch from them in any meaningful way. Of course there was no command line interface or anything to be had, and the git GUI software they had available was muddled enough that it confused me. In this situation, yes, technically they were using git, but in any real sense this clearly wasn’t the case.
我认为我见过最糟糕的失败模式是，有一个团队维护着一个所谓的“Git 仓库”来存放分析脚本，而它实际上只是共享驱动器上的一个目录。从技术上讲，它确实被初始化为一个 Git 仓库，但实际上并没有被当作仓库使用：该目录里存放的是带有修改时间戳的压缩代码副本。几乎看不到任何提交记录，我甚至不敢尝试从中创建任何有意义的分支。当然，那里没有任何命令行界面，他们使用的 Git 图形化界面软件也混乱得让我困惑。在这种情况下，是的，从技术上讲他们确实在使用 Git，但在现实意义上，这显然并非如此。

How did the team get into this situation? Well, first of all, they weren’t a software team as such: they were a team that worked heavily with data and had to write code (mostly in R), but that weren’t strictly speaking a software team. Importantly, this also meant that they didn’t have the institutional support (paltry as that would have been) that might have seen them learn how to use the infrastructure they had properly, or get something more appropriate. Git is a relatively simple tool, but it’s non-obvious in ways which make it very difficult to just get over the initial activation energy needed to start using it consistently: you need to have a remote repository, you need to get people authenticated to it and you need to show people how to push and pull code from it and make commits without too much difficulty. Second nature for us at this point, but it’s non-trivially difficult to learn when nobody is deliberately encouraging you: it took me a few years between registering that I needed to be using source control to be a serious engineer and actually developing real fluency with the tools. If nobody provides the push needed to make that happen, it’s very difficult to actually do it, and this kind of outcome is expected: people kinda-sorta using version control without actually being serious about it.
这个团队是如何陷入这种境地的呢？首先，他们本身并不是一个软件团队：他们是一个大量处理数据并需要编写代码（主要是 R 语言）的团队，但严格来说并非软件团队。重要的是，这意味着他们缺乏必要的机构支持（哪怕是很微薄的支持），无法让他们学会如何正确使用现有的基础设施，或获得更合适的工具。Git 是一个相对简单的工具，但它在某些方面并不直观，这使得克服开始持续使用它所需的初始“活化能”变得非常困难：你需要有一个远程仓库，需要让人们通过身份验证，还需要向他们展示如何推送和拉取代码，以及如何轻松地进行提交。对于现在的我们来说，这已是第二天性，但如果没有人刻意引导，学习过程是非常困难的：从我意识到要成为一名合格的工程师必须使用版本控制，到真正熟练掌握这些工具，我花了好几年时间。如果没有人提供必要的推动力，这确实很难做到，因此出现这种结果也是意料之中的：人们只是“凑合着”使用版本控制，而并没有真正认真对待它。

A similar failure mode that I’ve encountered in a couple of different places is that a lot of people, when we talk about git, will automatically think Github/Gitlab. I’ve actually seen this happen in a company that purported to be a software startup (though their business model didn’t really have much to do with the software): the pattern there is that people upload stuff to Github and make commits and do all the fashionable things there, but they do it all through the Github interface, sometimes even to the extent of “pushing” by manually uploading files. The local tool doesn’t really see use. This usually seems to come about because a lot of modern PaaS tools (Netlify, Vercel, Heroku for those of us who are old) work primarily by ingesting a repository, and a lot of modern frameworks (Flask, Django, Next.js, that kind of thing) allow you to get an app that kinda works built pretty quickly even if you don’t know shit about version control (I’m blessedly ignorant of the Supabase/Fly.io situation and how LLM tooling has accelerated this, but I assume it’s bad). This means that there are a lot of people out there who’ve “built an app” and want to know ho…
我在其他几个地方也遇到过类似的失败模式：很多人一提到 Git，就会自动联想到 GitHub/GitLab。我曾亲眼见过一家自称是软件初创公司的企业（尽管他们的商业模式与软件本身关系不大）出现这种情况：他们的模式是人们将东西上传到 GitHub，进行提交，并做所有时髦的操作，但他们完全是通过 GitHub 的网页界面来完成的，有时甚至通过手动上传文件来“推送”。本地工具根本没有得到使用。这通常是因为许多现代 PaaS 工具（如 Netlify、Vercel，以及对我们这些老派开发者来说的 Heroku）主要通过接入仓库来工作，而许多现代框架（如 Flask、Django、Next.js 等）让你即使对版本控制一窍不通，也能很快构建出一个勉强能用的应用（我很庆幸自己对 Supabase/Fly.io 的情况以及 LLM 工具如何加速这一过程知之甚少，但我猜情况很糟糕）。这意味着外面有很多人已经“构建了一个应用”，并想知道如何……