使用git进行多语言实现的最佳实践是什么？

Question

所以我有一些私有git存储库，它们是算法的不同语言实现（Python，Java等）。每个实现在功能上都相同，执行相同的步骤并提供相同的输出。目前，这些是单独的回购，但我想知道我是否不应该将它们统一到一个回购中，目录指示语言，如：

  master
     - java
     - python
     - ruby

我可以使用git-repo combine命令来保存历史记录，这不是问题。我对这方面的最佳做法感到好奇。

Answer 1

我在Mercurial遇到了同样的问题，我想在COBS和C中实现一个算法（Python）。

最终我决定将其拆分为单独的存储库（即使Python实现包含一个C扩展，它具有与普通C实现类似的代码）。我的理由归结为：

• 我想要实现的独立版本编号和独立版本。
  • git describe是一个很好的功能，可以根据最新的带注释标签识别版本。只有存储库中的一个实现，git describe用法很简单。但是，如果在一个存储库中使用具有单独版本号的不同实现，则git describe使用变得更加复杂，需要使用--match选项来限制具有给定前缀的标记。例如git describe --match "python*"
• 通常组织Python模块的方式（Python module packaging best-practices），让我更有意义的是让Python实现保持独立和自包含。
• 在其他条件相同的情况下，我倾向于支持更细粒度的模块化。

Answer 2

这是一个艰难的电话。可能什么是“最好的”只是归结为个人偏好和/或手头的具体情况。

一方面，每个目录在技术上与其他目录“无关”。虽然他们确实实现了相同的算法，但没有一个依赖于任何其他算法（因此从纯源代码的角度来看，它们是无关的）。通常，不相关的事情最好留在单独的回购中（出于Craig McQueen的回答中所确定的原因）。

但是，因为他们做实现相同的算法，您可能会发现如果需要更改算法，则需要对所有目录进行非常类似的更改。在这种情况下，可能有意义地将所有更改作为单个提交进行。假设你决定算法需要支持“虚拟dinglehoppers”。您将为每个目录添加该支持并进行单个提交，其消息为“添加对虚拟dinglehoppers的支持”。这很好，因为如果你以后决定添加虚拟dinglehopper支持 bad ，你现在可以只恢复一次提交。另一种方法是对三个独立的存储库进行三次单独的提交，然后从三个独立的存储库中恢复三次单独的提交。

同样，这是一个艰难的电话。我认为没有一条明确，严格的规则可供选择。