I'm sure it works both ways. If Github was somethingelseHub, somethingelse would be popular. Git started gaining popularity thanks to great UI and communities on github and gitlab.
That's not strictly true. I'm sure thst GitHub contributed to the awareness of git among and less technically experienced especially in recent years, but use of version control systems has always been the norm in mid to large codebases and git became popular because it improved greatly on the version control systems that came before it.
Another big factor contributing to it's popikaroty was that the Linux kernel (that even when git came out was a pretty big codebase already) also used it to great success.
The only real credit that can be given to GitHub in my eyes is that it allows individuals to more easily host remote repos.
Git didn't need GitHub to become popular. Torvald's name being attached to it is what did that. But GitHub is what gave Git the near monopoly on open source version control that it enjoys today. Once it became more convenient to contribute to open source projects by forking projects on GitHub than to self-host, that created a barrier against using any other version control system. Other version control systems would be much more popular if it weren't for GitHub.
GitHub made it easier than ever for people to share and collaborate on code. The options that predated it were pretty awful by comparison. It's no wonder that within a couple of years most OSS projects had moved over.
GitHub launched in Feb 2008, Git soared and SVN plummeted.
> In a previous blog post, we discussed how GitHub was using a new mode of git repack to implement our repository maintenance jobs. In Git 2.32, many of those patches were released in the open-source Git project
It looks like GH needed a better algo for git repack. Implemented a better algo for git repack. And contributed the better algo for git repack to the open source project. You can now use the better algo for git repack yourself without using GH.
