При использовании git для управления исходным кодом прошивки из аппаратного проекта, стоит ли иметь схему / печатную плату KiCAD в одном репозитории?

Question

Я уже использую git как VCS для управления ПО и прошивкой я разрабатываю. Проделав в последнее время некоторую работу на стороне оборудования и придя к выводу, что жизнеспособно управлять схемами KiCAD и файлами печатной платы также в git (пожалуйста, взгляните на https://jnavila.github.io/plotkicadsch), мне было интересно наличие микропрограммы и схем оборудования в одном репозитории git - и, возможно, на которые ссылается один и тот же проект github и средство отслеживания проблем - может быть очень интересным и продуктивным, поскольку оборудование и микропрограммное обеспечение так тесно связаны.

Часто новые функции в прошивке требуют, чтобы вы изменили печатную плату, и обратное тоже очень верно, поэтому изначально для меня имеет смысл, что оба могут управляться вместе в одном репозитории git, возможно, имея подкаталог схема вроде:

project (in git)
   - kicad
   - firmware

где субдиректор kicad будет иметь все файлы схемы и печатной платы и firmware будет содержать исходный код прошивки, которая должна работать на оборудовании, разработанном в KiCAD.

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

Вы когда-нибудь пробовали или думали об этом? Можете ли вы предвидеть какие-то "препятствия" или что-то, что настоятельно не советовало бы делать это таким образом?

Answer 1

По вашей ссылке:

Kicad - единственный известный мне САПР для электроники, использующий красивый текстовый формат для управления всеми данными.

Если схема и PCB Файлы представляют собой текстовые файлы, это, вероятно, хорошая идея, и у нее практически нет недостатков.

Двоичные файлы

Однако, если это двоичные файлы, это зависит от обстоятельств. Вне всяких сомнений, все файлы "худшего случая" для git:

• большой по размеру
• высокая энтропия (небольшое логическое изменение вызывает большие изменения в файле, например сжатие / шифрование)
• часто меняющийся

Если у вас все три типа файла, то git сильно потеряет эффективность. В противном случае git обычно нормально обрабатывает двоичные файлы.

Командный рабочий процесс

В статье, которую вы связали, также рассказывается о некоторых дополнениях для обработки острых углов:

• настройка gitignore
• clean/smudge игнорировать нелогичный файл проекта save_at даты
• схематическая диффузность

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

Затратить эти усилия сейчас означает автоматизировать рабочий процесс и предотвратить будущие головные боли - вам придется взвесить выгоду / затраты.