Git für PLC/SPS-Entwickler in 3 Tagen
Theorie, Livecoding sowie praktische Übungen
Dev-Umgebung mit Git für jeden Teilnehmer
Kleine Gruppen mit max. 7 Teilnehmer
Trainer erfahrener Git Berater
Unterlagen und Teilnahmezertifikat
Im Servicefall zählt vor allem, welcher Stand auf der Anlage läuft. Das Training richtet Git deshalb auf den SPS-Alltag mit TIA Portal aus, auf Inbetriebnahme, Service-Fixes und Release-Stände. Ihr bekommt klare Standards für Repo-Struktur, Branching, Reviews und Konfliktlösung, damit im Team dieselben Regeln gelten. In den Übungen arbeitet ihr mit realistischen TIA-Workflows, bis ihr einen ausgelieferten Stand über seinen Tag wiederfindet und reproduzierbar herstellt.
TIA-Projekte sind Container, keine Textdateien. Deshalb klärt das Training zuerst, was bei euch überhaupt versioniert wird: der Projektstand als Archiv oder Export, Baustein-Exporte und SCL-Quellen als quellnahe Artefakte, die Dokumentation getrennt davon.
Git-Kenntnisse setzt das Training nicht voraus. Vorausgesetzt wird, dass ihr TIA Portal kennt; darauf baut alles andere auf.
Ein Review im OT-Umfeld prüft andere Punkte als ein Software-Review: Safety, I/O, HMI und Alarme, Parametrierung, Feldbus. Genau diese Checkliste erarbeiten wir mit euch.
Die Agenda – 3 Tage Git für TIA Portal Entwickler
Git-Grundlagen mit direktem Bezug zu TIA Portal
Start, Zielbild und TIA-Projekt als Versionierungsobjekt
Wir klären, welche Arten von Änderungen ihr im TIA Portal typischerweise macht (z. B. Bausteine, Hardwarekonfiguration, PLC-Tags, HMI-Objekte) und welche davon sich gut in Git nachverfolgen lassen. Danach legen wir fest, was für euch im Repository als „lieferbarer Stand“ gilt, damit am Ende jeder weiß, welcher Commit einem reproduzierbaren TIA-Projektstand entspricht.
Git-Basics, die ihr im Alltag wirklich braucht
Wir bauen ein solides Git-Grundverständnis auf, damit ihr über Klickfolgen hinaus sicher einschätzen könnt, was lokal passiert und was im Repository landet. Anschließend übt ihr die täglichen Handgriffe wie Änderungen prüfen, gezielt stagen und sauber committen, sodass eure Historie später auch unter Zeitdruck noch verständlich bleibt.
Commit-Qualität und sinnvolle Commit-Nachrichten für SPS-Arbeit
Wir erarbeiten, wie ein Commit so geschnitten wird, dass er eine klare technische Absicht trägt, zum Beispiel „SCL-Baustein erweitert“ oder „Parametrierung angepasst“, statt einen unlesbaren Sammelstand zu erzeugen. Danach definiert ihr ein einfaches, teamtaugliches Schema für Commit-Nachrichten, das euch bei Fehlersuche, Reviews und Nachweispflichten spürbar hilft.
Repository-Grundstruktur für TIA-Projekte
Wir legen eine Repo-Struktur an, die für TIA Portal praktisch ist und gleichzeitig Git-freundlich bleibt, damit nicht alles in einem unübersichtlichen Ordner endet. Dabei trennt ihr bewusst zwischen „Projektstand“ (z. B. als Archiv/Export), „quellnahen Artefakten“ (z. B. Baustein-Exporte oder SCL-Quellen) und „Dokumentation“, damit Änderungen nachvollziehbar bleiben und das Repository nicht unnötig wächst.
Teamarbeit, Konflikte und TIA-spezifische Änderungsvergleiche
Zusammenarbeit mit Remote: sauber ziehen, sauber liefern
Wir üben, wie ihr im Team zuverlässig mit einem zentralen Git-Server arbeitet, ohne euch gegenseitig zu blockieren oder Stände zu überschreiben. Ihr trainiert dabei einen Rhythmus aus Updates holen, eigene Änderungen integrieren und kontrolliert pushen, der auch in Inbetriebnahme-Phasen stabil funktioniert.
Branching im SPS-Kontext: Feature, Inbetriebnahme, Service
Wir etablieren eine einfache Branching-Logik, die zu SPS-Realität passt, also zu parallelen Feature-Themen, laufender Inbetriebnahme und kurzfristigen Service-Fixes. Danach setzt ihr diese Logik praktisch um, indem ihr Änderungen in einem Feature-Branch aufbaut und sie so integriert, dass der Hauptzweig jederzeit einen klaren, prüfbaren Stand repräsentiert.
Konflikte verstehen und mit TIA-Artefakten umgehen
Wir machen transparent, warum Merge-Konflikte entstehen und warum sie bei TIA-Projektartefakten oft anders aussehen als bei reinem Text. Ihr übt deshalb gezielt Konfliktsituationen so, dass ihr eine Strategie habt, wann ihr textbasierte Exporte sauber mergen könnt und wann ihr bewusst über einen klaren „Stand ersetzen“-Ansatz arbeitet, um keine stillen Fehler in das Projekt zu ziehen.
Vergleichbarkeit herstellen: Exporte und Quellen als Review-Basis
Wir sorgen dafür, dass Änderungen im Team wirklich reviewbar werden, indem ihr TIA-Änderungen so ablegt, dass Git-Diffs einen fachlichen Unterschied zeigen können. Ihr übt, Baustein-Änderungen und relevante Projektteile zusätzlich in einer textnahen Form abzulegen (z. B. als konsistente Exporte/Quellen), damit Reviews, Code-Owner-Regeln und spätere Analysen realistisch möglich sind.
Releases, Kundenstände und ein kompletter Durchlauf bis zum Tag
Release-Stände in TIA sauber markieren und wiederfinden
Wir bauen einen Ablauf auf, mit dem ihr Abnahme-, Kunden- oder Lieferstände eindeutig kennzeichnet, sodass später klar ist, welcher Stand wirklich ausgeliefert wurde. Ihr übt, einen Release-Stand reproduzierbar zu dokumentieren und ihn per Tag so zu markieren, dass er im Service-Fall schnell wiedergefunden wird.
Service-Fixes zwischen Ständen übertragen, ohne Chaos zu erzeugen
Wir trainieren einen Service-Workflow, bei dem ein Fix aus dem Kundenumfeld kontrolliert in andere Stände übernommen werden kann, ohne die laufende Entwicklung zu destabilisieren. Ihr übt dabei das gezielte Übernehmen einzelner Änderungen zwischen Branches, damit ihr nicht ganze Projektstände hin- und herschiebt, wenn eigentlich nur ein klarer Fix benötigt wird.
Rückgängig machen ohne Schaden: sichere Undo-Strategien
Wir klären, wie ihr Fehler in der Versionshistorie korrigiert, ohne Teamkollegen zu gefährden oder die Historie unbrauchbar zu machen. Ihr übt genau die Fälle, vor denen alle Angst haben: falscher Stand gemerged, Änderung war doch nicht korrekt, zu viel committed. Das passiert in eurer eigenen Umgebung, in der ein Fehler nichts kostet.
Praxisprojekt: End-to-End von Änderung bis Release-Tag
Wir führen alles in einem durchgängigen Mini-Projekt zusammen, das typische TIA-Änderungen abbildet, zum Beispiel eine Bausteinanpassung plus eine parametrierungsnahe Änderung. Jede Gruppe arbeitet in Branches, erstellt einen Merge Request, führt ein Review durch, löst mindestens eine Konfliktsituation und liefert am Ende einen sauber getaggten Release-Stand ab.
Was macht das Git Training für PLC/SPS Entwicklung so besonders?
OT-Artefakte statt Quellcode-Idealwelt
Im SPS-Umfeld bestehen Projekte oft aus binären Containern, generierten Dateien und Tool-spezifischen Strukturen.
Wir zeigen, welche Dateien sinnvoll versioniert werden, wie Exporte (z. B. ST/XML/CSV) Git-fähig gemacht werden und wie man Repos so aufsetzt, dass sie wartbar bleiben.
Nachvollziehbarkeit für Inbetriebnahme & Service
Git wird als „Anlagen-Chronik“ genutzt: jeder Stand ist eindeutig auffindbar, reproduzierbar und rückrollbar.
Tags/Releases bilden FAT/SAT, Auslieferungen und Service-Hotfixes ab, sodass Teams im Fehlerfall schnell den letzten stabilen Stand herstellen können.
4-Augen-Prinzip & Freigaben OT-tauglich
Code Reviews in OT brauchen andere Prüfpunkte als reine Software-Reviews.
Mit Merge-Request-Templates und Checklisten (Safety, I/O, HMI/Alarme, Parameter, Feldbus) wird aus „Freigabe nach Gefühl“ ein reproduzierbarer Prozess.
Wer freigegeben hat, was geprüft wurde und welcher Stand ausgeliefert wurde, steht danach im Repository statt in Erinnerungen. Welche Nachweispflichten im Maschinenbau dahinterstehen, ordnet unser Beitrag zum Cyber Resilience Act im Maschinenbau ein.
Branching speziell für Varianten & Kundenstände
Maschinenbau bedeutet Varianten, Optionen und kundenspezifische Abzweige – klassische Branch-Modelle skalieren hier oft schlecht.
Wir etablieren pragmatische Strategien (z. B. trunk-based + Release-Branches), damit Serienstand, Sonderstände und Hotfixes ohne Chaos parallel laufen.
Konflikte & Diffs in der Praxis
Bei Ladder/FBD oder Projektcontainern sind Diffs/Merges oft eingeschränkt oder unmöglich.
Wir trainieren konkrete Workarounds: klare Ownership/Teilverantwortung, Export-Diffs, Locking-Ansätze und Vorgehen bei parallelen Änderungen – damit Konflikte nicht erst auf der Anlage auffallen.
Toolchain-Integration, die OT wirklich nutzt
Wir verbinden Git mit GitLab/GitHub/Azure DevOps so, dass es im Alltag funktioniert: Rechte/Rollen, Vorlagen, Release-Pakete, Nachverfolgung von Änderungen.
Optional zeigen wir einfache Automatisierungen (Export, Checks, Artefaktablage), die ohne Overengineering echten Nutzen bringen.
Sicherer Betrieb an der Anlage
OT-Teams arbeiten häufig offline, unter Zeitdruck und mit Produktionsrisiko.
Deshalb üben wir sichere Workflows für Service-Einsätze: saubere Backups, definierter Notfallprozess, „kleinste sichere Änderung“ und verlässliches Wiederherstellen eines bekannten Stands.
Ergebnisorientiert statt nur Git-Wissen
Am Ende steht neben dem Git-Verständnis ein anwendbarer Standard: Repo-Layout, Naming/Tagging, Branch-Regeln und DoD für SPS-Änderungen.
Dazu kommt ein konkreter 30-Tage-Plan, wie das Team die Methode in einem Pilotprojekt einführt und verstetigt.
Wie führen wir unsere Trainings und Workshops durch?
Öffentliches Training
Wir führen öffentliche Trainings in unseren Räumlichkeiten oder
an einem unserer Partnerstandorte durch. Folgendes wird Ihnen während des Seminars und bei Praxisübungen zur Verfügung gestellt:
- Trainingsunterlagen
- Getränke, Obst & Snacks
- Mittagessen & Kaffeepause
- Teilnahmezertifikat
Inhouse Training
Inhouse Trainings können inhaltlich Ihren speziellen Anforderungen, Wünschen oder den Bedürfnissen Ihres Teams bzw. eines Projektes angepasst werden. Sprechen Sie uns an und nennen sie uns einen Wunschtermin. Wir unterbreiten Ihnen gern ein Angebot.
Schreiben Sie uns unter: training@comquent.de
Einzelcoaching
Sie möchten einen unserer Trainer und Berater für sich allein? Auch das ist machbar und bietet die Möglichkeit, ganz auf Ihre Anforderungen und Bedürfnisse einzugehen. Sprechen Sie uns für ein spezielles Angebot incl. Wunschtermin an!
Schreiben Sie uns unter: coaching@comquent.de
Dieses Training setzt bei den Ständen an. Und wenn Ihr Engpass woanders liegt?
Jetzt Firmentraining anfragen: Git für SPS/PLC-Teams mit TIA Portal
Buchen Sie ein firmeninternes Training, das Git genau auf Ihren TIA-Portal-Alltag ausrichtet – inklusive Branching, Reviews, Konfliktlösung und Release-Standards. Wir arbeiten praxisnah mit typischen SPS-Änderungen und etablieren klare Team-Regeln, die sofort im Projekt greifen. Schreiben Sie uns jetzt für ein unverbindliches Angebot und passende Terminvorschläge.
Ihre Mail an academy@comquent.de
Nach drei Tagen hat Ihr Team einen eigenen Standard: Repo-Layout, Namens- und Tagging-Regeln, Branch-Regeln und eine Definition of Done für SPS-Änderungen. Dazu einen 30-Tage-Plan für das erste Pilotprojekt. Je länger Sie warten, desto länger bleibt die Frage nach dem ausgelieferten Stand eine Frage an das Gedächtnis.
Sieben Teilnehmer, sieben Umgebungen. Klemmt es beim Merge eines Baustein-Exports, steht der Trainer daneben.
Für die Anfrage genügen Teamgröße und Wunschzeitraum. Sie bekommen einen Terminvorschlag und eine auf Ihre Projekte abgestimmte Agenda, unverbindlich.
