Подтвердить что ты не робот

Какая наилучшая практика с git для нескольких языковых реализаций?

Итак, у меня есть несколько частных репозиториев git, которые представляют собой различные языковые реализации (Python, Java и т.д.) алгоритма. Каждая реализация функционально идентична, выполняет одни и те же шаги и дает один и тот же результат. В настоящее время это отдельные репозитории, но мне было интересно, не следует ли объединять их в одно репо с каталогами, указывающими язык, например:

  master
     - java
     - python
     - ruby

Я мог бы использовать команду объединения git -repo для сохранения истории, так что это не проблема. Мне было просто любопытно относиться к этой практике.

4b9b3361

Ответ 1

У меня был этот же вопрос с Mercurial и алгоритм (COBS), который я хотел реализовать в C и Python.

В конце концов я решил разделить его на отдельные репозитории (хотя реализация Python включала расширение C, которое имело аналогичный код для простой реализации C). Мое рассуждение сводилось к:

  • Я хотел иметь независимую версию нумерации реализаций и независимых выпусков.
    • git describe - хорошая функция для идентификации версии на основе последнего аннотированного тега. Использование только одной реализации в репозитории, использование git describe прост. Но если разные реализации с отдельными номерами версий находятся в одном репозитории, то использование git describe становится более сложным, поэтому необходимо использовать параметр --match для ограничения тегов с заданным префиксом. например git describe --match "python*"
  • Как обычно организованы модули Python (лучшие практики упаковки модулей Python), мне было более полезно поддерживать реализацию Python отдельный и автономный.
  • При прочих равных условиях я предпочитаю более мелкомасштабную модульность.

Ответ 2

Это сложный вызов. Вероятно, что "лучше всего" просто сводится к личным предпочтениям и/или специфике обстоятельств.

С одной стороны, каждый каталог технически "не связан" с каким-либо другим. Хотя они реализуют один и тот же алгоритм, ни один из них не зависит ни от одного из других (поэтому с точки зрения чистого исходного кода они не связаны). Обычно не связанные вещи лучше всего оставлять в отдельных репозиториях (по причинам, указанным в ответе Крейга МакКуина).

Однако, поскольку они реализуют один и тот же алгоритм, вы можете обнаружить, что если вам нужно изменить алгоритм, вам нужно будет внести очень похожие изменения во все каталоги. В таком случае может иметь смысл сделать все изменения в виде одной фиксации. Скажем, вы решили, что алгоритм должен поддерживать "виртуальных динозавров". Вы добавили бы эту поддержку в каждый каталог и сделали бы одну фиксацию, чье сообщение: "Добавить поддержку виртуальных дингельхопов". Это хорошо, потому что, если позже вы решите, что добавление поддержки виртуального dinglehopper было плохим, вы можете теперь вернуть только одну фиксацию. Альтернативой является создание трех отдельных коммитов для трех отдельных репозиториев, а затем возврат трех отдельных коммитов из трех отдельных репозиториев.

Опять же, это жесткий вызов. Я не думаю, что существует четкое, твердое и быстрое правило.