Większość sprowadza się do osobistych preferencji.
Śledzę wszystko, co robię dla projektu w Git. Zwłaszcza, że Git obsługuje wystarczająco dużo plików, nawet binarnych, z wystarczającą wydajnością. (Zamiast wbudowanych bzdur Altium SVN)
Jednym z moich głównych powodów jest to, że moi klienci nie wszyscy uważają, że Dropbox jest wystarczająco bezpieczny i potrzebuję systemu tworzenia kopii zapasowych, do którego mogę uzyskać dostęp na całym świecie, a także kontekst wersji dla większości moich działań. Więc skonfigurowałem prywatny serwer Git i zaszyfrowany system tworzenia kopii zapasowych i działa to uczta. Tablice, Schematy, Kod, Dokumentacja, Raporty, Ręczne modyfikacje, wszystko jest śledzone.
Zwykle tworzyłbym repozytorium dla sprzętu, jeden dla oprogramowania i jeden dla oprogramowania układowego, jeśli jest to duży, potencjalnie długotrwały projekt, ale dla małych projektów usługowych, przykładów lub małych eksperymentów często umieszczam to wszystko w jednym repozytorium, ponieważ wynikowe chaos nie będzie duży.
W Git możesz także używać sub-repozytoriów, aby zintegrować oprogramowanie układowe z projektem Hardware lub odwrotnie, nawet jeśli są to osobno zarządzane repozytoria.
W większych projektach często używam również systemów śledzenia błędów, aby śledzić problemy i rozwiązania, ponownie, zarówno dla HW, jak i SW, Mantis jest fajny, z którego można korzystać za darmo.
W przypadku poprawek sprzętowych generuję Gerbera lub cokolwiek innego, oznaczonego tagiem Git Hash dla tej wersji, te Gerbery są wówczas jedynymi dyskretnymi „staroświeckimi” wersjami w folderach według R01, 02 itd. Ponieważ nie chcesz generuj je cały czas, ale są to pliki wynikowe, więc nie powinno być wersjonowane w samym Git, naprawdę (ponieważ twoje oprogramowanie do projektowania powinno być deterministyczne przy generowaniu zawartości produkcyjnej, bo inaczej ...).
Jeśli w R01 jest coś interesującego, co nie dzieje się w R02 (lub na odwrót), masz dwa Git Hashe, z którymi możesz porównywać pliki źródłowe, nie martw się.
Na koniec, jednym koncepcyjnym przykładem projektu, byłoby repozytorium sprzętu, które również zawiera plik „BoardPinout.h”. Ten plik jest dołączany jako plik z wersją zdalną do repozytorium oprogramowania układowego, który zawiera kilka plików definicji interfejsu, które są zdalnie dołączane do repozytorium oprogramowania.
Oznacza to, że za każdym razem, gdy zmieniam kilka sygnałów bez modyfikowania szerokiej funkcjonalności, projekt HW „aktualizuje” BoardPinout, który następnie może być aktualizowany i używany w oprogramowaniu sprzętowym i tak dalej.