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.
Ist Git bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Git 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.
Git ist inzwischen über 20 Jahre alt — Linus Torvalds veröffentlichte die erste Version 2005 — und faktisch konkurrenzlos: In der Stack-Overflow-Entwicklerumfrage nutzen es seit Jahren über 90 Prozent der Befragten. Die Weiterentwicklung zielt heute weniger auf neue Grundfunktionen als auf Skalierung und Integrität: Partial Clone und Sparse Checkout machen auch Monorepos mit Millionen Dateien handhabbar, und der schrittweise Umstieg vom Hash-Verfahren SHA-1 auf SHA-256 härtet die Historie gegen Manipulation.
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 in Ordnern im Stil von „Final_V2_neu_wirklich" auf dem Netzlaufwerk zu liegen. Fast jeder Maschinenbauer startet genau dort; das ist kein Versäumnis, sondern der übliche Ausgangspunkt.
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 Git einfach erklärt?
- Git ist ein Versionskontrollsystem: Es speichert den Zustand eines Projekts als Kette von Snapshots, sodass jede Änderung nachvollziehbar bleibt und sich jeder frühere Stand wiederherstellen lässt. Mehrere Personen arbeiten parallel in Branches und führen ihre Stände kontrolliert zusammen — die Grundlage praktisch jeder modernen Softwareentwicklung.
- 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.
- Was ist der Unterschied zwischen Git und GitLab?
- Git ist das Versionskontrollsystem selbst — ein Kommandozeilenwerkzeug, das lokal auf jedem Rechner läuft. GitLab ist eine Plattform, die Git-Repositories hostet und um Zusammenarbeit erweitert: Merge Requests, CI/CD-Pipelines, Issue-Tracking, Container-Registry. Dasselbe Verhältnis gilt für GitHub und Bitbucket — alle drei bauen auf Git auf, ersetzen es aber nicht.
- Was ist der Unterschied zwischen Git und SVN?
- SVN (Subversion) arbeitet zentral: Es gibt genau ein Repository auf einem Server, ohne Verbindung dorthin geht wenig. Git ist verteilt — jede Arbeitskopie enthält die komplette Historie, Branches sind leichtgewichtig und lokal. In der Praxis hat Git SVN weitgehend abgelöst; Migrationsbedarf besteht vor allem noch in älteren Industrie-Codebasen.
Wo steht Ihr Team bei Git?
Uns interessiert, wo Ihr Team bei diesem Thema steht. Auf Basis Ihrer Antwort schlagen wir Ihnen den sinnvollsten nächsten Schritt vor — ganz ohne Formular.
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