非标准的git用法:如何跟踪许多手稿的不同版本

Question

在我们的项目中，我们需要创建和维护一组古代手稿(这些手稿被扫描并使用OCR软件转换为文本)。手稿的数量约为1000份。其中有些是人工复制的，经过几代人的传阅，因此随着时间的推移，不同的版本出现了。一个版本的差异通常很小，但一份手稿的版本数量可能很大，平均约5-7个版本。手稿根据其内容和其他因素分成几组。我们的项目作为某种“中间软件”或纯粹的数据提供给其他项目，这些项目可能以更友好的方式呈现信息，如桌面GUI、网站或移动应用程序。我们的基础设施应该支持协作(比如错误更正，等等)对于那些女儿项目和个人来说，就像维基一样。

最初的想法是将手稿保留为纯文本文件(在org-模式中用于轻量级标记和一些元数据)，而组应该由目录表示，如下所示：

Project/
├── Group1
│   ├── Group3
│   ├── manuscript_A
│   └── manuscript_B
└── Group2
    └── manuscript_C

不同版本的手稿应保存在单独的永久(即不合并)的分支，如分支手稿_B-雅典_728。

问题：

1. 这种方法的问题是，如果将这样的git存储库上传到例如GitLab，那么的所有不同分支都将同时显示所有手稿，从而使这个版本控制系统无法使用。是否有一种方法可以对分支进行分层分组，或者以某种方式将一组分支“附加”到一个文件(手稿)？
2. 在某种程度上，在某个文件中间阅读的读者是否有可能在文本中的特定位置找到另一个版本，可以在这样的分支中找到？
3. 当所有内容都在Unicode中时，git能与这种情况相结合吗？(a)手稿内容，(b)项目、目录和文件名，(c)分支名称？
4. 是否有更好的方法来组织这类收集( git)？我在考虑为每个手稿创建一个单独的git存储库。

就像这样：

Project/
├── Group1
│   ├── Group3
│   ├── Manuscript_A
│   │   └── manuscript_A
│   └── Manuscript_B
│       └── manuscript_B
└── Group2
    └── Manuscript_C
        └── manuscript_C

但这似乎更难维护，您得到了不必要的层次结构级别- Manuscript_A类型目录.或者，是否可以在一个目录中有几个git repos，每个目录都跟踪其特定的文件？

Answer 1

并非每个“跟踪不同版本的X”的概念都是相同的，而且听起来并不像您的项目“跟踪不同版本的手稿”的概念与“跟踪程序源代码的不同版本”的标准模型足够接近，从而使git成为正确的工具。

软件版本控制系统是关于跟踪文件随时间的演变，特别是当这种演变需要跨文件进行协调时。所有这些似乎都不适用于这里。所以大多数git能做的事，你都在“四处奔波”。

回答你的问题：

1)是。您可以“命名空间”分支。

manuscriptA/version1
manuscriptA/version2
manuscriptC/version10
...

但是，使用这些名称空间将取决于您的工具。或者你可以用单独的回复。

( 2)否。您需要编写重要的外部工具来支持这一需求。git可以告诉您在分支历史记录中文件最后一次更改的位置，但是它通常不能在一个分支上显示版本，并在另一个分支不同的地方进行注释。

git中最接近于支持这一需求的概念是合并成绩单，在版本不同的地方保留冲突标记。当然，git冲突标记并不是最直观的表示方法。一旦你把手稿归纳成一个冲突的文件，你已经从图片中删除了“存储多个版本的文件”的最后痕迹，所以git (或任何软件版本控制系统)作为解决方案就更没有意义了。

3)我认为unicode是你最不担心的。

( 4)几乎可以肯定，但由于我不在这一领域工作，我不知道它们会是什么。