Рекомендации по рабочему процессу / архитектуре контроля версий для аппаратного обеспечения (ECAD), документации и микропрограммного обеспечения

Должны ли мы использовать SVN или GIT? для следующего варианта использования

Как нам организовать систему:

1: «мастер-репозиторий», содержащий все проекты и автономные драйверы, используемые в проектах, причем каждый проект/драйвер представляет собой разные «ветки»?

пример:

MasterRepo
|-Project1
| \---Hardware
|     \--ECAD
| \---Firmware
|     \--src
|     \--includes
| \---Documentation
|-Project2
| \---Hardware
|     \--ECAD
| \---Firmware
|     \--src
|     \--includes
| \---Documentation
|-Drivers
| \---driver1
|     \--src
|     \--includes
| \---driver2
|     \--src
|     \--includes

2: Отдельные репозитории для каждого проекта и автономные драйверы? нам нужно будет «вытащить» или «слить» из репозитория драйверов в репозиторий проекта. Это важно, чтобы показать возможность узнать, какие проекты затронуты в случае ошибки на уровне драйвера.

Project1Repo
|---Hardware
|   \--ECAD
|---Firmware
|   \--src
|   \--includes
|---Documentation


Project2Repo
|---Hardware
|   \--ECAD
|---Firmware
|   \--src
|   \--includes
|---Documentation


DriversRepo
|---driver1
|   \--src
|   \--includes
|---driver2
|   \--src
|   \--includes

Должно ли аппаратное обеспечение полностью находиться в отдельном репозитории? (мы инженеры встроенного программного обеспечения, нам нужно видеть схемы и знать, когда есть изменения, или предлагать изменения и т. д.)

Должен ли каждый драйвер находиться в отдельном репо?

Мы являемся компанией по производству встроенной электроники в автомобильной промышленности. Пока я не начал, команда разработчиков программного обеспечения не использовала никакую систему управления версиями, все было «управлено версиями» через папки и почтовые индексы. и аппаратная сторона вещей по-прежнему использует этот способ управления версиями.

Мы начали использовать SVN (но не привязаны к нему). В настоящее время мы работаем с программным обеспечением, использующим специальную выдуманную модель следующего:

MasterSoftwareRepo
|-Documentation
|-MicroControllerMFG1
| \--FamilyOfMCUs
|    \--Drivers
|    \--Projects
|       \--Project1
|          \--active
|             \--src
|             \--test
|             \--build
|          \--release
|             \--srev1
|             \--srev2
|             \--srev3
|          \--projectSupport
|       \--Project2
|          \--active
|          \--release
|          \--projectSupport
|       \--Project3
|-MicroControllerMFG2
| \--FamilyOfMCUs
|    \--Drivers
|    \--Projects
|       \--Project10
|       \--Project11
|       \--Project13
|-MicroControllerMFG3
| \--FamilyOfMCUs

.......................and so on. 

Система работает... Это некрасиво и неэффективно. Поскольку мы использовали систему, скажем, 6 месяцев, общий размер репозитория превысил 40 гигабайт. И из-за структуры мы действительно не используем контроль версий, как предполагалось, это больше папок с историей.

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

Таким образом, большая идея конфликтов слияния из-за людей, работающих над одним и тем же проектом или файлом, не существует, поскольку репозитории действительно здесь только для того, чтобы отслеживать нас и хранить документацию об изменениях и т. д.

Каковы некоторые предложения для нашего варианта использования? Мы считаем, что идея с 1 репозиторием слишком велика, но мы застряли на идее использования этого, чтобы мы могли использовать драйверы. и базовая структура проекта и т. д., поэтому у нас есть полная сговорчивость к началу.

Должно ли оборудование быть отдельным репозиторием? можем ли мы включить его в наш репозиторий как ветку или как мы это сделаем?

Не используя размещенные решения, все решения должны быть размещены самостоятельно.

И да, я знаю, что это длинный пост, но я подумал, что чем больше подробностей я дам, тем лучше вы сможете понять ситуацию и наш вариант использования.


138
1

Ответ:

Решено

Если вы используете репозиторий в течение 6 месяцев, а его размер уже составляет 40 гигабайт, со временем он, вероятно, станет слишком большим, чтобы им было легко управлять.

Для проблемы, с которой вы столкнулись, я бы рекомендовал переключиться на git, но использовать git-lfs для управления вашими двоичными (не ascii) файлами. git-lfs позволяет пользователям локально иметь только последнюю версию двоичного файла, тогда как в обычном git все предыдущие версии каждого файла хранятся локально (в сжатой форме).

Это позволит вам хранить документацию и ECAD в одном репозитории, но локально просматривать только текущую/последнюю версию файлов.

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

MasterRepo
|-Project1
| \---Hardware
|     \--ECAD
| \---Firmware
|     \--src
|     \--includes
| \---Documentation
|-Project2
| \---Hardware
|     \--ECAD
| \---Firmware
|     \--src
|     \--includes
| \---Documentation
|-Drivers
| \---driver1
|     \--src
|     \--includes
| \---driver2
|     \--src
|     \--includes

Что касается количества веток — можете ли вы выполнить все свои тесты на ветке из запроса на включение? или вам нужно, чтобы ваши изменения тестировались в течение 1-2 месяцев, прежде чем определить, являются ли они стабильными/хорошими?

Если первый вариант реалистичен, я думаю, что сработает одна «основная» ветка, где вы отправляете запрос на включение и выполняете все свои тесты в этой ветке, прежде чем объединять этот PR с основной основной веткой.

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

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