Git, Versionskontrolle für Hardware/Firmware

[Mat. K. (matthias_kornfield)]

Hi
ich bin gerade dabei ein neues HW projekt/Firmware aufzusetzen.
Firmware wird ein repo und hardware ein 2tes repo.
Aber was benutze ich um die beiden repos mit einander zu versionieren?
Nimmt der Experte heutzutage submodule?
Mein Fw repo ist eher 50 MByte gross, Hardware wird womöglich 5-6 
Revisionen haben, ist ein Bluetooth module mit paar einfachen Sensoren.

Danke

[M. Н. (Gast)]

Mat. K. schrieb:
> Firmware wird ein repo und hardware ein 2tes repo.

Macht Sinn. Alles was getrennt Versionsnummern bekommen kann, also HW 
v1.2.3 und SW v1.5.6 sollte auch getrennt versioniert werden. Sonst 
macht das früher oder später keinen Spaß. Und Repos kosten ja nichts.

Mat. K. schrieb:
> ber was benutze ich um die beiden repos mit einander zu versionieren?
> Nimmt der Experte heutzutage submodule?

Da habe ich schon verschiedene Dinge gesehen. Unter anderem tatsächlich 
Submodule:

Also:
gerät_pcb_repo (Aktueller Release Tag v1.0)
gerät_firmware_repo (Aktueller Release Tag v0.4)

und dann ein

mein_lustiges_produkt_repo (Stand v0.1)
Mit den Submodulen
 * gerät_pcb_repo (v1.0)
 * gerät_firmware_repo (v0.4)
 * pc_software (v1.0)

Dadurch ist die Kette ersichtlich, dass in Produkt v0.1 Firmware v0.4 
und HW v1.0 verbaut sind.

Diesen Weg habe ich selbst schon benutzt und finde ihn okay. Submodule 
sind halt von der Nutzung her bisschen komisch. Da kommen vorallem nicht 
git-affine schnell mal an die Grenze, vorallem, wenn sie reine 
GUI-Klicker sind.
Funktioniert aber auch nur, wenn die komplette Kette git verwendet und 
nicht die softwerker git die Harwerker SVN und die Leute, die die Doku 
schreiben ein Tauschlaufwerk mit _neu_neu_datum_v3.docx Dateien bauen...

Anderer Weg, wie das in großen Firmen* läuft:

Da hat eh jedes Produkt in SAP ne Stückliste. Und in dieser SAP 
Stückliste sind dann die referenzen auf die Firmware / Hardware drin. 
Als Entwickler blutet einem halt immer ein wenig das Herz, wenn man SAP 
sieht... Aber so läuft das bei vielen Firmen.

* In diesem Fall: große Firma = groß genug, dass man SAP an der Backe 
hat.

[J. S. (jojos)]

geht auch ohne SAP, HW und SW sind Artikel und bei der HW wird der 
nötige Mindeststand der SW hinterlegt. Im Idealfall sollte neue SW auch 
mit alter HW zurecht kommen, also möglichst irgendeine Identifikation 
einbauen.
Damit hängt auch die Frage zusammen wo werden binäre Brocken die mehrere 
MB oder zig MB groß sind abgelegt? Unser git Betreuer meckert über große 
Binärdateien im git, die passen zwar auf den Server, machen gitlab aber 
lahm.

[Mat. K. (matthias_kornfield)]

Vielen Dank.
Sehe ich richtig:
ich kann auch erst HW/Firmware/software repo anlegen und erst 2-3 Monate 
später mich um den repo mit den submodulen kummern?
Also mein_lustiges_produkt_repo kann auch später erstellt werden. Der 
ist ja unabhängig vom rest.

[M. Н. (Gast)]

Mat. K. schrieb:
> 2-3 Monate
> später mich um den repo mit den submodulen kummern?

Ja. Kannst du machen.

[Ein T. (ein_typ)]

Mat. K. schrieb:
> Vielen Dank.
> Sehe ich richtig:
> ich kann auch erst HW/Firmware/software repo anlegen und erst 2-3 Monate
> später mich um den repo mit den submodulen kummern?
> Also mein_lustiges_produkt_repo kann auch später erstellt werden. Der
> ist ja unabhängig vom rest.

Klar, das geht. Worauf Du allerdings ein wenig achten solltest, ist, daß 
Git alleine nicht so richtig gut für Binärdat(ei)en geeignet ist, dazu 
empfiehlt sich die Erweiterung "Git Large File Storage" oder kurz "git 
lfs". Viel Spaß und Erfolg! :-)

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Mat. K. schrieb:

> Firmware wird ein repo und hardware ein 2tes repo.

Warum? Kann die Hardware auch mit anderer Firmware verwendet werden oder 
kann die Firmware auch auf anderer Hardware laufen?

> Aber was benutze ich um die beiden repos mit einander zu versionieren?

Im einfachsten Fall, nutzt Du nur ein Repo.

> Nimmt der Experte heutzutage submodule?

Der Experte nimmt, was die Anforderungen am besten / einfachsten 
erfüllt.

Selbst wenn Du mit einem Submodul exakt den Commit festlegen kannst / 
willst, der für exakt eine Version der Hardware gedacht ist, kannst Du 
das ja organisatorisch garnicht umsetzen. Wozu also dieses Verschränkung 
der Versionen, wenn Du die danach nicht umsetzen kannst?

[Jörg (Gast)]

Torsten R. schrieb:
>> Firmware wird ein repo und hardware ein 2tes repo.
>
> Warum? Kann die Hardware auch mit anderer Firmware verwendet werden oder
> kann die Firmware auch auf anderer Hardware laufen?
>
>> Aber was benutze ich um die beiden repos mit einander zu versionieren?
>
> Im einfachsten Fall, nutzt Du nur ein Repo.

Das habe ich schon einmal ausprobiert und für mich funktioniert es 
überhaupt nicht. Sobald mehr als reines Fast-Forward Committen notwendig 
war ist es sehr unübersichtlich geworden ohne einen Mehrwert 
beizutragen.

In (meiner) Realität sind Hard und Software zwei unterschiedliche 
Entwicklungsstränge die lediglich die gegenseitige Minimalversion als 
Anforderung haben. Meine Lösung ist es hier, die beiden Repos über Tags 
lose miteinander zu verbinden.

Wenn es unbedingt ein einzelnes Repo sein soll, könnte man einen Orphan 
Branch nutzen; hier sehe ich allerdibngs wieder keinen Vorteil gegenüber 
zweier Repos.

[Vincent H. (vinci)]

Ein T. schrieb:
> Klar, das geht. Worauf Du allerdings ein wenig achten solltest, ist, daß
> Git alleine nicht so richtig gut für Binärdat(ei)en geeignet ist, dazu
> empfiehlt sich die Erweiterung "Git Large File Storage" oder kurz "git
> lfs". Viel Spaß und Erfolg! :-)

Vor ein paar Jahren hätte ich das noch für Satire gehalten, mittlerweile 
legen einige CAD Programme wie etwa das von mir tief gehasste Altium 
derart viel Mist ab, dass man glauben könnte es handle sich dabei um LLM 
Trainingsdaten...

[Max P. (eizo)]

Ich handhabe das auch mit submodulen, ist aus meiner Sicht der sauberste 
Weg vor allem wenn die Projekte größer werden.
Neben HW und SW habe ich dann auch noch ein submodule für Mechanik, z.B. 
CAD Daten für ein Gehäuse das im 3D Drucker erstellt wird.

Hauptprojekt
- Submodule SW
- Submodule HW
- Submodule ME