Warum ist Git so zentral für DevOps?
Git ist ein verteiltes Versionskontrollsystem, das jede Änderung an Dateien nachvollziehbar speichert. In DevOps ist Git die Single Source of Truth für Anwendungscode, Infrastrukturdefinitionen, Pipeline-Konfigurationen und Policies.
Auch bekannt als: Git-Versionsverwaltung · Versionskontrolle mit Git · Git-Repository
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 speichert ein Projekt als Kette von Snapshots. Mit git add wählen Sie die geänderten Dateien aus, mit git commit legen Sie den Stand als neuen Snapshot ab. Jeder Commit bekommt eine Prüfsumme, die aus Inhalt und Vorgänger berechnet wird. Ändert jemand nachträglich einen alten Stand, passen alle folgenden Prüfsummen nicht mehr, und die Manipulation fällt auf. Branches sind nur Zeiger auf einen Commit, deshalb kostet ein neuer Branch praktisch nichts. Mit git merge führen Sie die Stände wieder zusammen.
Verteilt heißt, dass jede Arbeitskopie die vollständige Historie enthält. Sie committen, branchen und vergleichen offline und tauschen Stände erst mit git push und git pull mit einem gemeinsamen Repository aus. Ältere zentrale Systeme wie SVN brauchen dafür eine ständige Verbindung zum Server. Git ist dabei das Werkzeug selbst. GitHub, GitLab und Azure DevOps sind Plattformen, die Git-Repositories hosten und um Pull Requests, Issue-Tracking, Berechtigungen und CI/CD ergänzen.
In DevOps verwaltet Git mehr als Anwendungscode. Alles, was sich als Text beschreiben lässt, liegt im Repository: Infrastruktur als Code, Pipeline-Definitionen, Kubernetes-Manifeste, Policies und Konfiguration. Git wird damit zur Single Source of Truth, und GitOps baut darauf auf, indem ein Agent den Systemzustand aus dem Repository ableitet.
Für regulierte Industrien ist die Historie ein Audit-Artefakt. Wer hat was wann und warum geändert, beantworten Commit-Metadaten, signierte Commits und die Diskussion im Pull Request. Branch-Schutzregeln mit Pflicht-Review setzen das Vier-Augen-Prinzip technisch durch, das Normen wie ASPICE und IEC 62443 verlangen. Schwieriger sind binäre Artefakte wie kompilierte Firmware oder TIA-Portal-Projekte. Große Binärdateien gehören in Git LFS, für TIA Portal überführt das Version Control Interface Bausteine in versionierbare Textdateien.
Linus Torvalds veröffentlichte Git 2005 für die Entwicklung des Linux-Kernels. In der Stack-Overflow-Entwicklerumfrage 2022 gaben über 93 Prozent der Befragten an, Git zu nutzen. Die Entwicklung zielt heute auf Skalierung und Integrität. Partial Clone und Sparse Checkout machen Monorepos mit Millionen Dateien handhabbar, und für Git 3.0 ist SHA-256 als Standard-Hashverfahren für neue Repositories angekündigt, weil SHA-1 praktisch angreifbar ist. Einen Termin für Git 3.0 gibt es noch nicht, und GitHub unterstützt SHA-256-Repositories bislang nicht.
SPS-Projekt verlässt den Ordner „Final_V2_neu_wirklich"
Bei einem Maschinenbauer lagen TIA-Portal-Projekte in Ordnern auf dem Netzlaufwerk, unterschieden nur durch Datum und Namenszusätze. Welcher Stand auf welcher Anlage lief, wusste der Kollege, der zuletzt dort war. Heute versioniert das Team die Projekte über das Version Control Interface in Git. Jede Änderung an der Steuerung hat einen Commit mit Autor, ist vergleichbar und geht vor dem Einspielen durch ein Review.
Kein Commit ohne zweite Unterschrift im Hauptbranch
Ein Automotive-Zulieferer dokumentierte das Vier-Augen-Prinzip bisher in einer Prozessbeschreibung, die niemand prüfte. Heute schützt eine Branch-Regel den Hauptbranch, und ohne mindestens ein genehmigtes Review lässt sich nichts mergen. Im Assessment zeigt das Team die Regel und die Review-Historie statt der Prozessbeschreibung.
Wofür setzen Sie Git als Nächstes ein?
Git ist die Grundlage jeder Automatisierung — spannend wird es dort, wo es bislang fehlt: bei SPS-Projekten, Konfiguration oder im Team-Workflow. Zwei Klicks zeigen den passenden Weg.
Wofür wollen Sie Git vor allem nutzen?
- 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. Das ist 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, Bitbucket oder Azure DevOps sind Plattformen, die Git-Repositories hosten und um Pull Requests, Issue-Tracking, Berechtigungen und CI/CD erweitern. Git funktioniert ohne diese Plattformen, die Plattformen ohne Git nicht.
- Wofür steht die Abkürzung Git?
- Git ist keine offizielle Abkürzung. Linus Torvalds wählte laut README eine aussprechbare Kombination aus drei Buchstaben, die kein gängiger Unix-Befehl belegte; im britischen Slang heißt git so viel wie Dummkopf. Die Auflösung „global information tracker" steht in derselben README als Scherz, gedacht für die Tage, an denen Git funktioniert.
- Was ist der Unterschied zwischen Git und SVN?
- SVN (Subversion) arbeitet zentral mit genau einem Repository auf einem Server, ohne Verbindung dorthin geht wenig. Git ist verteilt, jede Arbeitskopie enthält die komplette Historie, und Branches sind leicht und lokal. In der Praxis hat Git SVN weitgehend abgelöst; Migrationsbedarf gibt es vor allem noch in älteren Industrie-Codebasen.
- Wie versioniere ich binäre Industrie-Artefakte wie Firmware oder SPS-Projekte?
- Große Binärdateien legen Sie mit Git LFS ab, das die Dateien außerhalb der Git-Historie speichert und im Repository nur Verweise hält. Für proprietäre Formate wie TIA-Portal-Projekte gibt es eigene Schnittstellen wie das Version Control Interface, das Bausteine in textbasierte, versionierbare Dateien überführt.
- Warum gilt Git als Single Source of Truth in DevOps?
- Weil alles, was sich als Text beschreiben lässt, in einem System landet, das jede Änderung nachvollziehbar speichert: Code, Infrastruktur, Pipelines, Konfiguration. Daraus ergibt sich ein konsistenter, auditierbarer Zustand, auf dem GitOps und automatisierte Deployments aufsetzen.
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.
Weiterführende Primärquellen zu Git: Normtexte, Hersteller- und Projektdokumentation. Alle Ziele öffnen in einem neuen Tab.
- /01git-scm.comGit Documentation(externe Seite, öffnet in neuem Tab)
Offizielle Referenz aller Kommandos plus Video-Einstieg.
- /02Scott Chacon und Ben StraubPro Git (deutsche Ausgabe)(externe Seite, öffnet in neuem Tab)
Das vollständige Standardwerk auf Deutsch, frei lesbar von Grundlagen bis Interna.
- /03GitHub DocsAbout Git(externe Seite, öffnet in neuem Tab)
Kompakter Einstieg in Repository, Branch, Merge und Remote.
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