Hacker News Reader

Comment by AndrewDucker | Hacker News Reader

The advantage of a distributed version control system is, of course, that you can keep working even if GitHub is down.

And everyone has a copy of the code, so even if GitHub never came back up you'd be able to keep on working, once you'd agreed a new central server to use for syncing purposes.

View on HN

In my experience it isn't the syncing of the commits that causes trouble. It is all the integrations you layer on top that cause trouble. You've got build systems that trigger whenever a branch is merged. Code review systems and ticketing systems do stuff whenever a commit shows up. When those stop working, all the commits in the world don't matter much because you can't get your code out to the next environment or the next step of your development workflow.

In short, Git allows you to make commits in isolation. Thats great if the only work you have can be done in isolation. But in my experience, eventually you'll need to kick off a build, make a deployment, start a code review, or something... and then you are hosed.

While these problems are valid and a shortcoming of distributed version control in general, I believe this is a good illustration of how we should not be using Git in the future. Git can be used as a deployment mechanism for sure, but it's not a very good one when comparing to other means of publishing and deployment, such as Docker and Kubernetes.

In my opinion, Git is best used as a system of record for changes to a codebase, and while deployment _can_ be triggered from events happening on Git (or a centralized repository such as GitHub), that should definitely not be the only way to deploy something. You should always be able to deploy manually.

GitHub isn't git.

Code reviews, pull requests, actions (CI), are all value that GitHub adds over git.

Just because the VCS stays up doesn't mean github going down doesn't impact work.

The company I used to work at used GitHub just for git hosting. Code reviews, pull requests, CI, were all handled by other tools. There are probably a lot of others in that situation.

No one does this. There is a huge infrastructure overhead of doing what you are proposing. If I were to guess, not even 1% of the companies are separating git & its contextual data (CI, PRs, code reviews, etc).

I'm not proposing this. The last place I worked for did this. There are plenty of third-party tools that do these things with good GitHub integrations.

If they are integrated to GitHub instead of git, they are probably down as well when GitHub is down.

The integrations were mostly there to notify the tools about updates and ensure they have the latest versions of every branch. You need this for things like triggering builds on branch updates, but not for things like uploading a diff to code review.

Reply on news.ycombinator.com