企业官网建设流程全解析

1. 这不是一份“教程”，而是一份你随时能翻出来查的 GitHub 仓库操作字典

我带过不少刚接触协作开发的新手，也帮某高校实验室的几位导师搭建过课程代码托管体系，还给某公司内部的非技术岗同事做过 Git 基础培训。每次开场问“你们最常卡在哪儿”，答案高度一致：不是不会写代码，而是搞不清“为什么点这个按钮就报错”“为什么别人能推上去我推不上去”“这个分支到底该不该删”。GitHub 仓库本身不难，难的是它把版本控制、协作流程、权限管理、自动化逻辑全揉进一个界面里——而绝大多数入门资料只告诉你“点这里→填这里→按回车”，却从不解释背后那套运行逻辑。

这本《GitHub 仓库完全指南》就是为解决这个问题写的。它不假设你懂 Git 命令行，也不预设你有团队协作经验；它默认你已经注册了账号，但可能连「Settings」里有几级菜单都数不清。全文围绕“一个真实仓库从零创建到长期维护”的完整生命周期展开，覆盖你95%以上的日常操作场景：新建仓库时要不要勾选「Add a README」、.gitignore文件里该写node_modules还是/node_modules/、PR 描述里写“fix bug”和写“修复登录页 token 过期后未跳转至登录页（#23）”带来的协作效率差异、保护分支规则里“Require pull request reviews before merging”和“Include administrators”两个开关同时打开的真实影响……这些细节，文档里不会写，视频教程里一闪而过，但它们恰恰决定你是不是那个总被叫去“帮忙看看为啥 CI 失败了”的人。

关键词全部落在实操动作上：GitHub 仓库创建、远程仓库同步、分支管理、Pull Request 流程、Issues 跟踪、Actions 自动化、仓库权限配置、归档与迁移。没有抽象概念堆砌，每个小节都对应一个你能立刻打开浏览器去验证的具体任务。比如看到「## 3. 分支不是标签，是可移动的指针」这一节，你马上就能切到自己仓库的 Branches 页面，观察 main 和 dev 分支的 commit hash 是否相同、点击「Compare」看差异、手动创建一个临时分支再删掉——所有操作都在你眼皮底下发生，而不是靠想象。

适合谁？三类人最需要：第一类是刚学完 Python 或 JavaScript，正准备把第一个小项目传到网上展示的初学者；第二类是设计师、产品经理、测试工程师等非开发角色，需要在协作中查看代码、提 Issue、审阅 PR；第三类是小型团队的技术负责人，要快速搭起一套不踩坑的协作规范。如果你属于其中任何一类，这篇内容就是为你写的——它不教你成为 Git 大师，但能让你在 GitHub 上每一步操作都心里有底。

2. 仓库设计底层逻辑：为什么 GitHub 的“仓库”不是文件夹，而是一套协作操作系统

2.1 仓库的本质：一个带时间轴的协作快照系统

很多人第一次点开 GitHub，下意识把仓库当成网盘或 FTP 目录：上传文件 → 点击保存 → 完事。这是最大的认知偏差。GitHub 仓库（Repository）本质是一个分布式版本控制系统（Git）的远程镜像节点，它的核心功能不是“存文件”，而是“记录每一次变更的上下文”。你可以把它理解成一台自带录像机的白板：每次提交（commit），系统不仅拍下当前所有文件的样子，还同时录下“谁在什么时候、因为什么理由、改了哪几行、和上一次相比有什么不同”。

举个生活化例子：你和三位同事共同编辑一份产品需求文档。如果用共享网盘，最终你会看到一堆命名混乱的文件：需求v1_final.docx、需求v1_final_张三修改版.docx、需求v1_final_李四确认版_20240315.docx。而用 GitHub 仓库，你们每人每次修改都是一次 commit，系统自动给你生成一条清晰的时间线：

• 2024-03-10 14:22｜王五｜初始化需求文档，添加用户登录模块描述
• 2024-03-11 09:35｜李四｜补充密码强度校验规则（见第7条）
• 2024-03-12 16:48｜张三｜修正登录流程图，更新时序说明（#12）

关键在于，每一次 commit 都绑定了作者、时间戳、描述文字、唯一哈希值（如a1b2c3d），以及它所基于的前一个 commit。这个链条构成了不可篡改的协作证据链。当你在 Issues 里写“这个问题在 commit a1b2c3d 后出现”，所有人立刻知道具体是哪次修改引入的，而不是在几十个文件里大海捞针。

提示：GitHub 界面右上角的「Insights」→「Network」图表，就是这个时间链的可视化呈现。每个圆点代表一个 commit，连线表示父子关系。新手建议花5分钟点开自己的仓库试试，拖动鼠标放大看分支分叉与合并过程——比读十页文档更直观。

2.2 本地仓库 vs 远程仓库：为什么必须理解“两套副本”的存在

几乎所有初学者的困惑根源，都来自混淆了“本地”和“远程”这两个空间。你的电脑硬盘上有一个.git文件夹（隐藏），它存储着完整的项目历史、所有分支快照、你做的每一次修改暂存区；而 GitHub 上那个同名仓库，只是你本地仓库的一个“备份镜像”，两者通过git push和git pull命令保持同步。

这个设计带来三个关键后果：

第一，离线可工作。你在高铁上没信号，依然能创建分支、写代码、提交 commit——所有操作只发生在本地.git文件夹里。等回到办公室连上 Wi-Fi，一条git push就能把这几天的全部变更同步到 GitHub。这和传统网盘“必须联网才能保存”有本质区别。

第二，同步需显式触发。很多人以为“我改完文件保存了，GitHub 就自动更新了”，结果发现网页端还是旧内容。真相是：保存文件只是改了工作区（Working Directory）；执行git add .是把改动放进暂存区（Staging Area）；执行git commit -m "xxx"才真正把这次改动记入本地历史；最后git push才把本地历史推送到远程。漏掉任意一环，GitHub 都看不到变化。

第三，冲突必须人工解决。当 A 和 B 同时修改同一文件的同一行，A 先push，B 后push时会失败。GitHub 不会自动选择谁的版本，而是要求 B 先git pull拉取最新版，手动合并冲突（通常是在代码里看到<<<<<<< HEAD和>>>>>>>标记），再add+commit+push。这不是 Bug，而是协作系统的安全机制——它强制暴露分歧，避免静默覆盖。

注意：新手最容易犯的错误是跳过git add直接commit，或者commit后忘记push。建议在终端里养成固定动作流：改完文件 →git status（看哪些文件已修改）→git add .（暂存所有）→git commit -m "描述"→git push。git status是你的导航仪，5秒就能确认当前状态是否符合预期。

2.3 仓库类型选择：Public、Private、Internal 的权限边界与成本逻辑

新建仓库时，GitHub 弹出的三个选项（Public / Private / Internal）看似简单，实则暗含成本结构与协作规则。很多团队早期用 Public 仓库做内部项目，后期想转 Private 却发现要付费——这并非平台套路，而是由底层架构决定的。

• Public 仓库：完全公开，任何人可git clone、浏览代码、提 Issue、Fork。GitHub 对 Public 仓库永久免费，且不限制协作者数量。但它意味着：你的代码、Issue 讨论、PR 评论、甚至 CI 日志（如果用了 GitHub Actions）全部对世界可见。某公司曾把含数据库连接字符串的配置文件误提交到 Public 仓库，3小时内就被爬虫抓取并公开。

• Private 仓库：仅限明确授权的成员访问。免费账户最多添加 3 个协作者；超出后必须升级为 Team 或 Enterprise 计划（按月付费）。Private 仓库的 CI/CD 分钟数、存储空间、API 调用频次均受套餐限制。关键点在于：Private 不等于绝对安全。只要协作者拥有写权限，他就能git push --force覆盖历史，或删除整个仓库（除非开启分支保护）。

• Internal 仓库（仅限 GitHub Team/Enterprise）：面向组织内所有成员自动开放读权限，无需逐个邀请。适合大型企业将通用工具库、内部 SDK 设为 Internal，让所有工程师默认可依赖，但外部人员无法访问。它的价值在于降低权限管理成本，而非提升安全性。

选择逻辑很简单：
✅ 如果项目要开源、做个人作品集、参与社区项目 → 选 Public；
✅ 如果是公司内部业务系统、含敏感数据、需控制访问范围 → 选 Private，并立即配置分支保护；
❌ 不要用 Public 仓库存放任何生产环境密钥、员工信息、未脱敏日志——GitHub 明确声明“Public 仓库不提供数据保密承诺”。

3. 从零创建到首次推送：手把手拆解仓库初始化全流程

3.1 创建仓库前的必做检查清单（90%的人会跳过的5件事）

别急着点「Create repository」按钮。在 GitHub 网页端新建仓库前，请先完成以下检查——它们决定了后续三个月的协作顺畅度：

1. 确认组织归属：右上角头像旁的下拉菜单，是否选对了目标组织？很多开发者用自己的个人账号创建了本该属于公司组织的仓库，导致权限混乱、计费错位、审计困难。切换组织后，URL 会从github.com/yourname/repo变为github.com/yourorg/repo，这是不可逆的操作。

2. 命名规范预演：仓库名将出现在所有命令行操作中（如git clone https://github.com/yourorg/my-project.git）。避免空格、中文、特殊符号；推荐小写字母+短横线（kebab-case），如user-auth-service而非UserAuthService或user_auth_service。后者在某些 CI 环境中会因路径解析问题失败。

3. README 初始化决策：勾选「Add a README file」看似省事，实则埋雷。如果你计划用 Markdown 写详细文档，勾选没问题；但若只是临时测试，勾选后会自动生成一个空 commit，导致你后续git push时必须处理“non-fast-forward”错误（因为远程已有 commit，而你的本地历史为空）。建议：新项目首次提交留给自己写，不依赖 GitHub 自动生成。

4. .gitignore 模板选择：下拉菜单里的「Python」「Node」等模板，本质是帮你预置常见忽略规则。例如选「Python」会自动加入__pycache__/、*.pyc、.env；选「Node」则包含node_modules/、dist/、.DS_Store。重点来了：这些模板只在仓库创建时生效，之后修改.gitignore文件不会自动删除已追踪的文件。比如你选了「Node」模板，但之前已git add node_modules/并 commit 过，那么.gitignore新增node_modules/也不会让它消失——必须手动执行git rm -r --cached node_modules。

5. 许可证声明：「Add .gitignore」和「Choose a license」是两个独立选项。不选许可证 ≠ 默认保留所有权利。根据 GitHub 的 Terms of Service，未声明许可证的代码，默认禁止他人使用、修改、分发。如果你希望别人能 fork 你的项目学习，至少选 MIT License（最宽松）；如果是公司内部工具，可选「No license」并注明“仅供组织内使用”。

实操心得：我帮某实验室搭建课程代码库时，发现学生频繁因.gitignore生效问题提交了node_modules，导致仓库体积暴涨。后来我们统一在创建仓库后，立即执行三条命令：git clone [url]→cd repo→echo "node_modules/" >> .gitignore→git add .gitignore→git commit -m "init: add node_modules to gitignore"→git push。这成了标准化初始化脚本的第一步。

3.2 本地初始化与首次同步：绕过“fatal: remote origin already exists”的经典陷阱

假设你已在 GitHub 创建好空仓库https://github.com/yourorg/my-project，现在要在本地建立关联。标准流程是：

mkdir my-project && cd my-project git init echo "# My Project" > README.md git add README.md git commit -m "first commit" git branch -M main git remote add origin https://github.com/yourorg/my-project.git git push -u origin main

但实际操作中，第6行git remote add origin ...常报错：fatal: remote origin already exists。原因很现实：你可能之前在这个文件夹里执行过git remote add，或者从其他地方复制了带.git文件夹的代码。此时不能删掉.git重来（会丢失本地 commit 历史），而应改用：

git remote set-url origin https://github.com/yourorg/my-project.git

这条命令会更新已有 remote 的 URL，而非尝试新增。接着再执行git push -u origin main即可。

另一个高频问题：git push报错refusing to merge unrelated histories。这是因为你的本地仓库和远程仓库没有任何共同 commit（GitHub 创建的空仓库自带一个初始 commit，而你的本地git init是全新历史）。解决方案是强制合并：

git pull origin main --allow-unrelated-histories # 解决可能的合并冲突后 git push -u origin main

注意：--allow-unrelated-histories是安全操作，它只是告诉 Git “我知道这两个历史无关，请把它们连起来”，不会丢失任何代码。但请确保你真的理解自己在做什么——如果远程仓库已有重要代码，盲目 pull 可能覆盖本地修改。

3.3 验证同步成功的黄金三步法（比看网页更可靠）

很多人点开 GitHub 网页看到文件列表就以为成功了，其实这只是表面。真正的同步验证必须覆盖三个层面：

1. 远程仓库层：在 GitHub 网页端，点击仓库右上角「Code」→「HTTPS」，复制链接https://github.com/yourorg/my-project.git。然后在本地新目录执行：

   git clone https://github.com/yourorg/my-project.git cd my-project ls -la # 应看到 README.md 和 .git 文件夹

   如果能正常 clone 下来，证明远程仓库可访问、URL 正确、网络无阻断。

2. 提交历史层：在本地原仓库目录，执行：

   git log --oneline --graph --all

   输出应显示类似：

   * 9a1b2c3 (HEAD -> main, origin/main) first commit

   这表示本地main分支和远程origin/main指向同一个 commit，历史完全一致。

3. 文件内容层：在 GitHub 网页端，点击README.md→ 右上角「Edit」→ 修改一行文字 → 「Commit changes」。然后回到本地仓库执行：

   git pull cat README.md # 应看到网页端修改的内容

   这验证了双向同步通道畅通，不是单向“只能推不能拉”。

这三步缺一不可。我见过太多人只做第一步就宣布成功，结果两周后发现 CI 构建失败——因为.github/workflows/ci.yml文件根本没同步过去，而他们一直以为“上次 push 成功了”。

4. 分支管理实战：从 feature 开发到 release 发布的完整生命周期

4.1 分支命名不是小事：为什么dev、staging、prod比branch1、test更专业

GitHub 的分支（Branch）本质上是指向某个 commit 的可移动指针。main分支默认存在，但你可以创建任意多分支，如feature/login-ui、hotfix/db-connection、release/v2.1。命名规则直接反映团队工程成熟度：

• 语义化前缀：用feature/、bugfix/、hotfix/、release/开头，一眼识别分支用途。git checkout -b feature/payment-integration比git checkout -b payment更易追溯。
• 小写字母+短横线：feature/user-profile合法，feature/UserProfile在 Windows 系统可能因大小写不敏感导致冲突。
• 避免空格和特殊字符：feature/new design会被 shell 解析为两个参数，报错error: pathspec 'design' did not match any file(s) known to git。

更重要的是，分支名会直接出现在 Pull Request 标题、CI 构建日志、部署环境标识中。某公司曾用dev作为开发分支，结果 QA 环境部署脚本硬编码了git checkout dev，当某天开发误删dev分支并重建时，所有自动化部署全部中断——因为新dev分支指向的 commit 和旧分支完全不同。

实操技巧：GitHub 支持分支名自动补全。在 PR 创建页面输入feature/，下拉菜单会列出所有以feature/开头的分支，避免拼写错误。建议在团队 Wiki 中固化命名规范，并用 GitHub Actions 的 pre-commit hook 检查 PR 分支名格式（如正则^feature\/[a-z0-9\-]+$）。

4.2 保护分支（Protected Branches）：给main加上三道锁

默认情况下，任何人都能向main分支git push --force或直接 push 删除历史。保护分支功能就是为防止这种灾难。进入仓库 Settings → Branches → 「Add rule」，针对main（或你指定的生产分支）启用以下核心规则：

还有一个隐藏但致命的选项：Restrict who can push to matching branches。如果不开启，任何有写权限的成员都能git push origin :main（冒号表示删除分支）或git push --force覆盖历史。开启后，可精确指定只有@org/admins组能推送。

注意：保护规则生效后，所有违反规则的操作都会被 GitHub 拒绝，并返回清晰错误信息。比如! [remote rejected] main -> main (protected branch hook declined)。这不是网络问题，而是策略拦截——此时应检查 PR 是否满足所有条件，而非反复重试。

4.3 Pull Request 工作流：从代码提交到合并的完整闭环

PR（Pull Request）是 GitHub 协作的灵魂，但它常被简化为“点按钮→写标题→点合并”。一个专业的 PR 应包含五个不可省略的要素：

1. 标题精准：feat: add password strength meter to login form比update login page更有效。前缀feat表示新功能，fix表示修复，chore表示维护任务，这是 Conventional Commits 规范，便于自动生成 CHANGELOG。

2. 描述结构化：用 GitHub 的模板功能（在仓库 Settings → Options → Set up templates）预置 PR 模板。标准字段包括：

   • What changed?（本次修改了什么）
   • Why?（为什么需要这个修改？关联哪个 Issue？）
   • How to test?（如何验证？提供测试步骤或截图）
   • Related issues（关闭的 Issue，如Closes #42，合并后自动关闭）

3. 关联 Issue：在描述中写Closes #42或Resolves #42，合并后 GitHub 会自动关闭对应 Issue，并在 Issue 页面留下合并记录。这比口头说“问题已解决”更可追溯。

4. 审查者明确：在 PR 右侧「Reviewers」栏 @ 相关同事。不要写“请随便看看”，而应指定：“@前端组 @后端组，请分别检查 UI 适配和 API 接口变更”。

5. 状态自检：PR 页面顶部会显示 CI 检查状态（如build: passed、test: failed）。永远不要合并红色（failed）状态的 PR。即使你认为失败是偶发的，也应先点开日志定位原因——可能是你漏提交了.env.example文件，导致测试环境无法启动。

实操心得：某跨平台项目曾因 PR 描述缺失测试步骤，导致 QA 每次都要私聊开发者问“这个功能在哪点？输入什么数据？”，平均耗时15分钟/PR。后来我们强制要求 PR 描述包含 GIF 录屏（用 LICEcap 工具），效率提升70%。记住：PR 描述不是给机器看的，是给下一个要理解你代码的人看的。

5. Issues 与 Projects：把待办事项变成可追踪、可量化的协作资产

5.1 Issues 不是留言板，而是结构化的问题追踪器

很多人把 Issues 当成随手记的便签：“首页加载慢”“按钮颜色不对”。这会导致问题淹没、优先级混乱、无法统计。专业用法是将其视为轻量级工单系统，每条 Issue 必须包含：

• 清晰标题：[Performance] Homepage SSR render time exceeds 2s on mobile (Lighthouse score < 50)
  （标注类型[Performance]、具体现象、量化指标）
• 复现步骤：1. 打开 Chrome 无痕窗口 → 2. 访问 https://example.com → 3. 按 F12 打开 Lighthouse → 4. 运行 Mobile 检测 → 5. 查看 Performance 分数
• 预期结果 vs 实际结果：预期 > 80 分，实际 42 分
• 环境信息：Chrome 122、iOS 17.4、Lighthouse 10.3.0

GitHub 支持在 Issue 中使用 Markdown 表格、代码块、图片，甚至嵌入 YouTube 视频。某硬件团队用 Issue 提交固件 Bug 时，会附上串口日志截图、Wireshark 抓包文件（作为附件）、以及复现用的 Python 脚本——所有信息集中在一个地方，无需邮件来回。

提示：用@mention关联相关人员，用#issue-number关联其他 Issue（如See also #15 for related auth issue），用keyword #number关闭 Issue（如Fixed in commit abc123. Closes #42）。

5.2 Projects（新版）：用看板管理从 Idea 到 Release 的全流程

GitHub Projects 替代了旧版 Projects，它更接近 Jira 的轻量版。一个典型的产品迭代看板包含四列：

关键技巧：Projects 支持自定义字段（如「预计工时」「负责人」「上线日期」），并可导出为 CSV 做进度分析。某创业团队用 Projects 看板跟踪 MVP 开发，每周一晨会直接打开看板，看「In progress」列是否有超期任务（字段设置「截止日期」+「高亮逾期」），比看 Excel 表格高效得多。

注意：Projects 是按仓库或组织维度创建的。如果项目跨多个仓库（如前端web-app+ 后端api-service），应在组织级 Projects 中统一管理，避免信息割裂。

6. GitHub Actions 自动化：用 YAML 文件替代重复的手动操作

6.1 Actions 的本质：事件驱动的流水线编排器

GitHub Actions 不是“高级脚本”，而是基于事件的自动化引擎。它的核心模型是：当某个事件发生（trigger），就在指定环境（runner）上运行一系列步骤（steps）。常见事件包括：

• push：向分支推送代码时触发
• pull_request：创建或更新 PR 时触发
• schedule：按 cron 表达式定时触发（如每天凌晨2点）
• workflow_dispatch：手动点击「Run workflow」触发

一个典型的 CI 流程 YAML 如下：

name: CI Test on: push: branches: [main, develop] pull_request: branches: [main, develop] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 # 拉取代码 - name: Setup Node.js uses: actions/setup-node@v4 with: node-version: '18' - run: npm ci # 安装依赖 - run: npm test # 运行测试

关键点在于：每个job独立运行，拥有干净的虚拟机环境。这意味着你不需要担心“上次测试残留的 node_modules 影响本次结果”，也不用手动清理缓存——Actions 为你保证环境纯净。

实操心得：某团队曾因在npm ci前漏掉actions/checkout，导致测试始终在空目录运行而全部通过。后来我们在所有 workflow 开头强制添加检查步骤：

- name: Verify checkout run: | if [ ! -f "package.json" ]; then echo "ERROR: package.json not found. Checkout failed." exit 1 fi

6.2 Secrets 安全实践：永远不要把密钥写在代码里

Actions 中常需调用第三方服务（如发送 Slack 通知、部署到云服务器），这时需要 API Key 或 SSH 私钥。绝对禁止将密钥明文写在 YAML 文件中（如run: curl -H "Authorization: Bearer xxxxx"），因为所有 workflow 文件都随代码公开。

正确做法是使用 GitHub Secrets：

1. 仓库 Settings → Secrets and variables → Actions → 「New repository secret」
2. 输入 Name（如SLACK_WEBHOOK_URL）和 Value（你的 webhook 地址）
3. 在 workflow 中引用：${{ secrets.SLACK_WEBHOOK_URL }}

Secrets 有严格作用域：仓库级 Secrets 对所有 workflow 可见；组织级 Secrets 可被多个仓库共享，但需显式授权；环境级 Secrets（如 Production 环境）需在 workflow 中指定environment: production才能访问。

提示：Secrets 值在日志中自动屏蔽。如果你在run步骤中echo ${{ secrets.MY_KEY }}，日志只会显示***。这是 GitHub 的基础防护，但不能替代最小权限原则——只为必要 workflow 分配必要 Secrets。

7. 权限管理与安全加固：让仓库既开放协作又守住底线

7.1 团队权限层级：从 Read 到 Admin 的真实权力地图

GitHub 的权限不是简单的“能看/不能看”，而是精细到操作粒度。在组织 Settings → Manage access 中，可为团队分配五种角色：

常见误区：给所有开发者Admin权限。这相当于给每个员工公司大门钥匙和保险柜密码。某公司因此发生过：实习生误删生产仓库，因Admin权限绕过所有二次确认，30秒内无法恢复。

最佳实践：遵循最小权限原则。新成员入职默认给Read，经培训后升Write；模块负责人给Maintain；Admin仅限 2-3 人，且启用 SSO 和 2FA 强制认证。

7.2 安全告警（Security Alerts）：主动防御依赖漏洞

GitHub 会自动扫描仓库的依赖文件（package-lock.json、pom.xml、requirements.txt），当发现已知漏洞（如 Log4j CVE-2021-44228）时，向有Admin或Maintain权限的成员发送邮件告警，并在仓库 Security 标签页显示详情。

但告警只是起点。关键后续动作是：

• 点击告警 → 「Create Dependabot PR」→ GitHub 自动生成修复 PR（升级到安全版本）
• 审查 PR 中的版本变更是否兼容（如 major 版本升级可能破坏 API）
• 运行 CI 确认无回归 → 合并

Dependabot 不仅修漏洞，还能自动更新依赖到最新版（version updates）。在 Settings → Code security and analysis → Dependabot version updates 中启用，它会定期（默认每周一）创建 PR，大幅降低手动更新成本。

注意：Dependabot PR 默认使用dependabot[bot]账户提交，其签名不受常规 GPG 验证规则约束。这是 GitHub 的设计，无需额外配置。

8. 进阶技巧与避坑指南：那些文档里找不到但每天都在用的经验

8.1 仓库迁移：如何把代码从 A 平台完整搬到 GitHub（含 Issues、PR、Wiki）

很多团队从 GitLab、Bitbucket 迁移到 GitHub。官方迁移工具（Settings → Options → Import code）仅支持代码和部分元数据。要完整迁移，需分三步：

1. 代码与分支：用git clone --mirror镜像原仓库，再git push --mirror到新 GitHub 仓库。--mirror会复制所有分支、标签、Git 对象，但不包含 Issues/PR。

2. Issues 与 PR：使用开源工具github-migrator（Python 编写）。它通过原平台 API 导出 Issues 数据（JSON 格式），再调用 GitHub API 批量创建。注意：原平台需开启 API 访问令牌，且 GitHub 令牌需有issues、pull_requests权限。

3. Wiki：GitLab Wiki 是独立仓库，可直接git clone后git push到 GitHub Wiki（URL 为https://github.com/owner/repo.wiki.git）。

避坑提示：迁移后，所有 Issue/PR 的编号会重置（GitHub 从 #1 开始）。如果原平台 Issue 被大量引用（如代码注释// See GitLab issue #123），需在迁移后全局搜索替换，或在 Wiki 中建立映射表。

8.2 归档仓库：当项目停止维护时，如何体面谢幕

归档（Archive）不是删除，而是将仓库设为只读状态：禁止 push、PR、Issue、Wiki 编辑，但所有人仍可浏览、fork、clone。适用于：

• 已被新项目替代的旧系统
• 个人练手项目已完成使命
• 开源库已移交社区维护

归档操作路径：Settings → Danger Zone → 「Archive this repository」。归档后，仓库首页会显示醒目横幅：“This repository has been archived by the owner. It is now read-only.”。

关键好处：归档仓库仍计入 GitHub Profile 的贡献图（Contribution Graph），且 Fork 数、Star 数保留，不影响作者声誉。而直接删除仓库，所有数据永久消失，Star 数清零，对 SEO 和社区信任是毁灭性打击。

实操心得：某开源库作者在归档前，在 README 顶部添加了三行说明：

⚠️ ARCHIVED: This project is no longer maintained. ✅ Use [new-project](https://github.com/org/new-project) instead. 📜 All historical issues and PRs remain accessible.

这样既尊重了老用户，又引导了新流量，归档后 Star 数反而增长了15%。

8.3 GitHub CLI：用命令行替代 80% 的网页操作

GitHub CLI（gh）是官方命令行工具，安装后可替代大部分网页操作：

• gh repo create my-project --private --description "My new app"（创建仓库）
• gh issue create --title "Bug: Login fails on iOS" --body "Steps to reproduce..."（创建 Issue）
• gh pr create --title "feat: add dark mode toggle" --body "Closes #42"（