4.3 协作工具与平台

4.3 协作工具与平台

本节摘要：SOURCE 4.3 覆盖 GitHub 仓库/协作者/PR/Issues、JupyterHub 多用户环境与 Google Colab 免安装场景。本节对比三平台在内核、存储、Git 集成上的差异，帮助选型而非「哪个更好」口号。

先说结论

阅读完本节，你应当能够：

1. 在 GitHub 建仓库并用 Pull Request 审查 Notebook 变更
2. 说明 JupyterHub 适合课程与团队统一内核的场景
3. 说明 Colab 适合轻量分享与 GPU 试用、不适合私密生产数据

一、GitHub 协作

SOURCE 要点：

• 创建仓库存放 ipynb 与数据说明（大数据用 Git LFS 或外部存储，正文禁外链则写「数据另行获取」）
• 邀请协作者共同 push 或通过 fork
• Pull Request：功能完成请求合并，reviewer 用 nbdime diff 看单元格变更
• Issues 跟踪 bug、任务、讨论

PR 检查清单：Clear Output、Restart & Run All、内核/requirements 是否文档化（requirements.txt 或 conda env.yml）。

二、JupyterHub

SOURCE：面向多用户共享服务器——管理员预装内核与包，学生/成员浏览器登录即写 Notebook。适合高校机房、企业内网分析平台。

本地 1.1 节的 ipykernel 注册在 Hub 上通常由管理员完成，用户只选内核名。

三、Google Colab

SOURCE 提及云端免安装、可分享链接。特点：

• 免费 GPU/TPU 时段有限
• Google Drive 存 notebook
• Git 集成弱于本地+GitHub 工作流

敏感数据不应上传 Colab；生产 pipeline 仍推荐自有 Hub 或本地 venv。

四、平台组合实践

常见组合：本地 venv 开发 → GitHub PR → nbconvert HTML 给业务方；课程用 Hub 布置作业 + nbgrader（SOURCE 扩展提及）。Colab 作开源教程复现即可。

⚠️ 常见坑：Colab 与本地 pandas 版本不一致——README 或 00 导读写清版本号。

💡 关键直觉：平台选型的轴是 数据敏感度 × 环境统一度 × Git 深度——没有万能平台。

温故知新

• GitHub + PR + Issues：协作主路径
• JupyterHub：统一内核与配额
• Colab：轻量/GPU，慎机密数据
• requirements 文档化：跨平台复现

第 4 章完结；第 5 章处理 性能、扩展与长期工作流。

平台选型决策脚本

def choose_platform(data_sensitive, env_unified, git_depth):
    # data_sensitive: 是否涉及机密数据
    # env_unified: 是否需要统一内核版本
    # git_depth: 是否需要深度 Git 协作
    if data_sensitive:
        return "本地 venv / 内网 JupyterHub"
    if git_depth and not env_unified:
        return "本地开发 + GitHub PR"
    if env_unified:
        return "JupyterHub（课程/团队）"
    return "Colab 轻量试用"
​

用这个函数评估团队需求：只有"公开数据 + 简单分享 + 免安装"三条同时满足，Colab 才值得优先；只要涉及机密数据，无论多方便都该回到本地或内网。

GitHub 协作的实操顺序

1. 本地 git init、Clear Output、首次 commit。
2. 推到远端仓库，邀请协作者。
3. 每次改动用新分支，改完开 PR。
4. reviewer 用 nbdime 看 diff，重点看 Markdown 格与代码格。
5. 合入前要求 PR 里附带 requirements 变更说明。

JupyterHub 的配额管理

Hub 上管理员可以按用户设置内存与 CPU 配额。用户侧能做的只有两件事：尽早用 5.1 节的 downcast 与 chunksize 控制单次分析内存；不用时及时关闭浏览器标签或注销，释放会话占用的资源。

Colab 的边界问题

Colab 免费时段有限、GPU 排队不确定，不适合长任务。它最大的风险是数据隐私：上传到云盘存储的 Notebook 默认跟随账号权限，误开分享链接就可能泄露。结论：Colab 适合公开教程复现和快速原型，生产数据一步都不要碰它。

跨平台复现的底线

无论选哪个平台，都要在仓库里固定三样东西：Python 版本、核心包版本、内核 display-name 约定。格式上写成 requirements.txt + 一两行 README 说明，团队新成员照做即可复现，这是所有协作工具能正常工作的前提。

权限与安全边界

无论哪个平台，都要回答两个问题：谁能看这份 Notebook？谁能在上面写代码？GitHub 用分支保护限制直接 push 到 main；JupyterHub 用用户分组控制内核与目录权限；Colab 关掉"任何人可编辑"的链接分享。权限收紧通常比出事后补救便宜得多。

平台迁移的判断点

团队从本地协作转向统一平台，通常出现三个信号：环境反复对不上版本、成员机器性能参差、需要给外部读者稳定访问地址。任一信号出现，就值得评估 JupyterHub 或托管 Notebook 服务；如果只是两三个人互发 ipynb，本地 + Git 就够。

权限的最小够用原则

给协作者开权限时遵循最小够用：只需看的人开只读，需要改的人开写权限，能合入主干的人控制在两三人。Notebook 里的内核执行权限更要收紧——能跑代码就等于能访问数据。权限列表每季度核对一次，删掉离职与长期不活跃的账号。

平台选择后的回退预案

无论选了哪个平台，都保留一条回退路径：Notebook 和数据的权威版本始终留在本地 Git 仓库，平台只是分发与协作层。这样平台出问题、配额不够、厂商调整策略时，团队能随时迁回，不会被困在某个单一平台上。