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

Question

所以我有一些私有git存储库,它们是算法的不同语言实现(Python,Java等).每个实现在功能上都相同,执行相同的步骤并提供相同的输出.目前,这些是分开的回购协议,但如果我不应该他们统一为一个回购协议,与指示语言,如目录,我想知道:

  master
     - java
     - python
     - ruby

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

Answer 1

我有与Mercurial相同的问题,以及我想用C和Python实现的算法(COBS).

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

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

Answer 2

这是一个艰难的决定。也许“最好”只是归结为个人喜好和/或当前情况的具体情况。

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

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

再说一遍，这是一个艰难的决定。我认为没有一个明确的、硬性的规则可以遵循。