Why don't people use git properly? | deadSimpleTechGet new articles delivered to your inbox →

Enter your email

Enter your email

Get Updates →

Also send me the monthly newsletter

Why don't people use git properly?<br>Author: Iris Meredith<br>Date published: 2026-07-03<br>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.<br>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.<br>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.<br>(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.)<br>The nature of the problem<br>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.<br>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.<br>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.<br>A similar failure mode that I've encountered in a couple of different places is that a lot of...