PLC Version Control: Approved Versions, Git and the Native IDE Tools

PLC version control keeps every version of a controller program, records who changed it and why, and lets engineers compare versions and roll back. In a plant it has one extra job that ordinary software version control was never designed for: telling you whether the program running in the controller still matches the version that was approved, because a controller can be edited while it runs.

Two models answer that job differently. Dedicated change management tools use an approved-version workflow built around the running device. Git, which most vendors’ engineering tools now support in some form, is built around the engineer’s project. This page explains both, the native Git options now inside the vendor IDEs, why binary project files make Git hard, and how to choose. It sits under the automation change management hub.

Two models of PLC version control

The approved-version model treats each device as the unit. There is one approved version per controller, robot or HMI. An engineer checks it out, edits it in the vendor’s own software, and checks it back in, where it is reviewed and approved. Scheduled jobs upload from the device and compare it with the approved version, so an online edit made outside the process shows up as drift. AMDT’s octoplant describes this workflow on its own site, and FactoryTalk AssetCentre works on a similar principle in Rockwell estates.

The Git model treats the project as the unit. Engineers commit changes to a repository, work on branches, open a merge or pull request, and the change is reviewed before it reaches the main branch. It is how software teams work, and it suits engineering teams building and reusing code across many machines.

Dimension	Approved-version workflow	Git workflow
Unit of control	The device and its approved version	The project and its branches
Built for	Operating and maintaining a running fleet	Developing and reusing code
Detects online edits on the controller	Yes, through scheduled upload and compare	Not by itself; needs a device backup tool
Parallel development	Limited; usually one change at a time per device	Native: branches and merges
Who it suits	Maintenance, plant controls, quality and auditors	Engineering teams, OEMs, integrators
Binary project files	Handled through vendor-aware compare	Stored, but not meaningfully diffed or merged
Audit trail	Built in, with approval records	Commit history; approvals depend on the platform

Neither model is complete on its own. An OEM building twenty machines from one code base needs branches. A plant running those machines for fifteen years needs to know what is in each one tonight. That is why the market is converging: Git-native tools such as Copia DeviceLink now back up running devices, and approved-version tools are adding better engineering workflows.

Native Git in the vendor IDEs

The biggest change in PLC version control over the last few years is that the engineering tools themselves now integrate with Git or similar systems. The details vary by release, so treat the table as a guide and confirm against your version.

Engineering tool	Vendor	How it supports version control	What it means for a plant
TIA Portal with the Version Control Interface	Siemens	Exports project objects to a file workspace that an external system such as Git manages; V21 extends the Git alignment (eeNews Europe)	Git becomes practical for Siemens projects, with care over which objects are exported
SIMATIC AX	Siemens	Code-first environment built on VS Code, with text-based source and Git workflows (ARC)	Software-style development for new Siemens projects; existing TIA projects stay where they are
FactoryTalk Design Studio	Rockwell Automation	Cloud-based, with “integrated version control, change tracking and streamlined workflows for sharing, reviewing and merging” (Rockwell)	Git-style collaboration for Logix projects, delivered from the cloud
CODESYS with CODESYS Git	CODESYS Group	Add-on that stores CODESYS projects in Git repositories (CODESYS Store)	Applies to the many controllers built on CODESYS, including ABB Automation Builder
TwinCAT 3	Beckhoff	Visual Studio-based, with project items stored as separate files that work with Git (Beckhoff)	One of the most Git-friendly PLC environments
PLCnext Engineer	Phoenix Contact	Version control integration, with Git and SVN support (PLCnext help)	Git for PLCnext projects
Ignition 8.3	Inductive Automation	Gateway configuration stored as files on disk, which can be placed under Git (Inductive Automation)	SCADA and HMI configuration joins the same workflow as code

What this does not cover. Every one of these is single-vendor and engineering-side. None of them, on its own, uploads from a running device on a schedule, covers robots, drives or a 2004 controller, or produces an audit trail of who changed which device on the floor. That gap is the reason multi-vendor tools still exist, and it is covered in our PLC version control software comparison.

Why binary project files complicate Git

Git was designed for text. It stores any file, but its diff, merge and blame features only make sense when changes appear as lines.

Many PLC projects are binary. A Studio 5000 project saved as an ACD file, an RSLogix 500 file or a classic STEP 7 project is a binary or database-style container. Git will keep every version, but a diff between two of them says only that the file changed. Two engineers editing the same binary project cannot merge their work; one of them has to redo theirs.

Text exports help, with limits. Rockwell’s L5X and Siemens’ VCI exports turn a project into XML or text. The diff becomes readable, but a single moved rung can show as dozens of changed lines, and some content, such as online tag values or certain module settings, may not round-trip cleanly. Treat the export as a view of the project, and test that a re-imported project matches the original before relying on it. Our Studio 5000 project structure page explains why structure decides how readable those diffs are.

Project format	What Git sees	Practical consequence
Studio 5000 ACD, RSLogix 500, classic STEP 7	A binary or database-style container	Every version is kept, but diffs and merges are meaningless; one engineer edits at a time
Rockwell L5X and Siemens VCI exports	XML or text	Readable diffs, noisy for moved rungs; test that the re-imported project matches the original
Projects stored as separate files, as in TwinCAT 3	Many smaller XML or text files	The closest to normal software practice: per-object diffs, and merges become possible with care
SCADA configuration on disk, as in Ignition 8.3	Configuration files	HMI and SCADA changes can be reviewed in the same way as code

Repositories grow. Binary files of tens of megabytes, committed daily, inflate a repository quickly. Git LFS or a dedicated tool’s storage handles this; plain Git on a file share does not.

Diffing ladder logic

A useful compare answers what changed in terms an engineer recognises: this rung, this tag, this preset, this module. That needs a tool that understands the vendor’s format.

• Graphical, rung-level compare shows the old and new rung side by side with the changed instruction highlighted. Copia advertises “built-in rendering for ladder logic, function block diagrams, and structured text” (copia.io); octoplant’s Smart Compare offers graph, table and text views (AMDT Smart Compare).
• Vendor compare tools ship with several IDEs and compare two projects, or a project against the online controller.
• Data and configuration matter as much as logic. A changed timer preset, a modified I/O configuration or an altered safety parameter can change machine behaviour with no change to a single rung. Check that a compare covers them.

Making PLC version control stick on the plant floor

The technical choice is the easier half. Version control works in a plant when a few rules are agreed and kept.

Write down who may edit what. Online edits will always be needed to keep a line running. The rule is not “never edit online” but “every online edit is checked in, or reversed, by the next working day.” The nightly compare enforces it without anyone policing it.

Record why, not only what. A compare shows that a timer preset changed from 2.0 to 3.5 seconds. Only a change note says it was raised to stop nuisance trips on the infeed, and that the real fix is a sensor bracket. That note is what the next engineer needs.

Make integrators and OEMs part of it. Commissioning should end with the final project checked into the plant’s repository as the approved version, with the source, the passwords and the software release recorded. Our systems integrator scope of work guide shows how to put that in a contract.

Start with the lines that hurt most. Bring the most critical and most frequently changed equipment under control first. Early wins, such as a drift alert that caught a change before it caused a fault, do more for adoption than any policy.

Limits and open questions

• Process versus tooling. Version control fails when online edits bypass it. No tool fixes that without an agreed rule about who may edit what, and a compare that catches the exceptions.
• Licensing of native features. Some IDE Git features sit in higher editions or add-ons. Check what your existing licences include before assuming they are free.
• Cloud engineering tools raise the same network and data questions as any cloud service touching OT. Agree them with the OT security owner first.
• Mixed estates. A plant with five vendors may end up with five Git integrations and still need a separate tool for the running devices.

How to evaluate a PLC version control approach

• Which of your engineering tools can store projects as text today, at your software versions?
• Do you need parallel development (OEM, integrator, multi-line standards) or mostly controlled maintenance changes?
• How will online edits on the floor be detected and reconciled?
• Can the compare show rungs, tags, data values and hardware configuration in a readable form?
• Who approves a change, and where is that approval recorded?
• Will integrators and OEMs work inside the same repository and process?
• What happens to legacy controllers whose tools have no Git support?

Deeper

• octoplant version control and change management: an approved-version model in detail
• Check-in and check-out: the edit cycle in the native tool
• Change detection: separating planned from unauthorized change
• PLC backup software: the device uploads that version control depends on

If a modernization is the moment to put this in place, our control system modernization work builds version control and approval into the new system from the start.