关于知识库框架结构的一些想法#

因为我的各种文档或笔记过于分散凌乱, 非常需要进行统一管理. 但是使用的技术栈千差万别, 有纯文字用 markdown 写的, 有使用 jupyter 笔记本内嵌代码的, 有使用 mathematica 的, 有用 typst 和 latex 写更专业的出版级文档的, 也有主要写代码附文说明的. 现有的知识库框架不可能支持如此多种类的文件管理, 事实上传统的知识库软件仅能做到管理文字内容, 并且也很难做到与其他编辑器的通用. 例如编写代码另附文档的情况, 势必要在其他编辑器处进行代码的编辑, 也当然希望在那里就完成文档的修改, 而不必打开特定的知识库管理或文档软件.

我想通过 git submodule 与 obsidian 协同构建一个包罗万象的知识库框架, 力图让专业的软件做专业的事, 而不必让知识库管理它能力范围之外的文件, 例如源代码啊, 交互式笔记本啊什么的.

obsidian 与 git submodule#

obsidian 本质上还是文字编辑软件, 在不加插件的前提下, 只有基础的文字编辑功能 (依托 markdown 标记语言). 因此我们只让 obsidian 管理博文和各类文档, 并辅以 git 进行版本控制.

项目结构如下:

.
├─ Blog
└─ Work
    ├─ A
    └─ B
    ...

其中 Blog 是记录日常或简单知识的文章; 而偏知识向或更专业的, 以及不使用 markdown 语言写的内容都放置于 Work 目录下, 每组另外再分目录.

Work 目录下的每个文件夹都是独立的 git 仓库, 并都注册为知识库的 子模块. 这样做有助于知识库挂载各种项目, 并且都高度自治, 提高独立性. 建议不要在子项目内编写文章, 重要的文章应该存放在主仓库内, 使用链接导向子项目内的文件, 如代码等.

版本控制#

将整个知识库置于 git 的管理之下, 不仅有助于追溯历史, 而且可以使用 GitHub 实现同步. 但是缺点也显而易见, 就是修改不再随心所欲. 因为你总要为它编写一个提交信息, 而且也不希望提交历史中总是无聊琐碎的标点符号或是遣词造句修改.

提交信息的编写总体上符合 约定式提交, 只是在另一些方面进行了扩充与修改:

1. 当新建一篇博客时, 提交信息如下:

   doc
   
   yyyy-MM-dd

   下面的日期是文章的写作日期. 因为博客的标题体现在文件的名字上, 没有必要赘述. 但是可能提交的是往年的文章, 所以日期需要特别注明.

2. 当子模块发生了修改, 提交类型写 submodule, 并只是简单写明是增加内容或是发生修改, 抑或是删除内容等. 详细的修改信息可以在子模块所在的仓库查看.

3. 尽量等子模块更新完成后一并提交. 不同的子模块分开提交.