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
Comquent Academy ist der richtige Partner, weil das Training Git nicht theoretisch erklärt, sondern konsequent auf den SPS-Alltag mit TIA Portal und typische Team-Situationen wie Inbetriebnahme, Service-Fixes und Release-Stände ausrichtet. Ihr bekommt dabei klare, umsetzbare Standards für Repo-Struktur, Branching, Reviews und Konfliktlösung, damit Git im Team einheitlich und verlässlich genutzt wird. Durch praxisnahe Übungen mit realistischen TIA-Workflows wird aus „Wir wissen, wie Git geht“ schnell „Wir arbeiten damit sicher und effizient zusammen“.
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 nicht nur Klickfolgen kennt, sondern 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 typische Rettungsszenarien wie „falscher Stand gemerged“, „Änderung war doch nicht korrekt“ oder „zu viel committed“, sodass ihr im Ernstfall ruhig und sauber handeln könnt.
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.
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 nicht nur Git-Verständnis, sondern ein anwendbarer Standard: Repo-Layout, Naming/Tagging, Branch-Regeln und DoD für SPS-Änderungen.
Zusätzlich gibt es einen konkreten 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
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
Warum ist Git für SPS-/PLC-Entwickler mit TIA Portal sinnvoll?
Git hilft dabei, Projektstände nachvollziehbar zu versionieren und Änderungen sauber zu dokumentieren. Dadurch wird die Zusammenarbeit im Team transparenter und Fehler lassen sich schneller analysieren.
Welche Teile eines TIA-Portal-Projekts sollten mit Git versioniert werden?
Sinnvoll ist es, klar definierte Projektstände sowie textnahe Exporte oder Quellen zu versionieren. Generierte oder rein binäre Dateien sollten nur dann aufgenommen werden, wenn sie wirklich notwendig sind.
Warum sind kleine, saubere Commits im SPS-Umfeld wichtig?
Kleine Commits machen nachvollziehbar, welche fachliche Änderung durchgeführt wurde. Das erleichtert Fehlersuche, Reviews und das Zurückverfolgen von Service-Fixes.
Wozu werden Branches in TIA-Portal-Projekten eingesetzt?
Branches erlauben es, parallel an Features, Inbetriebnahmen oder Service-Themen zu arbeiten. So bleibt der Hauptzweig stabil und jederzeit als Referenz nutzbar.
Warum entstehen Merge-Konflikte bei TIA-Portal-Projekten besonders häufig?
Viele TIA-Artefakte sind nicht rein textbasiert und lassen sich nicht automatisch zusammenführen. Konflikte entstehen vor allem dann, wenn mehrere Personen dieselben Projektteile gleichzeitig ändern.
Wie helfen Pull- oder Merge-Requests SPS-Teams konkret weiter?
Sie schaffen eine strukturierte Möglichkeit, Änderungen vor dem Zusammenführen zu prüfen. Gleichzeitig fördern sie Wissensaustausch und erhöhen die Qualität des Projektstands.
Wie können ausgelieferte Maschinen- oder Kundenstände in Git sauber gekennzeichnet werden?
Dafür werden in der Regel Tags oder dedizierte Release-Branches verwendet. So ist später eindeutig nachvollziehbar, welcher Stand tatsächlich ausgeliefert oder abgenommen wurde.
Warum ist ein definierter Service-Workflow mit Git wichtig?
Ein klarer Workflow verhindert, dass Service-Fixes chaotisch zwischen Projektständen kopiert werden. Stattdessen lassen sich gezielte Änderungen kontrolliert übernehmen und sauber zurückführen.
