I think this article conflates GitHub and Git a few times, though the author definitely knows better.
For better or for worse, I don't think Git is going anywhere. A lot of the recent developments in source control amount to providing a better user experience for git repos.
We might well see companies move away from GitHub as source of truth in favor of alternate forges with better SLAs or self-hosting, but dethroning git itself at this point feels very unlikely.
That being said, Git has two big weaknesses: non-text files and handling massive repositories. This is why you see continued use of centralized version control systems (e.g. Perforce, ClearCase) at organizations that need these things. Git LFS tries to address large non-text files, but in my experience teams tend to prefer VCS systems that handle this natively.
At a few big tech companies that decided to use huge monorepos 20 years ago, they've since hand-rolled custom non-git version control systems tailored to their unique scale. These systems usually work by combining a centralized version control server (similar to SVN or Perforce) with a virtual file system that selectively populates code paths based on the current checkout.
But the vast majority of orgs don't need massive monorepos or large amounts of non-text files checked into their repo.
Comments
I think this article conflates GitHub and Git a few times, though the author definitely knows better.
For better or for worse, I don't think Git is going anywhere. A lot of the recent developments in source control amount to providing a better user experience for git repos.
We might well see companies move away from GitHub as source of truth in favor of alternate forges with better SLAs or self-hosting, but dethroning git itself at this point feels very unlikely.
That being said, Git has two big weaknesses: non-text files and handling massive repositories. This is why you see continued use of centralized version control systems (e.g. Perforce, ClearCase) at organizations that need these things. Git LFS tries to address large non-text files, but in my experience teams tend to prefer VCS systems that handle this natively.
At a few big tech companies that decided to use huge monorepos 20 years ago, they've since hand-rolled custom non-git version control systems tailored to their unique scale. These systems usually work by combining a centralized version control server (similar to SVN or Perforce) with a virtual file system that selectively populates code paths based on the current checkout.
But the vast majority of orgs don't need massive monorepos or large amounts of non-text files checked into their repo.