基于 Git 的科研工作流的优越性

以 Git 仓库作为论文研究汇编的事实载体，使代码、论文、研究记录和生成结果共享同一个版本历史。这种做法比较优雅，且能够让人产生掌控感、成就感。

一、引言#

我个人认为，理论上说，只要论文（在撰写过程中）倾向于使用 Markdown 和 LaTeX 等纯文本文件，那么把它和代码一起使用 Git 进行托管到 Github，围绕 Git 开展工作，其实是一种比较优雅的方式。

同时，如果家里还有 NAS，它还可以同时被 NAS 的时间机器备份，作为数据资产的保障方式。

因为 Markdown、LaTeX 工程或者相应的代码，它们都是可被追溯的纯文本文件，而不像 Word 一样。Word 每次哪怕只更改一个字，都会把整个文档文件重新变更一次，是无法被细粒度追溯的。而且我还想到了这种工作流模式极其有优势的几点：

在学术写作中，文章的修改往往伴随着代码的变动（例如做了一个实验得出某个结论，相关的文本文件就需要以一定形式组织并写入原文）。如果它们都在同一个仓库内并使用 Git 进行管理，那么代码的变动和 Markdown 文本的变动就可以被写入同一个 commit，还可以附带丰富的 description。

这些 commit 不仅能被人阅读，也可以被 AI 一起进行追溯，便于 AI 参与到其中。这样一来，第三方看到后就能清楚地知道你做了什么实验、得出了什么结论，以及该结论、判断又影响了文章的哪一部分。

这不仅能让自己的工作像历史书一样清晰可追溯，对第三方来说也非常方便。这也就意味着：如果老师接受这套方法，未来就可以围绕着这套工作流，互相清楚对方到底做了些什么，减小未被客观信息固化下来而导致的信息损失和交流成本的骤增。

PS：虽然我感觉让老师接受是最困难的 233

如果将仓库托管在 GitHub 上，就可以充分利用 GitHub Actions 的自动化能力，例如：

针对 Python 代码，可以将 pytest 写入 GitHub Actions 流程中，还可以引入代码格式检查。
如果撰写金融相关领域的论文需要用到 Julia 语法，同样可以运行 Julia 测试，
自动检查引用缺失（涉及到 Markdown、Jupyter Notebook 和代码之间的交互）。
如果使用 LaTeX 撰写论文，还可以将 LaTeX 是否能正常编译写入 GitHub Actions 中。
此外，托管在 GitHub 上还支持将其部署为 GitHub Pages，并绑定到个人域名。在部分内容允许公开的前提下，这种网页化的展示方式能让别人更容易了解到你当前的学术成果。

同时，我认为 GitHub 的 Branch、Issue、Pull Request、Review 和 Actions，其实也可以被运用为面向人类和 AI 科研协作的工具。

例如，在软件工程中，Branch 通常表示一个待开发功能。但在科研中，它完全可以被重新定义为一个尚未被接受的假设、方法或路线。在它被验证之前，主分支不会受到影响，方便进行大胆的探索尝试。

更关键的是，即使是失败的方向探索，评论互动、审查意见等也能够得到保留。几个月后，无论是谁都能知道：这个方向以前试过，而且为什么被放弃。

我认为这对科研非常重要，因为负结果本身也是研究知识。如果不保留相关信息，未来很可能重复走同一条失败路线。

Branch 的运用其实也离不开 PR。例如：老师可以对在 PR 中对某一行论文表述留言、对某个公式提出修改，或者要求补充其他内容。PR 的评论、commit 与 review 历史都会被保留，使未来相关人员能够理解当时为何接受或拒绝这项修改。

更关键的是，上述这些信息具有历史性，即：可以按照时间顺序追溯工作中的内容和互动。这部分上下文是极其价值的，且很容易被遗漏。记录好、使用好这部分上下文，在人与 AI 的协作中是很关键的。

让老师用 Issue 提意见，我认为非常适合 AI 协作工作流。传统方式可能是在微信中互动，但这会导致互动意见散落在多个平台，AI 很难完整获取，也难以知道是否已经解决。

而 Issue 则可以把意见转化为结构化任务，结合 Github 丰富的引用机制，再使用 Github CLI 注入给 AI，能很大程度地增加效率、防止漂移。（不论是注入给 AI 来解决自身，还是作为未来研究的历史信息参考。）

其余的类似于 git worktree 能同时检出多个分支并发处理、PR / Issue 体系拥有完备的引用机制等就不说了，个人认为这些都是基操。

上述这些都是围绕 Git 才能具备的独特优势，我个人觉得是其他工作流远远无法比拟的。

这种思维和 Research Compendium 很类似。Research Compendium 的定义是：把研究项目的数字组成部分，包括数据、代码、文本、报告和元数据组织在一起，使研究结果能够被重新生成。它特别强调三个原则：
1. 使用规范、容易理解的目录结构；
2. 清晰区分数据、方法和输出；
3. 明确记录计算环境。
它甚至直接指出：一个版本控制仓库本身就可以成为 Research Compendium；再加入自动构建工具和可复现环境，就可以升级成可执行的研究汇编。
2024 年发表的一项研究也进一步主张，认为可以把现代软件开发工作流应用到整个科研生命周期中，包括实验设计、数据分析、协作记录和论文写作，而不应等到论文发表时才临时整理代码附件。