在我们的项目中，我们需要创建和维护一系列古代手稿（使用OCR软件扫描并转换为文本）。手稿数量是ca. 1000.其中一些被手动复制并传递了几代，因此随着时间的推移出现了不同版本的版本。一个版本的差异通常很小，但一个手稿版本的数量可能很大，平均约为5-7。稿件根据其内容和其他因素分组。我们的项目是某种＆＃34;中间件＆＃34;或其他项目的纯数据供应，可能以更加用户友好的方式呈现信息，如桌面GUI，网站或移动应用程序。我们的基础设施应该为那些女儿项目和个人提供协作（如纠错等），比如维基。
最初的想法是将稿件保留为纯文本文件（在org-mode中用于轻量级标记和一些元数据），而组应由目录表示，如下所示：
Project/
├── Group1
│ ├── Group3
│ ├── manuscript_A
│ └── manuscript_B
└── Group2
└── manuscript_C
不同版本的稿件应保存在单独的永久性（即不合并）git分支中，如分支手稿_Bara_728。
问题：
这种方法的问题在于，如果将这样的git存储库上传到例如GitLab将立即显示 ALL 手稿的所有不同分支，使此版本控制系统无法使用。有没有办法按层次结构或某种方式对分支进行分组＆＃34;附加＆＃34;一组分支到一个文件（手稿）？
对于读取某个文件中间的读者，是否有可能在文本中的特定位置存在另一个版本，可以在这样的分支中找到？
当所有内容都是Unicode时，git如何与案例结合：（a）手稿内容，（b）项目，目录和文件名，（c）分支名称？
有没有更好的方法来组织这样的收集（在git中）？我正考虑为每个手稿创建一个单独的git存储库
Project/
├── Group1
│ ├── Group3
│ ├── Manuscript_A
│ │ └── manuscript_A
│ └── Manuscript_B
│ └── manuscript_B
└── Group2
└── Manuscript_C
└── manuscript_C
但这似乎更难维护，你得到一个不必要的层次结构级别 - Manuscript_A类型目录......或者是否可以在一个目录中有几个git repos，每个目录都跟踪其特定文件？
答案 0 :(得分：1)
并非每个概念都跟踪X＆＃34;的不同版本。是一样的，它听起来不像你的项目的概念，跟踪稿件的不同版本＆＃34;与标准模型足够接近，可以跟踪程序的不同版本的源代码＆＃34;使git成为正确的工具。
软件版本控制系统是关于跟踪文件的 evolution ，特别是当需要跨文件协调进化时。这似乎都不适用于此。所以git可以做的大部分工作都是你在＆＃34;周围工作＆＃34;。
回答你的问题：
1）是的。你可以＆＃34;命名空间＆＃34;分支
manuscriptA/version1
manuscriptA/version2
manuscriptC/version10
...
但是你的工具可以使用这些命名空间。或者你可以使用单独的回购。
2）否。您需要编写重要的外部工具来支持此要求。 git可以告诉您文件在分支历史记录中的最后更改位置，但它通常无法在另一个分支不同的地方显示带有注释的分支上的版本。
git中最接近支持这种需求的概念是合并成绩单，在版本不同的地方保留冲突标记。当然，git冲突标记远从最直观的方式来表示它。一旦你将手稿归结为一个冲突的文件，你就删除了最后一个文件＆＃34;存储多个版本的文件＆＃34;从图片中可以看出git（或任何软件版本控制系统）作为解决方案的意义不大。
3）我认为unicode是你最不担心的。
4）几乎可以肯定，但由于我不在这个领域工作，我不知道他们会是什么。