Monday morning, the client wanted a progress demo, but GitHub wouldn’t load
At 9:30 last Monday, I was demoing a new feature to a client in a Hangzhou café. The page kept spinning. Email and chat worked fine, but the code repository wouldn’t connect. My first reaction was panic: the code wasn’t lost—every person on the team was stuck outside the same door. Later, I realized hosted platforms sometimes get congested or go down for maintenance. We can prepare an escape route in advance instead of scrambling when it happens.
What GitHub is, and how developers use it
Think of GitHub as an online folder for project code and version history. Developers put each change there so they can review earlier versions and work with other people. In March 2021, the Linux kernel project repository briefly experienced access issues. The discussion drew hundreds of developer comments, with many reminding teams to prepare mirrors and offline backups.
My approach is simpler: I keep a local copy of every important project, then sync it regularly to another cloud provider. It doesn’t eliminate outages, but it lets us keep working when GitHub is temporarily unavailable.
Replicating it today: zero to a few dozen yuan, with the first layer ready in 30 minutes
Cost: Existing free allowances can cover this at 0 yuan. Budget another 0–30 yuan per month if you need extra cloud storage. Time: About 30–60 minutes. Technical barrier: You need to know how to log in to a website, download files, and upload compressed archives. Even without coding experience, you can create a full-project backup first.
First step: Open the code-hosting site you already use, click “New repository” in the upper-right corner, and create a backup repository only you can access. If the code contains confidential client information, check the contract and platform permissions first—don’t upload it directly.
Choose the right level of protection for where you are now
If I’m just starting and the code only exists on my laptop, I’d do two things first: copy the project to a portable hard drive and upload a compressed archive once a week. There’s no need to build a complex process immediately.
If I already have one or two clients, I’d keep a local copy and add an off-site backup. Before each delivery, I’d store the runnable version alongside the documentation.
If I’m scaling up, I’d put automated syncing, permission checks, and recovery drills on the checklist, then test restoring from the backup once each quarter.
Not everyone needs this setup. If I already have a reliable cloud mirror and a company-level disaster recovery plan, I wouldn’t duplicate the work. And if I haven’t tried it yet, that’s okay too—the first layer of insurance can wait until the next time a repository won’t load.