许多小的脚本，一个或多个存储库？

同事和我自己都遇到了一个我们有很多看法的问题。

当前，我们有一个git存储库，我们将所有cronjobs保留在其中。大约有20克朗，它们除了它们都是小型python脚本并且对于某些活动必不可少之外，并没有真正的关联。我们使用一个fabric.py文件来部署和requirements.txt文件管理所有脚本的要求。

基本上，我们的问题是，是否将所有这些脚本都保存在一个git存储库中，还是应该将它们分离到各自的存储库中？通过将它们保存在一个存储库中，可以更轻松地将它们部署到一台服务器上。对于所有脚本，我们只能使用一个cron文件。

但是，这感觉不对，因为20个cronjob在逻辑上不相关。此外，使用一个在requirements.txt文件中的所有脚本，这是很难搞清楚什么是依赖一个特定的脚本，它们都必须使用的软件包的版本相同。

我们可以将所有脚本分离到各自的存储库中，但这会创建20个需要记住和处理的不同存储库。这些脚本中的大多数都不是很大，解决方案似乎过大。

一个相关的问题是，我们是对所有cronjobs使用一个大crontab文件，还是对每个cronjobs使用单独的文件？如果每个人都有自己的设备，那么一个crontab的安装如何避免覆盖另一个19个？这似乎也很痛苦，因为随后需要20个不同的cron文件进行跟踪。

简而言之，我们的主要问题是将它们紧密地捆绑在一起作为一个存储库，还是将它们通过自己的require.txt和fabfile.py分离到自己的存储库中？我们觉得我们也可能正在寻找一些非常简单的解决方案。有没有更简单的方法来解决此问题？

除非有特定的理由让您认为每个人都值得一个单独的回购协议（它们会增长很多吗？可能不会！）似乎更合理，将它们全部放入一个回购协议中，并省去了克隆所有回购协议的麻烦。其中有20个回购。

将每个人保存在单独的仓库中似乎是在不存在问题的情况下创建问题的途径。

不要为自己（和他人）创造额外的工作。

除非有充分的理由进行拆分（性能；压倒性的组织/安全问题等），否则我的直觉是将源文档放在同一存储库中。

将系统分成单独的存储库通常会产生阻碍重用的障碍；因为重用只是组织必须摊销开发成本的唯一方法，所以任何妨碍重用的方法实际上都是一件坏事。