--- title: "Why don't people use git properly?" url: https://daily.dev/posts/why-don-t-people-use-git-properly--nlptbzd7i source_url: https://deadsimpletech.com/blog/why-dont-people-use-git-properly type: article source: "Lobsters" published: 2026-07-04T20:39:37.999Z updated: 2026-08-07T21:25:49.579Z tags: ["git", "cli", "version-control"] reading_time: 27 upvotes: 0 comments: 0 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Why don't people use git properly? **[Lobsters](https://daily.dev/sources/lobsters)** · 27 min read · 0 upvotes · 0 comments ## Summary Many developers use git poorly or not at all, and this essay explores why. The core issues are: git is primarily a CLI tool and many developers lack command-line fluency; most people never experience situations where version control's value becomes viscerally obvious (rolling back a broken production deploy, for example); and without that felt need, learning the tool feels risky rather than safe. The author uses an analogy of armoured vs. unarmoured soldiers — git gives developers the confidence to take risks and experiment, but only once they've internalized that safety net. Solutions proposed include introducing git from the very first coding lesson, requiring repository submissions for assessments, rotating new hires through DevOps, and encouraging small independent tool projects that create real deployment and rollback scenarios. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 2 discussions and 81 comments across lobsters, hackernews (as of 2026-08-07). **TL;DR:** The community largely agrees that git is genuinely hard to use, but debates whether the root cause is poor mental models, a bad CLI design, or simply that better alternatives (like Jujutsu) already exist and the real question is why we're still defending git at all. **Sentiment:** 10% positive · 30% mixed · 60% skeptical **The case for** - Once developers internalize a correct mental model of git's data model, most day-to-day confusion dissolves. - Atomic, single-purpose commits and a clean history genuinely improve code quality and make history useful for future debugging. - Tools like Magit and Jujutsu demonstrate that a better UX layer on top of git's backend can make even experts significantly more productive. **The pushback** - Git's CLI was never designed top-down with users in mind — its porcelain commands are ad-hoc shortcuts to internal data-model operations, not high-level task abstractions. - Commands like `checkout` and `reset` overlap in confusing ways, and the sheer number of inconsistently named commands causes most developers to memorize a tiny safe subset and never explore further. - The staging area adds a third state (working copy / index / committed) that provides no power over a simple two-commit stack and actively confuses newcomers. - Git's lack of a basic undo primitive discourages experimentation and learning, as evidenced by the existence of sites like ohshitgit.com. - The Windows shell experience remains a real barrier: even WSL2 has stability and integration rough edges that push Windows developers away from CLI workflows entirely. **By community** - lobsters (skeptical): A rich, technical debate concludes that git's UX problems are deep and structural — rooted in its data-model-first design — and that Jujutsu represents a meaningfully better path forward backed by real user research. - hackernews (mixed): Brief but pointed: commenters agree git is non-intuitive and overcomplicated, with several noting they've already moved to Jujutsu and barely miss git's concepts like the staging area. **Hottest debate:** Whether git's core problem is that users lack the right mental model, or that the mental model itself is a poor abstraction that shouldn't be required of users in the first place. **Open questions** - Would making non-published history immutable by default (as some propose) actually help beginners, or create worse outcomes at scale? - Is there a realistic path to git improving its own UX, or is the answer simply to adopt a better frontend like Jujutsu universally? - Does the Windows developer experience remain a fundamental blocker for CLI-based git adoption, and what setup genuinely 'just works' there? **Highlights** > > 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. I'd like to propose an alternative solution, that's more realistic than improving the quality of education in the whole world: make git easier to use. > — [m\_eiman on lobsters · 65 points, 3 comments](https://lobste.rs/s/4e3g9a/why_don_t_people_use_git_properly#c_l0xwjs) > > My unscientific theory is that git's (lack of) ease of use isn't actually the main problem. […] I've found that what people miss is a mental model for what git sets out to do. That… is the exact same thing. Git’s a pain to use *because* it requires you to understand its exact internal model and implementation details, it’s the only VCS I’ve used where you can not become proficient or intuit the system by learning top-down. And to be clear I’ve done that legwork, I’ve internalised the model, I’ve parsed packs and indexes, I’ve written ad-hoc rebases on top of plumbing commands, and I’ve learned stuff, some if it was even useful. But at the end of the day I just wanted a VCS and I’m not going to pretend my colleagues should have to understand the implementation details of a storage engine when git’s original designers had no care or taste in UI. > — [masklinn on lobsters · 9 points, 3 comments](https://lobste.rs/s/4e3g9a/why_don_t_people_use_git_properly#c_xtxbcw) > There was a lot of user research that went into many of the workflows around which jj is built. * Martin worked on the source control team at Google for many years before starting to build Jujutsu. A lot of jj's feature set comes from Martin's experience deploying fig/hg at Google and seeing all the pain points developers faced. Linus had no such large-scale experience -- it was very much a vision in a dream for him. * I was on the source control team at Facebook, where we regularly did user interviews across the entire spectrum of experience levels. jj borrows extensively from much of that, while also adding a couple of ideas we hadn't foreseen and which make the overall experience 10x better. > — [sunshowers on lobsters · 10 points, 1 comments](https://lobste.rs/s/4e3g9a/why_don_t_people_use_git_properly#c_jhrh7a) > You simply don't have to ask "why don't people use Jujutsu properly?" There were no user studies or interviews that went into the original Git porcelain UX, nor was there much engagement with the existing space. Tools which come out of one person's autodidactic vision tend to be very uneven — they tend to have great parts, and also parts that make newbie mistakes. The staging area is one such mistake. (Jujutsu shows that it provides no additional power over using a stack of two commits.) > — [sunshowers on lobsters · 4 points, 2 comments](https://lobste.rs/s/4e3g9a/why_don_t_people_use_git_properly#c_4yr1fc) > In 2012, I joined a company that was using Git, while I was previously on Subversion. In 2013, a guy joined who had worked with OpenStack and Gerrit- we quickly adopted what I felt was a highly productive culture, including making an effort of having a clean change history, with single-purpose commits. I felt the change history was great- in that gig we had to refer to the history quite often, and I think it was pretty worthwhile. Also, in my opinion, thinking in atomic changes, made us better engineers- it makes you think more about what you're doing. I quit that company in 2019 and... I still work in that way, but personally, it's never been a priority for me to nudge my colleagues into improving. I've worked with others who knew how to make changes "well", but... I've corrected some flagarant problems, but really, it just hasn't felt like a priority. I rarely need a good change history nowadays, and the organizations I work for have problems several orders of magnitude more concerning. PRs and squash merge are horrible, but they are low effort and reasonably effective. And also, sometimes it's just about working in smaller chunks and not obsessing if occasionally you spit out big chunks that could be smaller. We still reminisce about how productive and nice Gerrit felt, but I think there are bigger fish to fry first... > — [koala on lobsters · 17 points, 1 comments](https://lobste.rs/s/4e3g9a/why_don_t_people_use_git_properly#c_hubcz8) **Source threads** - [lobsters](https://lobste.rs/s/4e3g9a/why_don_t_people_use_git_properly) · 31 points · 69 comments - [hackernews](https://news.ycombinator.com/item?id=48787122) · 25 points · 12 comments --- Tags: [#git](https://daily.dev/tags/git), [#cli](https://daily.dev/tags/cli), [#version-control](https://daily.dev/tags/version-control) [View this post on daily.dev](https://daily.dev/posts/why-don-t-people-use-git-properly--nlptbzd7i)