Нужно предложение по макету git-репо для нового проекта - PullRequest
2 голосов
/ 19 мая 2009

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

Проект представляет собой прошивку для двух встроенных устройств, которые общаются друг с другом и упакованы в пару. Для обоих устройств есть производственный вариант и производственный вариант кода. Оба проекта устройств имеют несколько вспомогательных проектов для использования различных битов аппаратного обеспечения (мигание светодиодов и т. Д.) Или аппаратных битов кода (драйверы и т. Д.). Большая часть кода распространена во всем.

У меня также есть требование, чтобы иметь возможность пересматривать производственную и производственную прошивку независимо друг от друга, чтобы не дать одному из них отправить другую обратно посредством проверки.

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

  • ProjectRoot
    • 1012 * включают *
    • ЦСИ
    • DeviceA
      • Производство
      • Производство
      • мигает
      • Кнопка
      • ...
    • прибор В
      • Производство
      • Производство
      • мигания
      • Кнопка
      • ...

У меня возникает соблазн поставить производство и производство на филиалы, но я обычно работаю как в определенный день, так и git позволяет активировать только одну ветвь за раз. И тогда я бы не знал, что делать с миганием, кнопками и т. Д., Потому что они на самом деле не производятся или не производятся. Предложения?

Разъяснения:

  • Производственная версия кода используется на производственной линии для тестирования аппаратного обеспечения. Производственный код загружается после того, как оборудование проходит тестовую станцию ​​и отправляется заказчику. Они похожи как минимум на 75%, но они должны быть независимыми, чтобы я мог исправить ошибку в рабочем коде, не останавливая производственную линию.

  • Поскольку DeviceA и DeviceB являются парой, оба набора кодов помечаются и выпускаются одновременно с одним и тем же номером версии выпуска.

Ответы [ 2 ]

2 голосов
/ 19 мая 2009

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

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

Чтобы привести пример, вы хотите, чтобы ваш драйвер находился в отдельном хранилище от вашего аппаратного обеспечения. Это связано с тем, что интерфейс между программным и аппаратным обеспечением очень четкий и представляет собой естественный шов для разложения. Кроме того, одна и та же версия драйвера будет применяться к ряду этапов проектирования вашего устройства.

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

Ветвление и слияние в git настолько дешевы, насколько вы можете себе позволить, а переключение между ветвями происходит молниеносно; так что нет штрафов за наличие веток. Также довольно легко подобрать совместимые изменения между ветвями. Подход, который вы обычно видите в мире программного обеспечения (ветки для выпусков плюс один HEAD), работает довольно хорошо.

Вы, вероятно, должны хранить демонстрационные / тестовые модули (мигалки и т. Д.) Вместе с модулями, которые они должны демо / тестировать. Это потому, что интерфейсы демонстрационной связи часто подвержены изменениям. Таким образом, вы должны будете синхронизировать демонстрационный код с реальными устройствами, что должно способствовать стабильности проекта в долгосрочной перспективе.

Как примечание: в мире FPGA вы обычно создаете прототипы на большом устройстве и производите его на ограниченном устройстве. Таким образом, ваши модули получат две разновидности, которые разрабатываются независимо. Возможно, вы захотите хранить эти разновидности в отдельных репозиториях, потому что они, по сути, разные сущности. В этом случае код, который разделяется между ними (всегда есть некоторый переносимый код, который вы можете использовать повторно), может находиться в отдельном репо и представлять собой отдельную библиотеку. Особенно, если размер кода оправдывает это.

Затем вы можете связать все упомянутые модули вместе, используя подмодули git.

1 голос
/ 19 мая 2009

Я думаю, вы могли бы использовать субмодули. Я не уверен на 100%, как это работает, но вы можете создать git-репо для вашего общего кода (скажем, светодиодный и пользовательский интерфейс или даже по одному репо для каждого) и включить копию этого репо в качестве подмодуля вашего репо для A и еще одна копия в виде подмодуля репо для B.

Если вы хотите внести изменения в общую часть, сделайте это на устройстве, над которым вы сейчас работаете. Когда вы закончите, внесите изменения в подмодули другого продукта. Вы также можете иметь репо для общей части где-нибудь еще, если вам удобнее.

Подводя итог: ваш повторно используемый код хранится в отдельных репозиториях, поэтому вы МОЖЕТЕ использовать его повторно.

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

...