Links ein offenes Testgestell mit Steuerungen zweier Hersteller, rechts prüft ein SPS-Programmierer am Bildschirm eine Vergleichsansicht mit einer grün und einer rot markierten Änderung, ein Kollege steht hinter ihm und liest mit

// Der Weg: Problem → Funktionen → Adapter → Beispiel → Grenzen → frühe Nutzung

PLC Git Bridge: Git für jede Steuerung

Ein Git-Ablauf für SPS-Projekte, egal ob sie in TIA Portal, CODESYS, TwinCAT oder Studio 5000 entstehen. Adapter übernehmen, was jede Umgebung anders macht: Export und Import, die Prüfung vor dem Commit und das Archiv zum Release.

Frühen Zugang anfragen Whitepaper Git mit TIA Portal

30 Minuten · unverbindlich · kein Vertriebsgespräch

IN ENTWICKLUNG · TIA PORTAL · CODESYS · TWINCAT · STUDIO 5000

// 01Kurz erklärt

Was ist die PLC Git Bridge?

Die PLC Git Bridge legt einen gemeinsamen Git-Ablauf über SPS-Projekte verschiedener Hersteller.

Jede Engineering-Umgebung bringt Steuerungscode auf ihre Art in Dateien. TIA Portal exportiert über das Version Control Interface, CODESYS ab V3.5 SP22 über File-Based Storage, TwinCAT legt das Projekt ohnehin als Dateien ab, und Studio 5000 liefert lesbaren Text über den L5X-Export, den Rockwell inzwischen mit eigenen Werkzeugen für Git zerlegt. Die Git Bridge hat je Umgebung einen Adapter und darüber dieselben Regeln: was vor dem Commit geprüft wird, was nach dem Pull passiert und was zu einem Release gehört.

Auf einen Blick

Art: Client mit Add-Ins, wo die Engineering-Umgebung sie zulässt
Adapter: Siemens TIA Portal, CODESYS, Beckhoff TwinCAT 3, Rockwell Studio 5000
Git-Server: Ihr vorhandener, etwa GitLab, Gitea oder Azure DevOps
Erweiterbar: Eigene Adapter für weitere Umgebungen, etwa über PLCopen XML
Status: In Entwicklung, frühe Nutzung mit ausgewählten Teams

Entwicklungsstand · Bildschirmfotos aus dem Prototyp

/01 Projekte und Prüfung
Die Bridge hängt sich an das laufende TIA Portal und gleicht jedes Objekt mit seiner Datei ab. FC_Notaus ist nicht exportiert, DB_Rezepte nicht übersetzt, also bleibt der Commit gesperrt. Die Hardwarekonfiguration steht als nicht exportierbar da; sie sichert das Archiv zum Release.
/02 Pull
Der Text-Merge war konfliktfrei, übersetzen lässt sich das Projekt trotzdem nicht: Ein Kollege hat UDT_Motor geändert, FB_Foerderband braucht noch den alten Parameter. Die Bridge meldet das direkt nach dem Pull, mit dem Commit, aus dem die Änderung stammt.
/03 Release
Der Tag sitzt auf einem eigenen Release-Commit, der nur releases/v1.4.0/ berührt. Darin liegen die Archive aller vier Umgebungen mit Prüfsumme und ein Manifest, das auf den Quell-Commit zeigt.

Bildschirmfotos aus dem Prototyp, Entwicklungsstand Oktober 2026. PLC Git Bridge ist in Entwicklung; Ansichten, Bezeichnungen und Zahlen können sich bis zur ersten Version ändern. Ein Klick auf ein Bild öffnet es in voller Größe.

// 02Ausgangslage

Warum reicht Git allein für SPS-Projekte nicht?

Weil jede Umgebung anders versioniert. Ein TIA-Projekt muss über das Version Control Interface exportiert werden, ein Studio-5000-Projekt ist eine Binärdatei, für die erst der L5X-Export einen lesbaren Diff ergibt. TwinCAT schreibt seine Bausteine dagegen direkt als Dateien. Wer Steuerungen mehrerer Hersteller betreut, hat mehrere Arbeitsweisen nebeneinander.

Weil die Handgriffe zwischen Projekt und Repository vergessen werden. Vor dem Commit exportieren, nach dem Pull importieren und übersetzen. Ein konfliktfreier Text-Merge heißt noch nicht, dass das Projekt übersetzt.

Und weil nicht alles Text wird. Hardwarekonfiguration und Teile der Visualisierung bleiben je nach Umgebung binär. Ein Release braucht deshalb neben dem Git-Tag das Projektarchiv desselben Stands.

Ein Maschinenbauer liefert je nach Kundenvorgabe mit Siemens oder mit Rockwell aus. Die Siemens-Projekte liegen seit einem Jahr in Git, die Rockwell-Projekte noch als ACD-Dateien mit Datum im Namen auf dem Netzlaufwerk. Welcher Stand bei welchem Kunden läuft, beantwortet jede Abteilung auf ihre Weise.

// 03Funktionen

Was soll die Git Bridge
können?

Der geplante Funktionsumfang. PLC Git Bridge ist in Entwicklung, Einzelheiten können sich bis zur ersten Version ändern.

/01
Ein Ablauf für alle Umgebungen
Commit, Pull, Branch und Release, überall gleich bedient.
Status, Commit, Pull, Push und Branch-Wechsel laufen über die Git Bridge, wo die Umgebung es zulässt als Add-In direkt im Engineering-Werkzeug. Der Adapter übersetzt jeden Schritt in das, was die jeweilige Umgebung dafür braucht.
/02
Prüfung vor dem Commit
In Git landet nur, was im Projekt genauso aussieht.
Vor jedem Commit fragt der Adapter die Umgebung, ob alle geänderten Objekte übersetzt und exportiert sind. Ist ein Baustein im Projekt neuer als im Repository, sagt die Bridge das, statt einen unvollständigen Commit durchzulassen.
/03
Import nach dem Pull
Der Stand der Kollegen landet im Projekt, nicht nur im Ordner.
Nach Pull und Merge spielt der Adapter die geänderten Quellen in das Projekt ein und übersetzt es. Scheitert die Übersetzung, etwa weil zwei Personen Schnittstellen abhängiger Bausteine geändert haben, sieht das der Entwickler sofort und nicht erst bei der Inbetriebnahme.
/04
Konventionen in einer Datei
Eine Konfiguration im Repository für alle Projekte.
Die Konfigurationsdatei legt je Projektordner den Adapter und die Regeln fest: Exportformate, Sprache, Zeilenenden und was ins Repository gehört. Die Bridge prüft jeden Arbeitsplatz dagegen, bei Siemens genauso wie bei Beckhoff.
/05
Release-Stand mit Projektarchiv
Tag und Archiv gehören zusammen.
Beim Release setzt die Bridge den Git-Tag, erzeugt über den Adapter das Projektarchiv der jeweiligen Umgebung und legt es mit dem Commit-Hash in Git LFS oder einer Artefaktablage ab.

// 04Adapter

Welche Hersteller unterstützt die Git Bridge?

Geplant sind Adapter für vier Engineering-Umgebungen. Bedienung und Regeln bleiben gleich, der Adapter übernimmt, was die jeweilige Umgebung anders macht. Welche Adapter zuerst fertig werden, ist noch offen. Weitere Umgebungen lassen sich über eigene Adapter anbinden.

Umgebung	Was der Adapter tut
Siemens TIA Portal V21	Arbeitet mit dem VCI-Workspace und SIMATIC SD, stößt Export und Import an und legt zum Release das Archiv .zap21 ab, weil Hardwarekonfiguration und klassische HMI nicht über VCI laufen.
CODESYS V3.5	Arbeitet ab CODESYS V3.5 SP22 mit File-Based Storage, das Bausteine als lesbaren Structured Text ablegt, ohne Zeitstempel und in fester Reihenfolge. Bei älteren Ständen bleibt CODESYS Git zuständig, dessen Dateien nur CODESYS selbst bearbeiten soll. Die Bridge bringt dort die gemeinsamen Regeln und den Release-Ablauf dazu.
Beckhoff TwinCAT 3	Das Projekt liegt schon als Dateien vor. Der Adapter prüft die Konventionen aus Beckhoffs Handbuch zur Versionsverwaltung, hält erzeugte Dateien und LineIDs aus dem Repository und übersetzt nach dem Pull. Merges an Bausteinen und Projektdateien übergibt er an das TwinCAT Project Compare Tool, weil Beckhoff vom automatischen Merge durch Git abrät.
Rockwell Studio 5000	Baut auf den Werkzeugen auf, die Rockwell selbst für Git veröffentlicht hat: Vor dem Commit wird das Projekt nach L5X exportiert und je Routine, Datentyp und AOI in eigene Dateien zerlegt, nach dem Pull wieder zusammengesetzt und importiert. Die .ACD-Datei liegt als Release-Archiv daneben.

// 05Beispiel

Wie sieht eine Konfiguration für mehrere Hersteller aus?

Ein Entwurf der Konfigurationsdatei im Repository. Eine Fertigungslinie mit Steuerungen von drei Herstellern und eine Altanlage, alle unter denselben Regeln.

Nach ein paar Wochen sieht der Review am Merge Request eine geänderte Zeile im Baustein, bei Siemens wie bei Rockwell, und nicht mehr eine neue Projektdatei mit Datum im Namen.

.plc-git-bridge.yml

# Entwurf
projekte:
  - pfad: linie-1/plc
    adapter: tia-portal      # VCI-Workspace, SIMATIC SD
    version: V21
  - pfad: linie-1/roboterzelle
    adapter: twincat         # Dateien direkt im Repository
  - pfad: verpackung/plc
    adapter: codesys         # File-Based Storage
  - pfad: altanlage/logix
    adapter: studio5000      # L5X zerlegt, .ACD als Archiv

regeln:
  vor-commit: uebersetzt-und-exportiert
  nach-pull: importieren-und-uebersetzen
  zeilenenden: crlf
  release:
    tag: v{version}
    archiv: git-lfs

Entwurf · Befehle, Bezeichnungen und Ausgabe können sich bis zur ersten Version ändern.

// 06Grenzen

Was die Git Bridge
nicht tut

/01
Die Git Bridge ist kein Git-Server. Sie arbeitet mit dem Server, den Sie schon betreiben.
/02
Sie macht nicht jede Umgebung vollständig zu Text. Was binär bleibt, sichert sie über das Projektarchiv je Release.
/03
Bausteine, die der Hersteller oder ein Lieferant gegen Einsicht schützt, kann auch sie nicht exportieren.
/04
Sie ersetzt nicht die Mehrbenutzer-Funktionen der Umgebungen, etwa TIA Portal Multiuser Engineering.
/05
Merge-Konflikte in grafischen Sprachen wie KOP, FUP oder Ladder löst sie nicht automatisch. Parallele Änderungen am selben grafischen Baustein bleiben eine Frage der Absprache.

// 07Voraussetzungen

Was braucht die Git Bridge?

Umgebung: Eine unterstützte Engineering-Umgebung in einer Version, die der Adapter kennt, bei TIA Portal etwa V21 mit Option „TIA Portal Openness“
Git: Git for Windows auf jedem Engineering-PC
Git-Server: Vorhandener Server mit Branch-Schutz für main
Archive: Git LFS oder eine Artefaktablage für die Projektarchive

// 08Einordnung

Wo steht die Git Bridge
in der Kette?

Die vier Werkzeuge bauen aufeinander auf: versionieren, bauen und testen, nachweisen, mit KI entwickeln. Jedes läuft auch allein, in Ihrer vorhandenen Pipeline. Die ganze Strecke bis zur Anlage deckt die Plattform IndustrialFlow ab.

01 · Versionieren
PLC Git Bridge
Diese Seite
02 · Bauen und testen
PLC Build Tool
03 · Nachweisen
PLC SBOM Builder
04 · Mit KI entwickeln
PLC KI Tool

Plattform · Verfügbar als 90-Tage-Pilot

IndustrialFlow

Entspricht in IndustrialFlow den Pipeline-Stufen Commit und Projektexport.

// 09Frühe Nutzung

Ab wann geht das
bei uns?

Wir suchen Teams, die die Git Bridge früh an einem eigenen Projekt einsetzen wollen, gern mit Steuerungen mehrerer Hersteller im Haus. Welche Adapter zuerst fertig werden, richtet sich auch nach diesen Teams. Was dafür nötig ist und ab wann es geht, klären wir in einem kurzen Gespräch.

Frühen Zugang anfragen

30 Minuten · unverbindlich · kein Vertriebsgespräch

PLC Git Bridge: Git für jede Steuerung

Was ist die PLC Git Bridge?

Warum reicht Git allein für SPS-Projekte nicht?

Was soll die Git Bridgekönnen?

Ein Ablauf für alle Umgebungen

Prüfung vor dem Commit

Import nach dem Pull

Konventionen in einer Datei

Release-Stand mit Projektarchiv