GitHub宕机自救指南

核心心态：GitHub 是一个远程服务，不是唯一的真理源

首先必须明确：你的代码和协作历史应该始终在本地和多个远程点有备份。Git 是分布式版本控制系统，天生就具备抗单点故障的能力。GitHub 只是大家约定俗成的一个"中心点"，但它不应该是唯一的一个。

第一篇章：日常预防 - 打造金刚不坏的开发流程（宕机前）

预防远胜于治疗。通过配置以下习惯和工具，你可以几乎无视 GitHub 宕机。

1. 多远程仓库配置 (Multiple Remotes)

这是最核心、最有效的方法。为你本地仓库添加多个远程推送地址。

添加另一个远程仓库 ：

假设你除了 GitHub (origin)，还使用了 GitLab 或 Gitee。

bash

复制代码

# 添加一个名为 gitlab 的远程仓库
git remote add gitlab https://gitlab.com/your_username/your_repo.git

# 或者添加一个名为 gitee 的远程仓库
git remote add gitee https://gitee.com/your_username/your_repo.git

一次性推送到所有远程仓库：

bash

复制代码

# 方法一：手动逐个推送
git push origin main
git push gitlab main
# 方法二：使用 bash 命令一次性推送（Linux/macOS/WSL）
git remote | xargs -I {} git push {} main
# 方法三：设置推送模式（不推荐新手）
git remote set-url --add --push origin https://github.com/your_username/your_repo.git
git remote set-url --add --push origin https://gitlab.com/your_username/your_repo.git
# 之后 git push 就会同时推送到两个仓库

推荐组合 ：GitHub + GitLab（海外）/ Gitee（国内）。平时主要用 GitHub，但每次 push 都习惯性地推送到两个地方。

2. 使用 Git 钩子 (Git Hook) 自动同步

你可以创建一个 post-push 钩子（虽然没有直接的这个，可以用 post-commit 或其他组合），但更简单的是在 IDE 或 Shell 配置中设置别名（alias），让一条命令完成所有推送。

3. 定期备份关键数据

GitHub 不仅仅是代码仓库，还包括：

Issues / Pull Requests : 使用官方工具 GitHub Backup 可以定期将 issues、PRs、wiki 等数据备份到本地。
GitHub Actions : 关键的工作流脚本本身就在你的仓库目录下的 .github/workflows/ 中，它们已经被 Git 管理。
Packages: 如果你使用了 GitHub Packages，应考虑定期下载重要版本到本地或同步到其他仓库服务（如 JFrog、Nexus）。

4. 团队沟通预案

和团队约定好：

"如果 GitHub 宕机，我们将立即把远程协作中心临时切换到 [GitLab/Gitee] 的镜像仓库，并在 [Slack/钉钉/Teams] 群中通知。"

第二篇章：宕机发生时 - 如何继续工作（宕机中）

当宕机真的发生时，不要慌，按照以下步骤操作。

1. 确认问题

首先访问 GitHub Status 官方状态页，确认是否是全球性宕机，而不是你的本地网络问题。

2. 继续本地开发

对于个人开发者：

继续 Coding : 你本地的 Git 完全可以正常工作。继续你的功能开发，正常进行 git add 和 git commit。
暂缓推送 : 只是暂时无法 push 到 origin (GitHub)。你的提交历史都会完好地保存在本地。

3. 团队协作应急方案

如果团队正在紧急协作，需要共享代码：

切换远程中心：
1. 团队负责人或任何有权限的人，将事先准备好的 GitLab/Gitee 镜像仓库设为临时中央仓库。
2. 在所有人群里通知新的仓库地址。

更新本地远程仓库地址：

bash

复制代码

# 方法一：直接修改 origin 的 URL（临时措施）
git remote set-url origin https://gitlab.com/your_team/your_repo.git

# 方法二（推荐）：使用新的 remote 名称，避免混淆
git remote add emergency https://gitlab.com/your_team/your_repo.git

从新的远程仓库拉取和推送：

bash

复制代码

# 如果使用了方法一
git pull origin main
git push origin main

# 如果使用了方法二
git pull emergency main
git push emergency main

通过其他方式传输补丁 （极端情况）：

如果连备选仓库都来不及搭建，可以通过其他工具分享补丁：

bash

复制代码

# 生成一个补丁文件
git format-patch origin/main..HEAD --stdout > emergency_fix.patch

# 将 emergency_fix.patch 文件通过 Slack/钉钉/微信发送给同事
# 同事应用这个补丁
git apply emergency_fix.patch

第三篇章：宕机恢复后 - 善后与同步（宕机后）

当 GitHub 恢复，你需要把宕机期间的工作同步回来。

1. 将工作同步回 GitHub

如果你的应急方案是使用了另一个 remote（如 gitlab）：

bash

复制代码

# 确保切回 main 分支
git checkout main

# 从应急仓库拉取最新的代码，确保本地是最全的
git pull gitlab main

# 推回 GitHub
git push origin main

如果你的应急方案是直接修改了 origin 的地址：

bash

复制代码

# 先把本地代码推送到 GitHub（此时 origin 还是 GitLab 的地址）
git push origin main

# 再把 origin 的地址改回 GitHub
git remote set-url origin https://github.com/your_username/your_repo.git

# 之后推送就恢复正常了
git push origin main

2. 同步其他数据

Issues/PRs: 如果在备用平台创建了新的 Issue 或 PR，需要手动将评论和状态同步回 GitHub。
Wiki: 类似操作。

3. 复盘与优化

和团队一起复盘这次事件：

应急方案是否顺畅？
沟通是否及时？
是否可以引入更自动化的工具（如 CI/CD 自动同步镜像）来避免下次手动操作？

高级技巧：使用 CI/CD 自动同步镜像

对于重要项目，可以配置 GitHub Actions（或 GitLab CI/CD），在每次推送时自动同步到另一个平台。

示例：GitHub Actions 同步到 Gitee

在 Gitee 导入 GitHub 项目，并配置 WebHook 或定时同步。

或者，使用 GitHub Action 实现自动 push：

yaml

复制代码

# .github/workflows/sync-to-gitee.yml
name: Sync to Gitee
on: [push]
jobs:
  sync:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Mirror to Gitee
        run: |
          git remote add gitee https://${ACCESS_TOKEN}@gitee.com/your_username/your_repo.git
          git push gitee main

（注意：需要在 GitHub 仓库的 Secrets 中设置 ACCESS_TOKEN，这是你的 Gitee 私人令牌）

总结： checklist

阶段	行动项	是否完成
预防	1. 为关键项目添加 GitLab/Gitee 作为第二远程	☐
	2. 养成 `git push all main`（推送到所有远程）的习惯	☐
	3. 团队沟通并确认应急方案和沟通渠道	☐
	4. 定期备份 Issues/Wiki 等元数据	☐
宕机中	1. 访问 status.github.com 确认问题	☐
	2. 继续本地提交	☐
	3. 如需协作，切换远程中心并通知团队	☐
恢复后	1. 将代码同步回 GitHub	☐
	2. 同步其他协作数据（Issues等）	☐
	3. 复盘优化流程	☐