Why don't people use git properly?

# Why don't people use git properly? | deadSimpleTech Source: [https://deadsimpletech.com/blog/why-dont-people-use-git-properly](https://deadsimpletech.com/blog/why-dont-people-use-git-properly) *The educational project that I've been blathering on about for a while has a name now, and has a landing page\! Meet[Arca](https://deadsimpletech.com/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\.* 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\. 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\. \(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\.\) ## 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](https://softwareengineering.stackexchange.com/questions/112270/is-it-unusual-for-a-small-company-15-developers-not-to-use-managed-source-vers)\)\. 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\. 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\. 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\. 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 how to deploy it, but who don't know any of the tooling to know how to do that\. They read a guide, see that they need their code in a Github repository, sign up for Github and make a project, see the "upload files" button and assume that that's how things are meant to work\. This is, obviously, an unusually bad situation: for the most part people are actually committing work in a manner that makes some kind of sense\. One way or another, SSO, the IT staff and some informal mentoring get people over the line to the point where a company at least has a remote repository that they're able to work with OK\. Even then, though, people often don't have a good grasp of, for instance, how to handle a merge conflict and panic when one comes up\. Similarly, branching or rebasing can be confusing and people can often do some very strange things while trying to make something work\. This is usually the point at which I'd complain about commit messages too, but honestly, I mostly work on personal projects so they're usually quite short and leave something to be desired, so that might be a little hypocritical\. In any case, you see the point: a lot of people working in tech, especially in spaces that aren't core to the software space but that still write a lot of software, really struggle to use git properly\. Which raises the question: why? Given how central git is to so much of modern tech practice, why are we in a situation where the bulk of people and teams writing software cannot use a core tool of their work? ## Command line blues A first\-order explanation has to do with the command line\. Git is, first and foremost, a command line tool, and while it's possible to write visual interfaces for it, they usually don't work all that well because the logic of the tool expects that it's used in a shell\. Even in applications like VSCodium \(which I think has one of the better graphical tools out there\), I still find myself doing anything more complex than a simple commit using the command line \(I tend to do simple commits using the graphical tool or with Lazygit because it's convenient to be able to see what's being committed, and remembering to check what is and isn't being tracked before committing is a bit of a pain\)\. Creating a new branch at a given commit or tag, branching at all or trying to run a rebase are all things that you really wouldn't want to try using the visual interfaces to do\. What this is to say, then, is that if you don't have a good grasp of how git works using the command line alone, you're almost certainly going to find yourself having real trouble when it comes to doing anything but the most basic tasks using the GUI version\. A startling number of actually existing software professionals, by contrast, are completely at sea when it comes to command lines\. As much as my readers probably don't want to think about this or might not believe it, the bulk of software development work still happens on Windows machines, and while it's less common than it was, it's still not unusual for developers to not really have access to a command line at all: everything happens via some bespoke IDE "run" button, an Excel spreadsheet or something like that\. As William Gibson once put it, "The future is here, it's just unevenly distributed", and an awful lot of people are still working with a level of tooling, cultural and process sophistication that the leading edge of software moved past a decade or more ago\. The natural consequence of this is that a lot of people who use git have neither the knowledge that they need to make sense of what the git GUI is doing, nor the ability to easily learn what's going on \(which they'd have to do by using git through the command line until it sticks\)\. This means that even the most basic kind of work\-stage\-commit\-push workflow that a solo developer might use when working on a personal project \(no branching or anything, just commit on main and push to your remote when you're happy with your work\) becomes a real pain: in the case of the standard corporate workflow, you might have to switch to a different piece of software entirely, wait for it to update with your changes, find the commit button, wait for another form to pop up, write your commit message, commit and then switch back to your IDE and continue with what you were doing\. This is all deeply non\-intuitive \(why switch to an entirely different tool to do all of this when code stuff happens in the IDE?\), and that makes it easy to do it in a desultory manner or try your best to avoid doing it at all\. A good IDE will mitigate the issue a bit by at least avoiding the content switch, but as we've established earlier, a lot of the software shops that we're talking about*don't invest in good IDES and won't let their employees install a good free one*\. You can get surprisingly far in the world of modern software without knowing anything about the command line: the natural consequence of this is that a lot of people working in tech won't bother to learn how to use it or to do anything in the shell beyond the most basic tasks\. In such a situation, you're naturally going to see people struggling with git: whether you stick to using the command line version of git or whether you eventually return to using a GUI, you have to have quite a bit of experience with the CLI version to really grok what's going on with it\. If we were to encourage a massive increase in CLI literacy, this would probably do a fair bit to improve matters, but of course people don't feel the need to learn how to use a CLI either\. Which means that we need to address the deeper problem, which is that\.\.\. Be the first to know when a new article drops\! Sign up to the newsletter too for exclusive updates on my thinking \(and some light marketing\)\. Get new articles delivered to your inbox → Also send me the monthly newsletter ## People don't see the kinds of problem that git solves When you're teaching someone a new skill or new material, two principles are of vital importance\. Firstly, you have to build from a concrete understanding of the tool to an abstract one: unless you absolutely*know*that someone already has an abstraction that's directly applicable to the current situation on hand \(in which case you can work from that\), you have to start with a specific case and build up to the abstract one\. Secondly, the first steps of the skill or material being taught have to be*immediately*useful to people in an obvious way\. In a less benighted time, this even applied to things like mathematics \(which people constantly complained about as being useless or irrelevant\): learning to add or multiply, subtract or divide, in a monetised society, is very important for things like*making change*or*budgeting*and so, as much as the work is unpleasant, the immediate need is there\. Similarly, I got much better at probability calculations by the simple expedient of playing Magic the Gathering and Warhammer 40k as a teenager: the immediate need to do the probability maths was there, and so I learned\. The issue with git and other version control is that as time has gone on, a steadily smaller fraction of software writing work allows for the development of the concrete understanding that leads to the abstractions being understood, or, for that matter, it being obvious that the skill is immediately useful to you\. It begins with a lack of understanding of the software lifecycle as a whole\. From bitter experience, I have learned that it is very difficult to teach someone the importance of version control using a project which hasn't been released somewhere and that isn't being used\. The chief value of version control, after all, isn't so much being able to recover lost work or look at previous versions of the code so much as it is being able to do all of that*fast and in an automated manner*\. This is part of where the command line thing comes in: a large part of the value of git is that you can integrate it into shell scripts that you've written yourself and that automate stuff, and using it through the UI thus loses a lot of what makes it fun to use\. Even something like shell autocompletion or being able to scroll through your shell history to find a command you ran earlier and edit it counts as a form of scripting and automation, and I suspect that a good number of my readers are already wincing at the thought of having to do without that: that is what people using git through a GUI have to deal with regularly\. But to return to the original point, if you're never in a situation where you*have to be able to roll back to an older version of code really fucking fast*, you might never understand why people bother with version control at all\. This means, for a start, that it's quite hard to learn why version control is important in educational settings: you almost never have the need to roll back from one version of code to an earlier working one, because assignments are usually small enough to recreate quickly if you've lost an earlier version, and the first working version of the code is usually the version that you hand in\. It also means that you're unlikely to be able to learn the skills as a junior working on an established codebase: you might learn that, for instance, cloning and committing on a certain branch are how you deliver work and keep your job, but in terms of actual function? With the kinds of tasks given to juniors, there's a good chance that the code you've written will almost never actually be executed, or that it won't matter if it crashes, or if it's even a little important a senior will probably step in at some point and fix the issue before it ends up on main\. There are very few ways in which you, as a junior on an established project can make a mistake that makes you go "oh shit: hard`reset`, hard`reset`\!"\. Even if you do, it's likely going to be the DevOps team doing that work these days, which means that you won't learn an important lesson about why we do version control at all\. Enough situations like that and it's easy to figure that version control isn't really important, or at least that it doesn't solve a problem that you really want to solve\. The only way that I've found for communicating that is to make people use git to work on something that they personally care about \(usually a personal website\) using git from the get go\. That's actually a thing in itself that a lot of people who use version control have never done: they've never had to create a new git repository and hook it up to a remote, much less think about adding files, tracking them or any of the other family of things that you do early on in a project\. Understanding that part of things helps in itself, but to my mind the most useful thing about this kind of learning is that it*actually creates situations where you might want to roll back a change*: design changes are the kind of thing that it's easy to become dissatisfied with, websites tend to break in interesting and hard\-to\-ignore ways, and if you're working with a website that's about you, you'll want to fix breakages fast\. Even if a breakage doesn't actually happen, people understand the value of the tool a lot faster\. Similarly, understanding the role that git has in deploying and distributing code is also of considerable importance\. In 2026 one of the main problems that version control solves doesn't actually have anything to do with versioning or maintaining versions at all: rather, we use git and other version control tools for integration, deployment and distributing our code\. These are arguably even more important than the versioning features in many cases: the versioning for a website is*nice*and I'd never want to go without it, but you can keep track of versions locally\. Being able to deploy changes to my website with one command \(or well, three: Gitlab CI/CD only triggers deploys for me on version tags, which means that I have to push the progress and then the tag\), though, is*massive*, to the extent that even if git didn't do version tracking at all, being able to push to a remote repository and then trigger some automations would probably make it invaluable on its own, and that's something that you just*can't*do without something like git \(I suppose you could write a script to overwrite a directory on a server with a local one through an SSH tunnel or something, but that seems shoddy and a little terrifying without version control in place\)\. The people whom I've talked about who manually upload files to Github so that they can be deployed have made significant progress towards understanding why the tool might actually be useful even if they annoy me, but the fact is that the majority of people who do programming these days have never actually deployed anything for themselves in their lives\. They've not thrown up a website or had to maintain a personal tool: all their work goes into the work repo for God\-knows\-what to happen to it\. In that situation, where people haven't ever really touched operations, DevOps or really ever had to deploy code at all, it becomes very easy to not feel like you have to use git, or even to*want*to learn how to use it\. These elements all work together: deploying something helps you understand both why deploying or distributing code is a lot easier with git than without it*and*teaches you quite quickly why you'd want to roll something back quite fast\. Working on a project that you're intending to deploy impresses the importance of having a remote repository and committing frequent small changes \(and over a long enough period, writing commit messages that are at least*informative*, if not the perfectly comprehensive ones that we'd ideally want\)\. A lot of people, however, simply don't have that experience and are unlikely to get it: a lot of corporate developers only write code at work and as we've discussed, have never deployed or distributed anything or been in a situation where they need to roll back changes fast\. ## Spending protection Bret Devereaux has written a fair bit on his[blog](https://acoup.blog/)\(and in an upcoming book, I believe: Bret, if you read this you should send me a reviewer copy\. It will do you absolutely*zero*good, but I reckon reviewing it on this blog would be fun\) about the Roman edge in military operations\. An important part of his conclusion is that a significant part of the advantage comes down to the fact that the Roman infantryman was significantly more heavily armoured than peer adversaries in the relevant period \(mostly Carthage and the Hellenistic Kingdoms, if I recall my history correctly\)\. A large part of the effect this has is obviously simply to reduce the risk of injury or death in battle, and that's no small thing on a strategic or operational scale, but there is another effect that's relevant here: a more heavily armoured soldier will tend to spend some of his increased protection by fighting more aggressively\. If you're wearing only a*linothorax*or are unarmoured entirely \(this comes up a lot when discussing Gallic infantry\), you'll tend to fight quite conservatively, covering yourself with your shield and putting as much distance between yourself and your enemy as possible\. If, by contrast, you're wearing*lorica hamata*\(mail armour\), you might be willing to move much closer into measure, strike at the enemy even if that means there's a chance of trading hits and otherwise be willing to wound or strike the enemy in a way than an unarmoured or lightly armoured fighter wouldn't be willing to attempt\. This is, to my mind, one of the greatest advantages of git \(and, by\-the\-by, also automated testing\): the added security that being able to restore to an earlier state whenever you need to allows you to take more risks and try more things when building software\. If you have no version control, or at best a bunch of folders, if you try something and fuck it up you have to throw away all of your work and start from quite a way back\. Version control, with frequent small commits, allows you to take more risks in your work, which is, in general, a good thing: you can be more ambitious, try riskier things and be safe in the knowledge that you can never permanently fuck things up, leading to better code in the long run as you learn skills faster and potentially even learn entirely new patterns that make things drastically better\. What I've seen is that a lot of software developers working without version control tools develop defensive habits to avoid doing the kind of damage that can derail an entire project\. They tend to be overly conservative, reuse a lot of previously used code that they*know*works and be extremely wary of trying anything new\. In the extreme case, this can lead to situations where people[copy the same application across multiple workplaces and coerce it into shape](https://ludic.mataroa.blog/blog/flexible-schemas-are-the-mindkiller/)\. In general they can be very unwilling to try new patterns, libraries, languages, technologies or anything new\. And without having a good grasp of version control, that makes quite a bit of sense\! Git allows you to move much faster and take more risks, but unless you've actually experienced working on a properly version\-controlled project yourself, you won't know that\. You need to have that feeling of*safety*, of "OK, if I mess this up I can just roll back" for it to really change your behaviour \(by\-the\-by, if you're an LLM proponent reading this and wondering why people at your workplace aren't adopting LLM tools, this could be why\. I don't like LLMs myself, but if you think they're good and want people to use them, but the people whom you're targeting haven't internalised the basic security that git brings, they will never adopt the tools\)\. The issue here is that for a lot of us that security is kind of second\-nature: we use git, we know that it*works*\. For someone without that security, though, using git*properly*\(small commits, frequent commits, do it locally and for the love of all things holy*don't*just do one big commit before you push\) could well actually feel like a risk\. It is, after all, a new and somewhat weird tool, and their experience of new and weird tools has mostly been "this fucked up my work and I had to redo all of it"\. You're essentially asking them to run into battle naked and telling them to use a new weapon that they think might hurt them as much as the enemy in the process\. Between all of these points, I think we have a fairly strong explanation both for why so many people struggle to use git effectively, and for why the problem can be so intractable\. In short, there's really no reason perceptible to a lot of people for them to learn to use the tools properly, and if they do try, learning to use the tool can feel actively risky and dangerous\. Obviously this isn't a good place to be, and so we now turn to how one might overcome this and get people to use git effectively\. ## Improving matters There's been a fair amount of talk about the fact that git is fairly user\-unfriendly and has a steep learning curve, and there is a certain amount of truth to this: Mira Welner's excellent[Can we communally deprecate git checkout?](https://mirawelner.com/posts/checkout.html)is an excellent example of the kinds of problems the software has\. This has led to a number of people suggesting that we should move away from git as industry standard and start using something else: Mercurial is one of the ones that comes up the most often\. Now, I'll admit I've not tried using Mercurial before \(perhaps I should\), but I don't think that switching tools is going to fix our problems: some improvements in usability might be helpful, but in a lot of ways git is the shape it is for very good reasons, and we wouldn't, for example, try and dumb down a milling machine or a lathe because they're hard to use\. We can make our tools more usable and it's a good thing to do that, but we won't eliminate the problem that way\. Telling people to build their own projects and thus learn for themselves is also a bit of a non\-starter\. For starters, a lot of people don't really have the time for that: a lot of the corporate developers that I talk about have lives and families and can't afford to spend hours after work building new projects that would teach them why git is important and how to use it fluently\. Learning new skills without a teacher is also pretty difficult: there are some things in most fields worth a damn where you need a teacher to give you a bit of a push to actually make the effort \(the teacher supplies the activation energy mentioned earlier\), and for a lot of these things, trying to learn without a teacher can teach you bad habits if you say, don't want to put in the effort to pin down something that's actually critical or find a resource that's bad or just wrong\. A motivated person with the right support can make this work, but this isn't a strategy that can easily scale\. Realistically, the only way we improve the general quality of git usage in the developer population is by significantly improving the quality of education in the software world\. This is, notoriously, a major challenge\. Formal education is, however, the easier place to start solving the inability to use git well, so it's the one I'll discuss first\. We can start by introducing version control more\-or\-less as soon as we start teaching coding: "hello, world" is not too early\. At that stage in education, basically everything a person's typing into a computer is some kind of mysterious rune or the other, so adding an extra command or two is easy, and it helps develop the habit early\. This can be consolidated by educators as time goes on: after all, educators have a major power which is important here, which is setting the terms for assessments\. You can demand that all assessments be submitted in the form of a push to a remote repository, which will at least force people to use the basics of git tooling effectively\. It's a poor substitute for real motivation, but for a lot of purposes, it's good enough\. Making git education happen in larger software spaces is more difficult: it requires, after all, that companies dedicate time and resources to education, which is a thing that doesn't happen very often\. I have few solutions for this one \(well, I mean, I have one solution, but it's the one I'm selling and I'm acutely aware that it could only ever be a very small part of the solution\)\. The first thought I have, for anyone who's actually doing DevOps in a sensible way, is to have everyone rotate through DevOps when they first join the company, no matter what their intended job is in the long run\. Exposure to DevOps practice in an at\-all\-busy company is an excellent way to impress the value of being serious about version control and your use of git on people: after all, something fucking out horrifically because someone used the tool badly and you having to fix it tends to fix itself in the brain\. The other thought I have here is that encouraging the building and maintenance of small, independent tools might be a good idea\. This is usually discouraged because it increases maintenance overhead, but against that, teams maintaining small tools \(small enough to be maintained by one or two people\) learn a lot and often get a crash course in how important things like proper use of version control are\. Encouraging this kind of work, within reasonable limits, might be a good way to get people to upskill\. Git is a core working tool for almost all of the software that we use day\-to\-day and even more of the software that sits in the background doing important things that keep society working\. It would perhaps be good, then, if more people had a strong understanding of what the tool does and how it works\. Like my writing? Want to see more of it? Support it here \(and if you donate in the next few days and let me know, you get free access to[Arca](https://deadsimpletech.com/arca)for as long as the product lasts\)\. Support independent writing → [Liberapay](https://liberapay.com/iris_meredith/)[Patreon](https://www.patreon.com/c/IrisMeredithandherblog?redirect=true)[Stripe](https://donate.stripe.com/6oE2a30hh3my2reeUY)