TIA Portal mit Git
versionieren.
GitHub, GitLab & CI/CD.
TIA-Portal-Code wird mit Git versioniert, indem man die Bausteine als mergefähigen Quelltext (LAD/FBD/SCL, XML, AWL) exportiert und diesen Export in Git verwaltet — nicht die binäre .ap-Projektdatei. Dafür gibt es zwei Wege: das ab V18 integrierte Version Control Interface (VCI) und die skriptbasierte Openness-API. So entstehen echte Diffs, Branches und Code-Reviews. GitHub und GitLab eignen sich gleichermaßen; GitLab/GitHub Actions bringen CI/CD für Export-Konsistenz und PLCSim-Tests gleich mit. CODESYS bietet mit „CODESYS Git“ eine integrierte Alternative.
Warum SPS-Code selten in Git liegt
Steuerungsprojekte für SPS/PLC wachsen über Jahre, oft ohne Versionskontrolle. Der Grund ist technisch: Das TIA-Portal-Projekt ist ein Binärformat. Legt man die .ap-Datei in Git, kann das System sie zwar speichern, aber nicht diffen oder mergen — zwei parallele Änderungen enden im unauflösbaren Konflikt.
Die Folge: Versionsstände als Projekt_final_v3_NEU.zip auf Netzlaufwerken, kein Audit-Trail, keine nachvollziehbare Änderungshistorie — ein Problem für ASPICE, IEC 62443 und jede Funktionssicherheits-Argumentation. Genau hier setzt unser Anwendungsfall: CI/CD für SPS/PLC im Maschinenbau an — von der versionierbaren Codebasis bis zur durchgängigen Pipeline.
Drei Wege, SPS-/PLC-Code in Git zu bekommen
Alle drei Wege versionieren denselben textuellen Quelltext — sie unterscheiden sich im Integrationsgrad und im Aufwand. Welcher passt, hängt von TIA-Version, Team-Know-how und gewünschter CI/CD-Tiefe ab.
Version Control Interface (VCI)
Integriert im TIA Portal, Bedienung per Drag & Drop, ab V21 diff-fähiger LAD/FBD/SCL-Export. Wenig Skriptaufwand — erste Wahl für neue Projekte.
TIA Openness (Skript)
Maximale Flexibilität über eigene Export-/Import-Skripte und Naming-Konventionen. Unabhängig von der VCI-Roadmap, ideal für tiefe CI/CD-Integration und Custom-Toolchains.
Spezialwerkzeuge (octoplant, Copia)
Nutzen Git unter der Haube und liefern PLC-spezifische Diffs über mehrere Hersteller hinweg — sinnvoll, wenn Siemens, Rockwell und Beckhoff parallel laufen.
TIA Portal über Openness an Git anbinden
Der skriptbasierte Weg über die TIA-Openness-API — maximale Flexibilität für Custom-Toolchains und tiefe CI/CD-Integration, auch für ältere TIA-Versionen.
Openness-API aktivieren
Im TIA Portal die TIA Openness-Schnittstelle installieren und den Benutzer zur Gruppe „Siemens TIA Openness" hinzufügen. Ab TIA Portal V17 ist Openness Bestandteil der Installation.
Projekt als Quelltext exportieren
Bausteine (FB, FC, DB) und PLC-Tags per Openness-Skript als XML bzw. SCL/AWL exportieren. Nur der textuelle Export ist mergefähig — die binäre .ap-Datei gehört nicht ins Git.
Git-Repository strukturieren
Pro Steuerung ein Verzeichnis, Bausteine als einzelne Quelltext-Dateien. Eine .gitignore schließt Binär-Artefakte, Cache und Kompilate aus. Aussagekräftige Commit-Messages je Funktionsänderung.
Round-Trip absichern
Re-Import per Openness-Skript automatisieren und gegen das Original diffen, damit der Export/Import verlustfrei bleibt. So wird der Git-Stand zur verbindlichen Quelle.
CI/CD-Pipeline anbinden
In Jenkins oder GitLab CI bei jedem Commit Export-Konsistenz prüfen, PLCSim-Smoke-Tests fahren und Engineering-Backups als signierte Artefakte ablegen — IEC-62443-konform.
Der integrierte Weg: das VCI
Das Version Control Interface (VCI) ist Siemens’ integrierte Brücke zwischen TIA-Portal-Engineering und Git. Ab V18 ist es Bestandteil des TIA Portal; ab V16 gibt es den VCI Git Connector als Add-In. Man arbeitet mit einem Workspace direkt im Engineering — ohne eigene Export-Skripte.
VCI-Workspace anlegen
Im TIA Portal über die Projektnavigation einen Version-Control-Interface-Workspace erstellen und mit einem lokalen Windows-Verzeichnis verknüpfen. Das VCI ist ab V18 integrierter Bestandteil des Engineering-Frameworks.
Objekte in den Workspace übernehmen
Bausteine, Typen und PLC-Datenobjekte per Drag & Drop in den Workspace ziehen. Das VCI legt sie als quellcode-basierte Dateien ab — ab V21 als diff-fähiges LAD/FBD/SCL statt des älteren, rein XML-basierten Exports.
Workspace mit Git verbinden
Auf das Workspace-Verzeichnis einen Git-Client (VS Code, Git Bash, IDE) ansetzen und gegen GitLab, GitHub, Gitea oder einen On-Prem-Server committen, branchen und mergen. Bausteinvergleiche sind direkt im TIA Portal möglich.
Synchronisieren & CI/CD ergänzen
Änderungen aus dem TIA Portal in den Workspace exportieren, per Git versionieren und dieselbe CI/CD-Logik wie beim Openness-Weg anbinden — Export-Checks, PLCSim-Tests und Compliance-Gates greifen unverändert.
Git je TIA-Portal-Version
Ab welcher Version welcher Git-Weg verfügbar ist — und was V21 beim Export verbessert.
TIA Portal V20 und Git
In TIA Portal V20 ist das Version Control Interface fest integriert — der VCI-Workspace, der Drag-&-Drop-Export und die Git-Anbindung über einen externen Client funktionieren wie ab V18, mit breiterer Steuerungsunterstützung. Der Export ist in V20 allerdings noch überwiegend XML-basiert: Bausteinvergleiche gelingen im TIA Portal selbst, Standard-Git-Diffs bleiben sperrig. Wer den textbasierten, direkt diff-fähigen LAD/FBD/SCL-Export will, braucht das Upgrade auf V21 — der Git-Workflow selbst bleibt beim Wechsel unverändert.
TIA Portal mit GitHub verbinden
GitHub braucht keine Sonderbehandlung: Das VCI- oder Openness-Exportverzeichnis wird als lokales Git-Repository initialisiert und gegen ein Repository auf github.com oder GitHub Enterprise gepusht — Branches, Pull Requests und Code-Reviews funktionieren damit wie in der Software-Entwicklung. GitHub Actions übernimmt die CI/CD-Seite: Export-Konsistenz prüfen, PLCSim-Smoke-Tests fahren, Engineering-Backups als Artefakte signieren. Self-hosted Runner auf einem Windows-Engineering-Host sind dabei Pflicht, weil TIA Portal und PLCSim Windows voraussetzen.
Git-Integration je Engineering-Tool
Die PLC-Git-Frage stellt sich nicht nur im TIA Portal — CODESYS und TwinCAT gehen eigene, teils komfortablere Wege. Der Vergleich zeigt, wie nah die jeweilige Plattform an einem nativen Git-Workflow ist.
Wenn Git allein nicht reicht
Bei heterogenen Anlagen mit mehreren Steuerungsherstellern oder wenig Git-Erfahrung im Team können spezialisierte Werkzeuge sinnvoll sein. Sie nutzen Git meist im Hintergrund und ergänzen es um PLC-spezifische, grafische Diffs.
octoplant (ehem. versiondog)
Herstellerübergreifende Versionsverwaltung für Automatisierungsprojekte; interpretiert proprietäre Formate, stellt Ladder-/Grafik-Diffs dar und nutzt Git-Mechanismen (Branches, Rollback) im Hintergrund.
Copia Automation
Speziell auf PLC-Versionierung via Git ausgelegt; übersetzt proprietäre Formate in lesbare Strukturen und ergänzt grafische Diffs und Reviews für SPS-Code.
Comquent berät herstellerneutral: Wer volle Kontrolle und CI/CD-Tiefe will, fährt mit nativem Git über VCI oder Openness flexibler — Spezialwerkzeuge spielen ihre Stärke bei gemischten Flotten aus. Wie sich PLC-Code mit Git versionieren und auf ganze Anlagen-Flotten ausrollen lässt, vertieft unser GitOps-in-der-Industrie-Leitfaden.
Kann man TIA Portal mit Git versionieren?
Ja. TIA Portal speichert das Projekt zwar binär (.ap-Datei), über die TIA-Openness-API lassen sich Bausteine und Tags aber als mergefähiger Quelltext (XML, SCL, AWL) exportieren. Dieser Export wird in Git versioniert — nicht die Binärdatei. So entstehen nachvollziehbare Diffs, Branches und Code-Reviews wie in der klassischen Softwareentwicklung.
Gibt es ein offizielles TIA Portal Git-Addin?
Ja. Siemens bietet mit dem Version Control Interface (VCI) ab TIA Portal V18 eine integrierte Git-Anbindung; für ältere Versionen existiert der VCI Git Connector als Add-In (ab V16). Ergänzend erlaubt die Openness-API eigene Export-/Import-Skripte für maximale Flexibilität und tiefe CI/CD-Integration. Openness ist also der skriptbasierte, VCI der direkt im TIA Portal integrierte Weg. Comquent richtet beide Toolchains projektspezifisch ein.
Was ist das TIA Portal Version Control Interface (VCI)?
Das Version Control Interface (VCI) ist Siemens’ integrierte Brücke zwischen TIA-Portal-Engineering und quellcode-basierten Versionierungssystemen wie Git oder Subversion. Man legt im TIA Portal einen Workspace an, der auf ein Verzeichnis zeigt, übernimmt Bausteine per Drag & Drop und versioniert dieses Verzeichnis mit einem Git-Client. Ab V21 exportiert das VCI diff-fähiges LAD/FBD/SCL statt des älteren XML-Formats.
Unterstützt TIA Portal Source Control bzw. Version Control?
Ja. Siemens nennt die integrierte Lösung „Version Control Interface" (VCI) — in englischsprachigen Quellen läuft das Thema unter „TIA Portal version control" oder „TIA Portal source control", gemeint ist dieselbe Schnittstelle. Ab V18 verbindet das VCI das Engineering mit quellcode-basierten Systemen wie Git oder Subversion; wer nach „Siemens Git" sucht, landet in der Regel genau hier. Für ältere Versionen oder tiefe Automatisierung bleibt die Openness-API der skriptbasierte Weg.
Openness oder VCI — welcher Weg ist der richtige?
Für neue Projekte ab V18 (ideal V21) ist das integrierte VCI der komfortablere Weg: weniger Skriptaufwand, Bedienung direkt im TIA Portal. Die Openness-API lohnt sich bei älteren Versionen, eigenen Naming-Konventionen oder besonders tiefer CI/CD-Automatisierung. Beide Wege versionieren denselben textuellen Quelltext in Git und lassen sich kombinieren — die Wahl hängt von TIA-Version und gewünschtem Automatisierungsgrad ab.
Was ist neu bei TIA Portal V21 in Sachen Git?
TIA Portal V21 baut vor allem das Version Control Interface (VCI) deutlich aus: Bausteine werden als textbasiertes LAD, FBD und SCL exportiert, das sich mit Standard-Git diffen lässt — ein klarer Fortschritt gegenüber dem überwiegend XML-basierten Export ab V18. Parallel verbessert V21 die Openness-API. Bestehende Openness-Skripte sollten beim Versionswechsel gegen die neue API validiert werden.
Wie funktioniert die Versionsverwaltung in CODESYS?
CODESYS bringt mit „CODESYS Git" eine integrierte Git-Anbindung mit, die Projekte direkt aus der Entwicklungsumgebung committen und mergen kann. Die Bausteine werden dabei in einem versionierbaren Format abgelegt. Das macht CODESYS in puncto Git-Integration komfortabler als TIA Portal, das den Umweg über Openness braucht.
Lässt sich SPS-Code mit GitHub oder GitLab versionieren?
Ja — sowohl GitHub als auch GitLab eignen sich. Versioniert wird der textuelle Export der SPS-Programme. GitLab bietet zusätzlich integrierte CI/CD-Pipelines, mit denen sich Export-Konsistenz, PLCSim-Tests und Compliance-Gates automatisieren lassen. GitHub Actions leistet dasselbe. Die Wahl hängt von der bestehenden Toolchain ab.
Warum reicht es nicht, die TIA-Portal-Projektdatei in Git zu legen?
Die .ap-Projektdatei ist ein Binärformat. Git kann Binärdateien zwar speichern, aber nicht sinnvoll diffen oder mergen — zwei parallele Änderungen führen zum Konflikt ohne Auflösungsmöglichkeit. Erst der textuelle Export (über VCI oder Openness) macht Änderungen Zeile für Zeile sichtbar und mehrere Bearbeiter konfliktfrei möglich.
Was unterscheidet octoplant und Copia von nativem Git?
Spezialwerkzeuge wie octoplant (ehemals versiondog) und Copia Automation nutzen Git oft im Hintergrund, ergänzen es aber um herstellerübergreifende Unterstützung und PLC-spezifische, grafische Diffs — auch für Ladder-Logik. Sie sind sinnvoll, wenn mehrere Steuerungshersteller (Siemens, Rockwell, Beckhoff) parallel laufen oder im Team wenig Git-Know-how vorhanden ist. Wer volle Kontrolle und CI/CD-Tiefe will, fährt mit nativem Git über VCI oder Openness flexibler.
Verwandte Artikel
SPS Versionsverwaltung: Git für Industrial IT
Warum Git die Grundlage für reproduzierbare SPS-Projekte ist — und wie der Einstieg gelingt.
CI/CD für SPS: TIA Portal mit Jenkins automatisieren
Automatisierte Build-, Test- und Deploy-Pipeline für TIA-Portal-Projekte mit Jenkins.
SPS mit C# programmieren — S7.NET, TwinCAT.NET, CI/CD
Drei Pfade für C# in der OT — inklusive Git-Versionierung und CI/CD.
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