PLC version control means keeping every change to your PLC and HMI projects in a repository, with who changed what, when and why, so you can compare versions, review changes and return to a known state. For years the PLC world lagged behind software teams here, mainly because project files were binary. That has changed: TwinCAT 3 integrates source control into Visual Studio, CODESYS has an official Git add-on, and Siemens offers native Git in its newer SIMATIC AX environment and a version control interface in TIA Portal. If several engineers, or an outside partner, work on your machines, Git should be the norm.
Why PLC version control matters more now
- More people touch the code. In-house engineers, service technicians, outsourced teams and the customer's maintenance staff.
- Regulation asks for traceability. From 20 January 2027 the Machinery Regulation requires a log of safety software versions uploaded after a machine is placed on the market, kept for five years. See EU Machinery Regulation 2027 and control software.
- Security programmes need a known good state. Under NIS2, being able to restore verified code after an incident is part of resilience.
- Outsourcing needs a clean hand-over point. The code should live in your repository, not on the partner's laptop.
PLC version control by platform
| Platform | Version control option | Notes |
|---|---|---|
| Beckhoff TwinCAT 3 | Integrated source control in Visual Studio, including Git | Text-based project files make diffs readable |
| CODESYS | CODESYS Git add-on, with diff, merge and branch view | Requires CODESYS V3.5.19.30 or later |
| Siemens SIMATIC AX | Native Git integration and CI pipelines | VS Code-based engineering |
| Siemens TIA Portal | Version Control Interface and multi-user engineering | Export to text formats for Git |
Beckhoff states that TwinCAT 3 integrates all engineering components into Microsoft Visual Studio and supports connection to source code management systems such as Git. The CODESYS Git add-on, version 1.7.0.0 from January 2025, brings Git into the CODESYS development system without a separate Git installation and needs CODESYS V3.5.19.30 or later. Siemens describes SIMATIC AX as a VS Code-based engineering tool with native Git integration and CI pipelines, while TIA Portal offers multi-user engineering and a Version Control Interface for exchanging project objects with external version control.
Mister Automation Ep31: Tips & Tricks - Version Control Interface
Siemens Knowledge Hub
This video is hosted on YouTube. Playing it loads content from Google, which may set cookies.
Watch on YouTubeBinary projects and how to live with them
The honest difficulty with PLC version control is that some engineering tools still store projects as binary databases. Git can store them, but it cannot show you a readable difference or merge two people's changes. The answer on each platform is the same in principle: export the program objects to text, version the text, and keep the vendor's project archive alongside for completeness. TwinCAT's file-per-object structure and CODESYS Git do this for you; on TIA Portal, the Version Control Interface handles the export for the objects you link.
Hardware configuration, HMI screens and drive parameters are often the least diff-friendly parts. Version them anyway as archives, and describe changes clearly in the commit message so a reviewer knows what to check in the tool.
A simple Git workflow for machine builders
- One repository per machine type, with a branch or tag per delivered machine.
- A main branch that always compiles, protected so changes reach it only through review.
- Feature branches for each change, named after the ticket or change request.
- Review before merge. A second engineer reads the diff. For safety code, the safety engineer reviews too.
- Tags on delivery. Every machine shipped gets a tag matching the version on its type plate and in the technical file.
- Archive alongside. Keep the vendor's own project archive with each tag, so the project can be opened even if export formats change.
Version control with outsourced teams
When we deliver a work package, we commit to the client's repository from the first day. The client sees every change as it happens, reviews merge requests, and owns the full history when the package closes. Access is removed at the end. This is the simplest answer to the question every engineering manager asks about outsourcing: what happens to our code? Our guide to outsourcing PLC programming in Germany covers the other parts of that hand-over, and engineering outsourcing from India explains the wider model.
Coding standards make diffs useful
Version control shows you what changed; a coding standard makes the change understandable. Consistent naming, small function blocks and comments in an agreed language turn a diff into something a reviewer can judge in minutes. The PLCopen coding guidelines are a good neutral base if you have no house standard. Third-party tools such as Copia also offer Git-based versioning and backups across several PLC brands, which can help in mixed plants.
Getting started in a week
Pick one active machine project. Set up a repository on your company's Git server, add an ignore file, commit the current state as the baseline and tag the version running on the machine. For the next change, use a branch and a review. After two or three changes the team will not want to go back. For plants rather than machine builders, start with the controllers on your critical lines, ideally as part of an S7-300 migration where the code is being touched anyway.
Wartens delivers TIA Portal, TwinCAT and CODESYS code into clients' repositories with reviewable history. See our automation engineering services. Next step: tell us your platform and we will share the repository structure and ignore list we use. Contact us.
