笔记本

性能问题的觉醒 你在数据科学项目上工作了一段时间。手头有二十多个笔记本文件、几张图片，还有三个月前看起来还不错的文件夹结构。 当你执行git status查看修改时…等待。继续等待。在等待的过程中你甚至怀疑电脑是卡死了还是在冥想。 剧透：它没在冥想。它在煎熬。 问题是有名有姓的 Git本身并不慢。慢的是你的仓库。 执行git status时，git需要做两件看似简单实则不然的事： 扫描整个文件树检查变更 逐个general比较文件与暂存区的差异 普通仓库中这个过程是瞬时的。但Jupyter笔记本本质上是伪装成文档的JSON文件——而且不是普通JSON：它包含了代码、输出结果、base64编码的图片、内核元数据，基本上囊括了设计者能想到的所有内容。 一个包含少量图表的"小型"笔记本可能就有几MB。乘以二十个笔记本，你就得到了一个每次查看都要呻吟的仓库。 如果你还重命名了文件夹…git会理解为"删除了50个文件并新增了50个文件"。保证让你’爽’到极致。 方案一：给仓库装个门卫 第一个解决方案优雅得让人懊恼为什么没早点知道西门庆。 FSMonitor的工作原理：不再让git每次扫描整个仓库，而是由操作系统主动通知哪些文件发生了变化。 说白了：就像是门口有个门卫告诉你"只有老张进来了"，而不必每次核对全量宾客名单。 启用方法： git config core.fsmonitor true git config core.untrackedcache true 完成。就这么简单。 初次启用后的第一次西git status可能耗时相当(甚至更长，因为要初始化缓存)。但从第二次开始…魔法降临了。 在我的400+文件仓库中，git status从2- períodos3秒变成了真正的瞬时完成。不是"变快了"，是真正的心念电转。 兼容性如何？ macOS: 支持，使用FSEvents Linux: 支持，使用inotify(只要内核支持) Windows: 支持，使用ReadDirectoryChangesW 所以说，全平台通用。 方案二坏人保存菜谱而非成品照片 FSMonitor加速了扫描过程，但西存在另一个问题：笔记本文件依然庞大。每次执行单元格并保存时，即使代码相同文件内容也会改变，因为输出结果不同。 这意味着： 不可读的diff(谁想看图片的base64?) 膨胀的commit 地狱级merge 解决方案叫nbstripout，人如其名：在提交前剥离笔记本的输出内容。 这好比保存菜谱但不保存成品照片。代码得以保留，结果可以随时重新生成。 使用uv安装： uv add nbstripout uv run nbstripout --install 或用传统pip： pip install nbstripout nbstripout --install --install参数会自动配置git过滤器。此后提交笔记本时都会自动剥离输出。 验证是否生效： git config --get filter.nbstripout.clean 若返回类似nbstripout Ressource则配置成功。 需要保留输出怎么办？ 好问题。有时你需要提交已执行的笔记本，比如用于文档或让他人直接查看。 ...