第4章 · 协作与分享优化
第 4 章 · 协作与分享优化
章节摘要：Notebook 单人爽、多人痛，痛点在 JSON diff 与巨型输出。本章按 SOURCE 第 4 章：Git 管理 ipynb、nbdime/jupytext 改善 diff、nbconvert 多格式导出、GitHub/JupyterHub/Colab 协作——并强调 Clear Output 与 .gitignore 检查点目录。
核心问题
阅读完本章，你应当能够：
- 初始化 Git 仓库并合理忽略 checkpoints
- 安装 nbdime 使 git diff 可读 Notebook 变更
- 用 jupyter nbconvert 导出 HTML/PDF/Markdown/脚本
- 说明 GitHub PR 与 JupyterHub 在团队中的分工
核心概念速览
金句：协作 Notebook = 版本控制 + 可读 diff + 无输出提交——三者缺一，PR 就是灾难。
子章节导航
4.1 版本控制
git init/add/commit、.gitignore、nbdime、jupytext、分支策略。
4.2 导出与分享格式
Download as、nbconvert --to html/pdf/markdown/script。
4.3 协作工具与平台
GitHub 仓库/PR/Issues、JupyterHub、Google Colab 边界。
子章节之间的逻辑关系
Git 跟踪变更 → nbdime 让人能 review → nbconvert 给非 Git 读者 → 平台托管分发
前置知识与后续延伸
- 前置：第 1 章 Clear Output；第 2–3 章可复现 Run All
- 为后续铺垫：第 5 章 nbconvert 批处理与 papermill 自动化
本章学习建议
本章解决"Notebook 进了团队就乱"的问题，建议按三步实践：第一步，把 4.1 的 .gitignore 与 nbdime 装上，把你自己最近的一个 Notebook 提交到 Git，先体会 Clear Output 前后 diff 大小的差别；第二步，用 4.2 的 nbconvert 把同一份 Notebook 分别导出成 HTML 和 .py，观察两种受众看到的东西有何不同；第三步，对照 4.3 的平台对比表，为你的团队选一个主协作路径——多数团队是"本地 venv 开发 + GitHub PR 审查"，课程场景选 JupyterHub。做完这三步，你就能跟同事解释"为什么 Notebook 不能直接当 Word 用"。
本章结构图
本章协作最小约定
团队协作最容易在三个地方失守：提交时带了巨大输出、环境版本对不上、分支合入没人把关。本章给出的最小约定是：提交前 Clear Output，Restart & Run All 一次通过，PR 附带 requirements 变更说明。把这三条写进仓库 README 的"贡献指南"，新成员第一次提交就能对齐。
本章实战自测
挑一份你最近完成的 Notebook，按本章流程走一遍：配好 .gitignore 与 nbdime 后提交一次，对比 Clear Output 前后的提交体积；用 nbconvert 导出 HTML，发给一位非技术同事看能否读懂；对照平台对比表，说明你当前的工作流属于哪种组合、为什么这样选。三项做完，本章的目标就算达成，你的 Notebook 也从"个人的"变成了"团队的"。