语境：
我最近采用了版本控制作为我的数据分析工作的一部分（最后我可能会听到你说：请参阅我之前关于 SO 的问题）。这促使我更多地考虑用于项目的存储库和目录结构。
我的典型研究工作涉及一项或多项研究（即我收集的数据），这些研究被写成一份或多份出版物（期刊文章、书籍章节、演示文稿、报告等）。分析和报告通常使用 R、LaTeX、Sweave、文本数据文件等的组合生成。我真的很喜欢能够上传单个独立存储库的想法，该存储库可用于分析数据和复制出版物。
特别是，我一直在思考出版物、研究、数据和公共代码，以及这些实体如何映射到存储库。例如，为每个出版物拥有一个单独的存储库更好，还是将每个出版物作为更大存储库中的单独文件夹更好。我正在对此提出一些想法，但我很想听到其他选择。
问题：
关于你的第一个问题：
人们使用什么策略将研究、出版物和分析映射到存储库？
大约一年前，我决定为每个出版物、演示文稿或学期/课程建立一个存储库。我的典型目录如下所示：
.git
.gitignore
README.org
ana
dat
doc
org
基本思想（希望）是显而易见的：每个出版物、演示文稿、课程都是一个“自给自足的实体”，我可以轻松地与他人分享。
顺便说一句，您不是第一个问这个问题的人：一个存储库/多个项目而不会混淆？
但是，我也开始使用 git 来管理可能会导致一些出版物的项目（目录结构大致遵循 John Myles White 的ProjectTemplate，但没有使用它）。
.git
.gitignore
README.org
ana
data
docs
graphs
lib
org
报告
测试
关于你的第二个问题：
何时应将相关实体（例如，出版物、研究等）拆分为多个存储库？
我想不出任何理由将出版物、会议等相关存储库拆分为多个存储库。但我会对其他意见感兴趣......
我为每个项目保留一个单独的存储库，一个项目以特定数据集或正在解决的问题为中心。存储库包含解释和表达结果的数据、代码和 Sweave 文档/图表。
我为每个离散的出版物或演示文稿维护一个单独的存储库，因为
可跨项目重用的代码也有自己的存储库。如果我使用已经在一个存储库中的数据提出一个新的离散问题，我会将该数据复制到一个新的存储库中。
如果您想对此严格要求，许多版本控制系统都提供了“子项目”的想法，但我发现这太过分了。