3 ms·

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

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.

spookthesunset 7y ago
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.
- tomphoolery 7y ago
  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.
7777fps 7y ago
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.
- daveFNbuck 7y ago
  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.
  - spectramax 7y ago
    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).
    - daveFNbuck 7y ago
      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.
      - xiphias2 7y ago
        If they are integrated to GitHub instead of git, they are probably down as well when GitHub is down.
        daveFNbuck 7y ago
        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.

spookthesunset 7y ago

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.

tomphoolery 7y ago
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.

7777fps 7y ago

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.

daveFNbuck 7y ago
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.
- spectramax 7y ago
  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).
  - daveFNbuck 7y ago
    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.
    - xiphias2 7y ago
      If they are integrated to GitHub instead of git, they are probably down as well when GitHub is down.
      - daveFNbuck 7y ago
        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.