Why is Git so popular and frequently used?

Without needing to worry about setting up a web frontend, I can quickly and easily have as many free and lightweight repos as I want, on any server I own, with support for ssh certificate authentication. And if the server goes down, Git is offline-first, so I can keep working in my local repos until I can fix the server or relocate the repos.

Assuming that Git is bad because you saw some bad stories on Hacker News is like concluding that prehistoric people all lived in caves just because that's where the evidence was preserved. Most people who use Git aren't complaining about it, they're just quietly using it.

How many other SCM tools have you used? In my experience git gets a fair deal of hate, but everyone switched over to it because 1) the alternatives are worse and 2) github revolutionized the way that we write and share software.

Before git, the most popular SCM tool was SVN, which required you to talk to a central server for everything you do (single point of failure, slower, no offline). I've used mercurial before too, and its approach to branching is pretty painful.

I've heard of some enterprise companies needing to use git alternatives for very specific needs or scalability issues, but outside of that IMO the only meaningful downside to git is that there's a learning curve to using it. But it's not much of one - once you understand the mental model and what the basic commands are doing, you can get by just fine. The average person doesn't need to know about git rerere or octopus merging.

(also, commits are effectively immutable for public projects, which sucks for trans engineers who change their name)

1. Network effects

2. Timing

The world was ready for a replacement for SVN just at the moment when git hit the scene, and it was just good enough to take over. Mercurial dates to the same era and was just about as good (arguably better), and could easily have won out instead, but tiny difference in initial adoption snowballed, and so git won and mercurial lost (as did Bazaar, Fossil, etc.)

And while git is hardly perfect, a git killer needs to not just be 15% better, but hugely better; a big enough gap to trigger another industry wide shift. "It's like git, but we made the UI 15% nicer" seems like a good sales pitch, but it's not going to motivate people into becoming evangelists for their teams to adopt it, and that's what you need. (Git, for all its flaws, was enough better than SVN that people absolutely fought to change over.)

1. Git was WAY better than SVN and CVS and was also a lot better than most of the commercial options of the time. The open source license and fact it worked on just about any text file made it pretty easy to adopt.

2. Author was Linus Torvalds and git was immediately used and proven (in 2005) to manage the Linux kernel. For a lot of open source developers, experience working with kernel stuff had you thinking, hey this git thing is pretty nice...

3. When Github showed up, it quickly replaced the old SVN and CVS driven software "forges" that were used by a lot of the open source world.

So what about the undo thing? Git has always got a lot of flack for it's command line inconsistency. Honestly, it's no better/no worse than most developer tools (try your compiler's command line options). You have to learn to use it, and like other dev tools, learning it usually involves on the job pain, exactly when you don't want it (demo in 15 minutes).

1. It's free.

2. You don't need an IT support ticket to set up a new repository.

3. It's distributed and supports collaborative development in a way that "classical" version control (CVS, SVN, and similar models) does not.

4. You don't need a chain of approval signatures to create a new branch.

5. It's free.

I've never worked with anyone who publicly said they disliked git. Those who didn't understand it always preferred to use a GUI, such as Source Tree, Github, or VS Code.

Personally, whenever git was unable to do something I needed it to, I have always been able to add a git alias to my `.gitconfig` that became a new part of my workflow, essentially extending the CLI. I've found it to be easy to work with, and the amount of great tooling I've found built on top of it is amazing.

I've never used a version control system other than git though. So I am heavily biased. Before I was introduced to git, I didn't use version control at all, and so maybe it's a case of the grass is always greener. But I came from a place without any grass at all.

It is by no means perfect but is vastly better than the alternatives.

With prior version control systems I always had the fear I could get into some situation i could not fix. With fit I have no fear of mistakes because I can revise commit messages, rebase, etc.

Git has some cryptic commands but you can write the important ones on a 5 x 7 card and get back to coding.

I think people chafe at the bit because git is so easy to use that even non-coders use it (really is ‘track changes’ in Office that easy to use? How much do you trust it?

It’s very success means that it challenges people who might not have used a version control system before.

The thing I really like of Git is the simplicity and transparency of its structure: a Git repository is a DAG of commits, each of which is a tree of blobs and directories, all of them linked by their hashes. On top of that there are tags and branches, which are labels for some of these hashes. That's all, essentially. This makes it very easy to understand what's happening in my repositories. It makes it easy to address data: if two repositories have the same commit hash, they have exactly the same history, nothing else to check.

To me understanding the data structure is more important that understanding how that data is to be manipulated. Manipulation follows from the structure, not the other way around for me. So it's true that git's interface can be a bit confusing, but if you know what you want to get, eventually you find out how to do it. Much worse would be to understand if you did the right thing with a repository whose internal structure is opaque to you.

Also, manipulation tools can be fixed, enhanced, redesigned, developed, and git's user interface has definitely progressed since its beginning. Data at rest is more difficult to fix if you laid it out wrong (as the transition away from SHA1 proves: that's one thing that was not engineered well enough at the beginning and it has a price now). So having a solid data layout is more important that having an easy interface.

These are the reasons for my love at first sight with git.

Frankly, because of GitHub

Late 2000s/Early 2010s there was greater variety in version control tooling. Distributed VCS was new. Mercurial promised to be the “easy” version. Subversion was still heavily used and maintained.

GitHub quickly established itself as THE place to share and collaborate code. To use it you had to learn git.

Most people, still, to this day have a fairly shallow understanding of git and find themselves encountering lots of foot guns, lack of opinions, and UI inconsistencies. I’m not sure without GitHub, git would be as dominant.

Paraphrasing, "Git is the worst distributed version control system... except all the others".

With an exception made of Mercury - that according to people (I never used it) was in points better than Git -, git swept the floor with the competition, with a "little" help from Github.

The reality is that today you can't really separate git from Github.

Regarding your link, and to answer your question, my position is that Git is like the PHP of version control.

The barrier to entry is so, so low, that not enough people care about learning it right / properly /enough (Myself included)

(The difference being that I can goople myself out of a problem pretty much every time). Also, I do make a pretty basic use of git, and it's been years since I screwed up. Worst case scenario I need to fix a merge conflict with code from one of my colleagues (That I hate to fix, because it doesn't happen often enough as for myself to remember how to interpret the diffs)

Anecdotally, I was the person responsible for the adoption of Git in my company, some 13 years ago. We were really struggling back then to get SVN working for distributed version control.

We never looked back.

The reason it's so popular and frequently used is... Because it's popular and frequently used. It's the ultimate in network effects.

That being said, git is a very solid system, it's just not polished very well. You could take the "plumbing" parts, throw out the "porcelain", and build an equally capable but far more usable system atop it.... Which almost nobody would use.

It's simple logic, really:

1. distributed version control systems (dvcs) are a lot more complex than people think they are. (This is anecdotal/personal, but a _lot_ of blogs and complaints I read about git primarily boil down to complaints that are intrinsic to dvcs. It's not possible to do any better unless you either drop support for important features or come up with a novel and creative solution that somehow makes things easier to understand without losing any power. I'm not sure such an 'easier but just as powerful' model exists). In other words, lots of these complaints sound like 'the pizzas at this restaurant are crap' but the actual problem is that the complainer simply fundamentally dislikes round things, and they've misplaced most of the blame. Not something a restaurant can fix without reimagining pizzas.

2. The really easy to understand systems (such as cvs / svn) are too simple and can't do many important things, so those aren't suitable replacements.

3. Because dvcs is hard and git is the de-facto standard, in order to 'shop around' and use something else (or, build something better), you'd first need to fully understand all the particular principles of dvcs.

4. If you don't bother to learn all that or aren't capable, then you won't do a good job on finding another dvcs or building one yourself. You can't rely on outside advice - you won't be able to follow the reasoning, and you can't rely on appeal to popularity (as git is the popular choice).

5. If you DO bother to learn all that, you'll understand git so there isn't actually any reason. There is very little you'd want to do with a dvcs that git cannot do. Git's shortcomings can be solved by writing tutorials, front-ends to it, and setting up a model ('we develop features like this, we sign off on commits like this, this is how we name our tags, etc'). Not by writing something else.

When Git was taking over from SVN, the main benefit I remember reading about was the much faster/lighter-weight branching. IIRC in SVN making a branch makes a complete copy of all the files. Since then it's benefited from being the standard everyone (kinda) knows despite its sharp edges.

Because git is actually very very good at what it does for the most common cases of source control. Aside from scaling edge cases it works phenomenally well and gets almost everything right. The big flaw is just the inscrutability and learning curve of the porcelain commands, however any attempt to fix that has to either nerf git's power, or else transform the complexity to another equally complex if less arbitrary set of commands and switches. I don't think such a system can ever gain traction because it only helps beginners, for the majority of seasoned developers it just amounts to new syntax to the same stuff.

My theory:

1. Git was used for Linux. People developing Linux also developed packages for apt. They used it to host the source since they already used it for Linux.

2. GitHub showed the file tree @ master as the main thing when viewing a repo. "where are my files" is the first thing I think when using legacy Got web uis

3. It's free

4. It's just good enough that you don't encounter problems every day. Because of this many people have never encountered a problem. Because people are mean they insult people who do encounter problems. This encourages people to not speak up.

5. Other VCSs were way slower.

Whats the quote?

"There are two types of version control systems: the ones people complain about and the ones no one uses."

Originally, I think it was because it's made by Linus. People trust him and the people who make the Linux kernel so it was a natural fit.

Since then though, it's mostly network effects.

>if this is the state

I find git quite easy to use with egit. I've been using git for more than 10 years. There are two types of people I see struggle with git.

People moving from CVS/SVN to git would have a hard time because the terminology is the same, but means something conceptually different. A git commit is not the same as a commit in SVN.

The other group is people who don't understand version control very well with any system. This group existed before git and will always exist. I believe for these people, git undo or whatever other "easy mode" will simply muddy the water further for them. If you don't know the difference between a revert and a reset, you need to learn it, not try to paper over it with yet another command. undo will simply add to their confusion as they don't understand any of the nuance with git.

In the late 00's, SVN was the dominant version control system, but it had lots of pain points (eg reliant on remote server, lots of crappy little .svn directories, branching was difficult, very difficult to make a git repo for small projects etc) that Git resolved. At this time, hg and bzr were also on the scene, but Github quickly became incredible popular, for a few reasons - Sourceforce, the incumbent community home for open source, was a comparatively inferior user experience - Rails, which was a dominant OSS project in that era, was hosted there, and the Rails / Ruby community converged on GH as a result - Heroku was a trendy platform during this time, which at the time you deployed by `git push`-ing, so git knowledge was required to take advantage of it.

I'd be fine with Git if it wasn't for every single GUI for it being a steaming pile of crap.

I use CLI for committing/pushing/branching etc... But anyone who pretends that CLI is adequate for inspecting history and changes or operations such as cherrypicks is a macho pretender.

* 2005 Linus invents git to get around licensing issues with bitkeeper.

* 2005 Git into use shortly in the Linux kernel

* late 2000s, SourceForge kinda got bad - trying to do too many things badly in complex interfaces

* 2008 github comes around - it's simple and obvious (shiny, new), open source projects start to move over - exponential growth due to network effects

* 2009 github gets big. That era of the web was all bootstrap themes with sites just implementing features as fast as possible, lots of fast growth

* 2010 github has 1M repos

* 2010 microsoft TFS goes git based

Understanding what git replaced is a key for this. For me the main thing git did right in that period that made me want to change from the various SCMs I used at the time (CVS/SVN/SourceSafe/Perforce/TFS) was that source control becomes a part of development, done locally. There's only one machine (yours) that breaks when you break a merge / integration / rebase etc. The server is not really part of the "I'm done with my change, now share my change with others" loop that is part of every team based development project. This reduced that time significantly (things which often took hours or even days now took seconds).

TL;DR - Workflow improvements, Linux, OSS network effects, Github's simple UI, world domination

I really dislike your burried link, not mentioning what you are arguing about.

> if this is the state (hn link)

this is an enormous load of salt to throw while doing nothing to clarify or make clear where umbrage might be taken. poor form of "question asking" & does a disservice to possible conversations, by not making a case, just being nasty. you should at least try to communicate a case for your distaste, so as not to present as so easily disregarding & dismissing without real interest. you seem unwilling from the start to be accepting.

Before I started programming I mainly got my open source source code from SVN. Back at the day all the emulators were hosted on SVN + google code (I think?), I didn't even know git existed.

I felt the shift to git in projects I use happen only after github launched and became popular and with the "fall" of google code, all the projects just naturally moved to github + git

so main points

1.git works (not that other SCM don't)

2.github is huge and very easy to use

3.the decentralized way of git seems more "natural" to me (subjective, obviously)

Everything in Git is addressed based on the hash of data, this automatically makes things content addressable. Git doesn't take more room if you rename a file, the contents are still at the same hash. It treats the whole repository as an object, instead of tracking each individual file.

Not every command is as user friendly as it should be, but it is far, far better than having a stack of floppy disks with .ZIP files on them, which is what I used to do in the 1990s as a solo developer.

Don't believe the hype, there is really not much you could do to improve upon Git. There is a good reason why Git is not a VSCode plugin or a GUI program like inexperienced devs often expect it to be. It's an example of a program that uses unix philosophy. There is nothing stopping you from using Git through a GUI or a simplified text interface if you want, but that functionality is out of the scope of Git.

Because of GitHub.

But it also makes people feel smart. People like to feel smart, like they're using the "expert" tools.

Back then I used Mercurial, Bazaar NG, and Bitkeeper before Git. Coming to Git I was astounded that people who had used Bitkeeper (Linux devs) had created Git. Because Bitkeeper had a fairly elegant and consistent command line UI. Git does not.

Before Github, many OSS are hosted at Sourceforge. but IIRC, you need Sourceforge's approve to open a new project. Unlike Github, which you can open a public repository by yourself.

Then Ruby (and ruby gems?) is hosted at Github, as Ruby/RoR gets more attention, Github and Git become popular too.

We used mercurial but few tools integrated with it out of the box. It was easier to move to git that get mercurial to work with our tools

Historically, it was more or less the first OSS distributed version control system - before that, people used Subversion, and it was much nastier to merge branches, etc.

People are right to call it not exactly user friendly, you can call "winning" despite this handicap a side effect of network effects - there's nothing that's been better enough than git that also that millions of users will organically switch to it

Network effect, perhaps

Git doesn't have any restrictive licensing. Anyone can install and use it for free, no questions asked.

there's a whole history/check the timeline of how it rose

here's a thread where some of it is being discussed: https://news.ycombinator.com/item?id=27579701

/s

Because mercurial lost.

CVS was hell.

It's overly complex, uses esoteric and inconsistent commands, and is generally unusable by mere mortals -- presenting a significant barrier to entry for the wrong types of people.

In this way it is a bit like capitalism.