Eine Einführung in Git für Hardware mit Altium Designer

Einführung

Vor einigen Jahren wechselte ich vorübergehend von der Arbeit in einem hippen, überkoffeinierten Startup-Umfeld zu einem Ingenieurjob in einem erfahreneren und etablierten Unternehmen. Dabei erkannte ich die binomiale Verbindung zwischen technischer Kultur und Werkzeugen. Wie wir denken und wie wir arbeiten, wird durch die uns zur Verfügung stehenden Werkzeuge geprägt, da unsere Bedürfnisse und Bräuche die Werkzeuge beeinflussen, die wir wählen.

Das neue Unternehmen, in dem ich arbeitete, war nicht an 3D-Drucker, hausinterne Fehlerverfolgungssoftware oder sogar ein gutes CMS gewöhnt. Es war alles ziemlich altmodisch. Dies hatte einen erheblichen Einfluss darauf, was meine Kollegen und ich täglich erschufen.

Ein Beispiel wäre der Übergang der letzten Jahrzehnte von TO220-Gehäusen zu D2PAK. Gleichzeitig haben sich Ingenieure mit Hochleistungs-Lötkolben ausgestattet, wie sie beispielsweise von JBC hergestellt werden.

Würde ein junger Ingenieur, der Zugang zu einem gut ausgestatteten Labor hat, in diesem Jahrzehnt überhaupt irgendeinen beliebten IC in einem TO220 in Betracht ziehen? Ich glaube nicht. Es ist so viel einfacher, mit D2PAKs zu arbeiten und nicht mit Schrauben, Unterlegscheiben und isolierender Folie herumzufummeln, vorausgesetzt, man hat einen Lötkolben der letzten Generation. Diese einfache Änderung kann einen Ingenieur dazu veranlassen, flachere Platinen zu entwerfen, was oft zu ästhetisch ansprechenderen Produkten nach modernen Standards führen kann.

Git ist ein seltenes Beispiel für ein Werkzeug, das eine ganze Branche auf den Kopf gestellt hat. Vor zehn Jahren hätten Software-Engineering-Manager es für Wahnsinn gehalten, einen schnell bewegen und Dinge kaputt machen-Ansatz zu verfolgen. Git für Hardware- und PCB-Design hat dies durch die Ermöglichung von Revisionsverfolgung, Versionskontrolle und dem Zurückrollen von Designänderungen möglich gemacht. Entwickler sind jetzt sicher, dass ihre Bemühungen um Open-Source-Projekte immer zugeschrieben und überprüft werden können, dank einer Funktion namens Git blame. Vor einem Jahrzehnt wurde die Anerkennung für Ihren Beitrag zu Open-Source-Projekten der Politik überlassen. Das sind alles Beispiele für Veränderungen, für die wir Git danken können.

Obwohl die Elektronikindustrie von Natur aus langsamer als die Softwarebranche voranschreitet, sickern viele der Innovationen in unsere tägliche Arbeit ein. Altium Designer®, mit der Einführung von sowohl Altium 365® als auch Concord Pro™ in diesem Jahr, hat den Weg in der Branche gewiesen, wobei andere wichtige Akteure manchmal Mühe haben, mit Funktionen Schritt zu halten, die vor über einem Jahrzehnt veröffentlicht wurden. Git für Hardware- und PCB-Design ist eine der Technologien, die diesen Wandel vorantreiben.

Was ist Git?

Ganz einfach, Git ist ein Versionskontrollsystem (VCS). Es ist eine Software (einschließlich der zugrundeliegenden Protokolle und Datenformate), die von Softwareentwicklern verwendet wird, um Codeänderungen zu verfolgen und zu verwalten. Wenn Sie ein Softwareentwickler sind, der in diesem Jahrzehnt arbeitet, duplizieren Sie keine Ordner auf Ihrem Desktop, um Dinge auszuprobieren, Sie verwenden höchstwahrscheinlich ein auf Git basierendes VCS.

Obwohl Git massiv beliebt ist, um Codeänderungen in der Softwareentwicklung zu verfolgen, kann es verwendet werden, um Änderungen an jedem Dateiensatz zu verfolgen. Diese Dateien müssen keinen Code enthalten, sie können Ihre PCB-Design-Dateien, Design-Dokumentation, PCB-Fertigungsdateien und alle anderen Dateien sein, die Sie für Ihr Projekt benötigen. Git für Hardware ist eine natürliche Erweiterung des Git-Ökosystems für mechanisches Design, PCB-Design, Firmware und vieles mehr.

Git ist frei verfügbar für kommerzielle Nutzung. Es ist Open-Source und unter der GNU General Public License vertrieben. Jedes Git-Verzeichnis ist eine separate Einheit und ist selbst ein Repository, das eine vollständige Historie seiner Elemente enthält. Jede Datei, die in ein Git-Repository platziert wird, ist vollständig nachverfolgbar bis auf jedes Bit, von wem und wann. Git-Repositories benötigen keinen Netzwerkzugang, wobei jedes Repository völlig unabhängig von den Server(n) ist, die den Namen Remote(s) tragen.

Es sollte daher nicht überraschen, dass es derzeit das weltweit beliebteste VCS ist. Die meisten Marktanteilsanalysen zeigen Git über 75%, und die beliebteste Alternative, SVN, ist seit 2012 im Rückgang. Die Anzahl der Stellenangebote, die SVN erfordern (ein Legacy-VCS, das auch von Altium Designer unterstützt wird) ist ebenfalls rückläufig, während Git an Beliebtheit gewinnt.

Geschichte von Git

Git wurde 2005 von Linus Torvalds, dem Mann, der Legende, dem Schöpfer und Entwickler des Linux-Kernels, erstellt und geschrieben, um die Entwicklung des eigenen Kernels zu verfolgen. Die Linux-Gemeinschaft hatte die kostenlose Nutzung einer kommerziellen Software namens BitKeeper erhalten. Im April 2005 zog der Autor von BitKeeper die Lizenz zurück, nachdem ein prominentes Mitglied des Linux-Teams und Erfinder des Samba-Dateiservers, Andrew Tridgell, begonnen hatte, an einem Open-Source-Client zu arbeiten, der auf dem (angeblich) reverse-engineerten BitKeeper-Protokoll basierte. Die BitKeeper-Lizenz verbietet ausdrücklich das Reverse-Engineering.

Daher entschied sich Linus Torvalds, sein eigenes Versionskontrollsystem zu erstellen, das nicht so locker von BitKeeper inspiriert war, da keine der verbleibenden Alternativen seinen Anforderungen auch nur nahe kam.

Torvalds entschied, dass die neue Software sehr unterschiedlich von den damals verwendeten CVS (Concurrent Version Systems) sein würde. Er erkannte, dass aktuelle Systeme lange brauchen könnten, um Patches anzuwenden, und da er hunderte von Patches gleichzeitig anwenden musste, wenn er sich mit seinem Team synchronisierte, war deren Leistung weit von akzeptabel. Er stellte eine Reihe von Anforderungen auf:

• Ein verteilter Workflow ähnlich dem, was BitKeeper ermöglichte. Der Benutzer sollte in der Lage sein, offline zu arbeiten und später zu synchronisieren.
• Schutz vor Unfällen wie Datenkorruption
• Sicher vor bösartigen Angriffen
• In der Lage sein, Patches in weniger als zwei Sekunden zu berechnen

Die Arbeit an Git begann Anfang April 2005. Am 16. Juni 2005 wurde Version 2.6.12 des Linux-Kernels veröffentlicht, der Grund, warum die Software in Eile benötigt wurde. Die Entwicklung und Wartung von Git wurden dann an Junio Amano übergeben, der einen Beitrag geleistet hat und immer noch zur Entwicklung beiträgt und weitgehend dafür anerkannt wird, die Software benutzerfreundlich gemacht zu haben; Git 1.0 wurde im Dezember 2005 veröffentlicht.

Namenskonvention

Warum Git? Ein seltsamer Name, gelinde gesagt! Wie die meisten Menschen im Vereinigten Königreich wissen, wird der Begriff oft jemandem gegeben, der ein wenig frech ist oder, laut dem Oxford Online Dictionary, "eine unangenehme oder verachtenswerte Person". Weitere berichtete Bedeutungen sind "Narr" (Slang des 18. bis 19. Jahrhunderts (UK)) oder "Bastardkind" (Slang Mitte des 18. bis 19. Jahrhunderts (US)), beides würde ziemlich poetisch in seinen Mythos des einsamen genialen Eremiten passen, der sich versteckt, um ein Kunstwerk zu erschaffen, das die Welt verändern würde.

Torvalds hat mehrere Gründe für die Benennung seines Systems "Git" angegeben, die je nach Gefühlslage des Benutzers am Tag oder wahrscheinlich, wie er sich zu verschiedenen Zeiten beim Schreiben des Systems gefühlt hat, gewählt werden sollen! Er beschreibt es oft als "den dummen Inhaltsverfolger" in der offiziellen Dokumentation, und die Definition von Git als:

• "Eine zufällige Kombination von 3 Buchstaben, die nicht ausgesprochen werden kann".
• Eine Fehlaussprache von "get"!
• Globaler Informationsverfolger, wenn es nach Plan funktioniert
• Dumm, verachtenswert und abscheulich, wenn es nicht funktioniert.

Oh, Programmiererhumor.

Nachteile

Git ist jedoch nicht perfekt und hat einige Nachteile. Die schwer zu begreifende Datenstruktur und die seltsame Nomenklatur gehören zweifellos dazu. Dies schließt Git für Hardwareprojekte ein, bei denen dieselbe Dateistruktur und Operationen erzwungen werden.

Cherry-Picking, Checkout, Index, Clone, Push, Stash, Pull/Pull Request, Tag, Upstream, Fork, Rebase, Origin, Fetch und HEAD (immer in Großbuchstaben geschrieben, ich habe keine Ahnung warum) gehören zu einigen der seltsamsten Begriffe, die man in der Softwarewelt finden kann.

Es kann schwierig sein zu verstehen, wie man ein Repository als serverseitige Software einrichtet und die Beziehung zwischen lokalen und entfernten Repositories sowie die Operationen, um sie synchron zu halten, zu verstehen. Git ist tendenziell viel komplexer zu erlernen und zu verwenden als SVN, teilweise weil es viel leistungsfähiger und effizienter ist.

Glücklicherweise kümmern sich Altium Designer und Concord Pro um die meisten dieser Probleme. Während wir vollen Zugriff auf die Leistung von Git über die Befehlszeile haben, machen die Benutzeroberfläche und die strikte Integration von Concord Pro die Bedienung einfach und intuitiv. Gleichzeitig kümmert sich Altium 365 um alle serverseitigen Probleme.

Wie funktioniert Git für Hardware?

Git kann als... sehr eigenartig erscheinen! Die Nomenklatur spiegelt hauptsächlich einen Arbeitsablauf wider, der sich erheblich von dem klassischen Kopieren-Einfügen, Zippen und E-Mails unterscheidet, an die viele Ingenieure gewöhnt sind.

Verzweigung (und Zusammenführung)

Das Verzweigungsmodell ist vielleicht das beliebteste Merkmal, das Git von einem anderen VCS wie SVN unterscheidet. Git kann mehrere Zweige haben, sowohl lokal als auch entfernt. Wie der Zweig eines Baumes sich vom Stamm oder voneinander abzweigt, so sprießen Git-Zweige aus anderen Zweigen. Der "Stamm" des Baumes oder der Hauptzweig wird als Master bezeichnet. Die Zweige können leicht erstellt, zusammengeführt und gelöscht werden. Hier ist, wie diese Operationen funktionieren:

• Jeder Zweig ist unabhängig, und wenn man fernarbeitet, muss man niemandem auf die Füße treten. Man kann sogar mehrere Zweige selbst haben, jeder Zweig enthält eine leicht unterschiedliche Variation des eigenen Software- oder Hardware-Designs, und sie können im selben Verzeichnis gewechselt werden, ohne Dateien manuell schließen und wieder öffnen zu müssen.
• In der Softwarewelt ist es eine Faustregel, einen Produktionszweig, genannt der Master, und einen zweiten Arbeitszweig, genannt Entwickeln, sowie so viele kleine Zweige wie nötig für neue Funktionen und Korrekturen zu haben. Der gleiche Ansatz kann bei Hardwareprojekten angewendet werden. Tatsächlich gibt es viele GitHub-Repositories mit PCB-Designs und anderen Projekten speziell für Hardware.
• Nicht alle Zweige müssen in den Master-Zweig zusammengeführt werden. Oft stellen Entwickler fest, dass die neue Funktion doch kein Geniestreich ist, und der Zweig kann einfach gelöscht werden, wenn er nicht mehr benötigt wird.

[Nerd-Modus AN]

Wie funktioniert also dieses clevere Merkmal? Ein Zweig ist im Wesentlichen ein Zeiger auf einen Commit. Ein Commit ist eine Reihe von Dateiänderungen, Hinzufügungen oder Entfernungen, die in das Repository gepusht werden. Der Commit hat eine 40-stellige kryptografische SHA-1-Prüfsumme, die in eine Datei geschrieben wird. Jeder Commit enthält auch einen Zeiger auf den Eltern-Commit, von dem er stammt.

Es gibt viele zusätzliche Zwischenschritte, zum Beispiel werden Dateien in checksummierte Binärblobs umgewandelt und in Verzeichnissen durch einen Binärbaum organisiert. Die Prüfsumme des Baumes wird ebenfalls berechnet. Da alles kryptografisch gehasht ist, gibt es keine Möglichkeit, die Daten oder die Geschichte zu ändern (oder zu korrumpieren), ohne den Hash des letzten Commits zu ändern. Das kryptografische Hashing macht die Geschichte von Git irgendwie dauerhaft, also seid höflich beim Schreiben von Commit-Nachrichten!

[Nerd-Modus AUS]

Workflows in Git für Hardware

Dank der verteilten Natur von Git für Hardware und dem fortgeschrittenen Verzweigungssystem sowie einer Vielzahl anderer Funktionen sind Benutzer frei, jeden Workflow zu übernehmen.

Unter den beliebtesten ist das *Zentralisierte Workflow*-Modell eines, das oft verwendet wird, wenn Leute, die Erfahrung mit zentralisierten Versionskontrollsystemen haben, Git (das *dezentralisiert* ist) zum ersten Mal verwenden. Das *Zentralisierte Workflow* verlässt sich fast ausschließlich auf den Master-Zweig, wo alle Commits gepusht und gefetcht werden, was Git das Verhalten von SVN und entfernten Dateisystemen nachahmen lässt.

Der Feature Branching Workflow ist eine Weiterentwicklung des *Zentralisierten Workflows*. Die Entwicklungsarbeit wird auf separaten Branches durchgeführt, die dann in einen Master zusammengeführt werden. Ich bin ein begeisterter Befürworter dieses Modells im Bereich der Elektronikentwicklung und warte gespannt darauf, dass Altium ihre Branch-Unterstützung ankündigt, um sie nutzen zu können. Beispiele für Feature-Branches könnten „fix_current_generator_oscillation“, „upgrade_microcontroller“, „lower_power_consumption“ oder „reduce_thermal_drift“ sein.

Im GitFlow-Workflow, vielleicht der komplexeste unter den beliebten Workflows, enthält der Master-Branch nur vollständige Design-Releases, man kann ihn sich vorstellen als board_v_1.0, board_v_1.1 usw. Die Entwicklung erfolgt auf einem separaten Branch namens Develop, und Features sowie Fixes gehen vom Develop-Branch aus. Nur Develop kann in den Master eingegliedert werden, sobald es fertig ist.

Dezentralisierung und Geschwindigkeit

Git ist aus mehreren Gründen schneller als andere Versionskontrollsysteme. Jeder Benutzer kann das Original-Repository klonen, und Commits können regelmäßig zu lokalen Branches gemacht und seltener an das Remote gesendet werden. Andere VCSs, die nicht so dezentralisiert sind, werden durch die Kapazität des Remote-Servers begrenzt, der erheblich langsamer werden muss, um all ihre Anfragen zu befriedigen.

Dieser Local-First-Ansatz ist besonders wichtig in der Elektronikindustrie, da Dateien ziemlich groß sein können. Es ist nicht ungewöhnlich, dass ein PCB-Design mehrere zehn Megabyte groß ist, insbesondere mit Hunderten von 3D-Körpern. Quellcodedateien sind dagegen meist nur einige hundert KByte groß.

In der letzten Firma, für die ich gearbeitet habe, hatten wir ein SVN-Repository in den Hauptbüros, das über ein VPN zugänglich war, wo wir die Projektdateien und Dokumentation speichern würden. Jede Operation dauerte ewig, und unsere begrenzte Internetverbindung war häufig durch all die Anfragen überlastet, um die Tausenden von Dateien zu verwalten.

Git ist außerdem in der C-Sprache geschrieben, was bedeutet, dass sein Overhead im Vergleich zu anderen Hochsprachen minimal ist. Je nach Operation kann Git einige Male bis zu hunderte Male schneller sein als SVN.

Der dezentralisierte, Offline-First-Ansatz macht Git auch viel leichter für das Netzwerk. Selbst wenn Ihr Unternehmen keinen Zugang zu Breitband hat, können Sie die Daten in der Mittagspause oder nach der Arbeit pushen, ohne Leistungseinbußen bei der täglichen Arbeit.

Auf Concord Pro können Sie alle Vorteile von Altium 365 genießen, wenn Sie Zugang zu einer Internetverbindung haben, dann Ihre Altium Designer-Lizenz mitnehmen und offline weiterarbeiten.

Staging-Bereiche

Beim Arbeiten mit Git ist es wesentlich zu verstehen, dass Dateien drei Stufen durchlaufen, bevor sie tatsächlich als unter Versionskontrolle stehend betrachtet werden können:

1. Unverfolgt
2. Vorbereitet
3. Übernommen

Unverfolgt bedeutet, dass die Datei auf der Festplatte existiert, aber außerhalb des Versionskontrollsystems ist. Die unverfolgte Datei kann dann vorbereitet werden, was bedeutet, dass sie zum Versionskontrollsystem hinzugefügt wurde, aber noch nicht übernommen wurde. An diesem Punkt können die vorbereiteten Änderungen übernommen werden. Das Vorbereitungssystem wird genutzt, um sich auf die Übernahme vorzubereiten, aber dieses Feature wird hauptsächlich in der Befehlszeilenoperation verwendet.

Beim Einsatz von Git über Altium vereinfacht die grafische Benutzeroberfläche, die den Betrieb vereinfacht, den Vorbereitungsansatz, der automatisch im Hintergrund angewendet wird, wenn Sie die Änderungen auf dem Server speichern.

Erstellen eines Repositorys

Repositorys werden automatisch auf der Serverseite erstellt, wenn Sie ein neues Projekt erstellen. Im folgenden Fenster erstelle ich ein neues PCB-Projekt aus einer Vorlage innerhalb meines Fermium LTD Arbeitsbereichs. Sobald ich das Projekt erstelle, wird es in meinem Altium 365 Arbeitsbereich zugänglich sein, und die Plattform wird automatisch ein Git-Repository für das neue Projekt erstellen.

Erstkonfiguration des Repositorys

Die mit Concord Pro erstellten Repositorys werden automatisch konfiguriert, sodass nur die wesentlichen Dateien bereits im Git-Repository des Projekts übernommen wurden, während lokale Backups und LOG-Dateien nicht übernommen werden. Normalerweise wäre es notwendig, eine Datei namens ".Gitignore" entsprechend zu konfigurieren und darauf zu achten, keine unnötigen Dateien zu übernehmen, aber Concord Pro kümmert sich darum.

Einrichten von Anmeldeinformationen

Um auf Git-Repositorys zugreifen zu können, müsste man im Allgemeinen SSH-Schlüssel und Benutzeranmeldeinformationen sowohl auf der Serverseite als auch auf der Clientseite konfigurieren. Concord Pro kümmert sich automatisch darum, wenn ein neuer Benutzer hinzugefügt wird.

Klonen von Repositories

Klonen ist der Prozess, durch den Git ein entferntes Repository in eine lokale Kopie repliziert. Das manuelle Klonen großer Repositories mit Binärdateien, wie PcbDoc- und SchDoc-Dateien, würde normalerweise eine expertenmäßige Bedienung von Git über die Befehlszeile erfordern. Altium Designer und Concord Pro klonen das Repository automatisch im Hintergrund auf Ihren lokalen Rechner, wenn Sie ein entferntes Projekt öffnen.

Konflikte lösen und Änderungen vergleichen

Concord Pro ermöglicht es Ihnen, Änderungen zwischen verschiedenen Revisionen, sowohl lokal als auch entfernt, über das Speichermanager-Panel zu vergleichen. Im folgenden Beispiel habe ich ein Textnotizobjekt hinzugefügt und die Änderungen lokal committet, sie aber nicht auf das Remote gepusht.

Dies gibt uns die komplette Funktionalität, die auf einer Git-Plattform für Hardware benötigt wird.

Schlussfolgerungen

Git ist ein mächtiges Werkzeug, und Git für Hardware bietet PCB-Designern einen umfassenden Workflow für Versionskontrolle, Teilen und Revisionsmanagement. Dieses beliebte System hat die Kultur moderner Programmierer geprägt. Jetzt können Designer mit Altium Designer® und der Altium 365® Plattform auf Git-Funktionen für PCB-Design zugreifen.

Sie können heute eine Testversion von Altium 365 starten, die mit Beispielprojekten geladen ist, um die elektronische Entwicklung im Stil des 21. Jahrhunderts vollständig zu erleben. Haben Sie weitere Fragen? Sprechen Sie noch heute mit einem Experten bei Altium.