I mean one of the beauty parts of git has always been that you can and, under ideal best practices, should have more than one place to put your code with the distributed nature of it
But also, and more relevantly here, git is designed to be usable entirely offline. And if you do need to have some connection with remotes, git allows you to do so extremely sporadically if your network connectivity, or remote availability, is limited.
I dunno about "should", that feels like overkill. Expecting to get something like a 99.99% SLA shouldn't be unreasonable to expect out of a hosted solution
Comments
I mean one of the beauty parts of git has always been that you can and, under ideal best practices, should have more than one place to put your code with the distributed nature of it
But also, and more relevantly here, git is designed to be usable entirely offline. And if you do need to have some connection with remotes, git allows you to do so extremely sporadically if your network connectivity, or remote availability, is limited.
I dunno about "should", that feels like overkill. Expecting to get something like a 99.99% SLA shouldn't be unreasonable to expect out of a hosted solution
A seperate git remote isn't incredibly unreasonable either - Even if it's just something on localhost in case of scenarios like this one
Github being down for a bit shouldn't disrupt your work flow
GitHub being down blocks all of our CI pipelines, for example.
you should be able to run the basic tests locally.
The value add for Github is mostly the issue/PR interface and actions.
But currently that's not the beauty part of GitHub, it's the actions, discoverability and other features not part of Git.