Warum ist Git so zentral für DevOps?
Git ist ein verteiltes Versionskontrollsystem, das jede Änderung an Dateien nachvollziehbar speichert. In DevOps dient Git als Single Source of Truth — nicht nur für Anwendungscode, sondern auch für Infrastrukturdefinitionen, Pipeline-Konfigurationen und Policies.
Versionsverwaltung in der Industrial ITGit ist ein verteiltes Versionskontrollsystem, das den Verlauf von Dateien als Abfolge unveränderlicher Snapshots speichert. Verteilt bedeutet, dass jede Arbeitskopie die vollständige Historie enthält — anders als bei zentralen Systemen kann jeder Entwickler offline committen, branchen und vergleichen. Jeder Commit ist über einen kryptografischen Hash eindeutig identifiziert, was die Historie manipulationssicher und lückenlos nachvollziehbar macht.
In DevOps ist Git mehr als ein Werkzeug für Anwendungscode. Es wird zur Single Source of Truth für alles, was als Text beschreibbar ist: Infrastruktur als Code, Pipeline-Definitionen, Kubernetes-Manifeste, Policies und Konfiguration. Dieses Prinzip ist die technische Grundlage für GitOps, bei dem der gewünschte Systemzustand allein über das Git-Repository gesteuert wird.
Für regulierte Industrien ist die Git-Historie ein wertvolles Audit-Artefakt. Wer hat was wann und warum geändert — diese Frage beantwortet Git lückenlos über Commit-Metadaten, Signaturen und Pull-Request-Diskussionen. Standards wie ASPICE oder IEC 62443, die Nachvollziehbarkeit von Änderungen verlangen, profitieren davon unmittelbar. Über Branch-Schutzregeln und obligatorische Reviews lässt sich zudem das Vier-Augen-Prinzip technisch erzwingen.
Ein verbreitetes Missverständnis ist, Git mit der Plattform darum herum gleichzusetzen. Git ist das zugrundeliegende System; GitHub, GitLab und Azure DevOps sind Plattformen, die Git um Hosting, Issue-Tracking, CI/CD und Berechtigungen erweitern. Im Industrieumfeld kommt hinzu, dass binäre Artefakte wie kompilierte Firmware oder TIA-Portal-Projekte besondere Behandlung brauchen — etwa über Git LFS oder dedizierte Versionierungsschnittstellen.
SPS-Code unter Versionskontrolle
Ein Maschinenbauer versioniert TIA-Portal-Projekte über das Version Control Interface in Git. Jede Änderung an einer SPS-Steuerung ist damit nachvollziehbar, vergleichbar und reviewbar — statt als undokumentierte Datei auf einem Netzlaufwerk zu liegen.
Vier-Augen-Prinzip per Branch-Schutz
Ein Automotive-Zulieferer schützt den Hauptbranch so, dass kein Commit ohne mindestens ein genehmigtes Review hineingelangt. Das nach Norm geforderte Vier-Augen-Prinzip ist damit technisch durchgesetzt statt nur prozessual vereinbart.
- Was ist der Unterschied zwischen Git und GitHub?
- Git ist das verteilte Versionskontrollsystem selbst, das lokal auf jedem Rechner läuft. GitHub, GitLab oder Azure DevOps sind Plattformen, die Git-Repositories hosten und um Funktionen wie Pull Requests, Issue-Tracking, Berechtigungen und CI/CD erweitern.
- Wie versioniere ich binäre Industrie-Artefakte wie Firmware oder SPS-Projekte?
- Für große Binärdateien eignet sich Git LFS, das die Dateien außerhalb der Git-Historie ablegt und nur Verweise speichert. Für proprietäre Formate wie TIA-Portal-Projekte gibt es zusätzlich dedizierte Schnittstellen wie das Version Control Interface, das den Code in textbasierte, versionierbare Form überführt.
- Warum gilt Git als Single Source of Truth in DevOps?
- Weil sich alles als Text beschreiben lässt — Code, Infrastruktur, Pipelines, Konfiguration — in einem System landet, das jede Änderung nachvollziehbar speichert. Daraus ergibt sich ein konsistenter, auditierbarer Zustand, auf dem GitOps und automatisierte Prozesse aufsetzen können.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance