The Complete Guide to Version Control for TIA Portal Projects

December 18, 2025 · tia-portalgitversion-controlvcisiemens

Version control for PLC projects is one of those things that every automation engineer knows they should do, but few do well. Unlike software development, where Git is second nature, the PLC world has struggled with version control because our project files are mostly binary.

I have used three different approaches over the past few years, each with increasing capability. This guide walks through all three so you can choose the right approach for your situation.

Why Version Control Matters for PLC Projects

If you have ever opened a TIA Portal project and wondered “what did I change last week?” or needed to roll back a change that broke something, you already know why version control matters. But it goes beyond that:

• Safety net. You can experiment with new logic knowing you can always go back.
• Audit trail. Track what changed, when, and why.
• Collaboration. Multiple engineers can work on the same project (with the right setup).
• Customer requirements. Some industries require documented change history for compliance.

The question is not whether to use version control – it is which approach fits your workflow.

Level 1: Plain Git on TIA Portal Project Folders

This is the simplest approach and the one I started with. You do not need any TIA Portal add-ins or special configuration. Just Git.

How It Works

1. Install Git (search for “Git installer” – it is free).
2. In your TIA Portal project folder, right-click and select “Git GUI.”
3. Create a new repository in the current folder.
4. Stage your changes and write a commit message. Make each message descriptive enough that you will understand what changed when you read it six months later.
5. Commit.

That is it. Each modification you make – commit. Want to try an experimental feature? Create a branch. Need to restore a previous version? Check it out in Git, then open TIA Portal – it loads whatever version is in the folder.

What You Get

• Free and simple. No add-ins, no subscriptions, no configuration in TIA Portal.
• Full project snapshots. Everything is versioned – PLC code, hardware configuration, HMI, the whole project.
• Branching and rollback. All of Git’s workflow tools are available.
• Cloud backup. I keep my projects in OneDrive, so the project folder including the .git folder syncs to the cloud automatically.

The Limitations

This approach has real drawbacks that you should understand:

• Binary files. TIA Portal projects are stored as binary files (.ap19, .ap20). Git cannot show you what changed between versions – it just says “binary files differ.”
• No meaningful diffs. When you change one line of ladder logic, the entire binary project file changes. You cannot see what changed without opening TIA Portal.
• No merging. If two engineers work on different parts of the code, Git cannot merge their changes. You would have to manually recreate one person’s work.
• No code review. Pull requests on GitHub or GitLab are useless because they just show “binary files differ.”
• Large repositories. Each commit stores the full project file again, so repository size grows quickly.

For a solo developer working on moderately sized projects, these limitations are acceptable. For teams or larger projects, you need something more.

Level 2: TIA Portal VCI in V20

TIA Portal’s Version Control Interface (VCI) solves the fundamental problem with plain Git: it converts your program blocks to text-based formats that Git can actually work with.

The Key Difference

Instead of versioning the binary project file, VCI exports each program block (OBs, FBs, FCs, DBs, tag lists, UDTs) as a separate file. SCL blocks stay as plain text. Ladder and FBD blocks are exported as XML. This means:

• Readable diffs. You can see exactly which ladder rung changed, not just “binary files differ.”
• Granular commits. Changed one FB? Only that file shows up in the commit. Not the entire 500MB project.
• Real merging. Two engineers can work on different function blocks simultaneously. Git merges their changes cleanly as long as they edited different blocks.
• Code review. Pull requests on GitHub show actual logic changes. Teams can review and comment on specific changes.

How to Set It Up

1. Create a separate folder for your Git repository (not inside the TIA project folder).
2. Initialize a Git repo in that folder.
3. In TIA Portal, go to the Version Control Interface section in the project tree. Create a new workspace and configure it to point to your repo folder. In TIA V20, this works natively – no add-in required. Previous versions needed the Git connector add-in.
4. Drag and drop your PLC from the project tree into the VCI workspace window. This adds your PLC project to the repo scope.
5. When objects change, they show up with a || symbol in the Action column, meaning VCI does not know which direction to sync. Click the right arrows to export to VCI, then click Sync.

Important: VCI only stages the exports. You still need to go to your repo folder and commit with Git (command line or Git GUI). To restore a version, check it out with Git first, then import in VCI.

What VCI Does Not Cover

VCI versions your program blocks (OBs, FBs, FCs, DBs, UDTs, tag lists) but not the full project. Hardware configurations and HMI projects are not included.

My workaround: for major milestones, I create a TIA Portal project archive and store it in OneDrive or SharePoint, which handles versioning for the complete project. VCI covers the day-to-day code changes.

Level 3: VCI in TIA Portal V21 – Human-Readable Diffs

TIA Portal V21 brought the most significant improvement to version control: a new export format called Simatic Source Documents (Simatic SD). This changes everything for anyone working with graphical programming languages.

Why This Matters

In V20, Ladder and FBD blocks exported as XML. While technically text-based, XML diffs are practically unreadable. You might see that something changed, but understanding what changed requires careful parsing of XML tags.

Simatic SD exports Ladder and FBD code in a format that is actually human-readable. Git diffs now show meaningful changes that you can understand at a glance. If you work with graphical languages – and most of us still do, even if we prefer SCL – this is a major step forward.

Setup Tips for V21

The workflow is similar to V20, but with important details:

1. Create a new workspace in the VCI interface menu.
2. Open the workspace and set the path to your version control folder.
3. Set the export format immediately. This is critical – you cannot change it later. Select Simatic SD for Ladder and FBD files. Keep .scl for SCL, .udt for UDTs, and .db for data blocks, since these are already readable text formats.
4. Drag and drop your PLC (and types library if you have one) into the VCI window. Before you do this, none of the sync buttons will work.
5. Sync and commit as before.

The Synchronization Workflow

This is where V21’s VCI can get confusing. When you modify files and open the VCI window, you will see changes marked with || in the Action column. This means VCI does not know which direction to synchronize.

• To send changes to VCI (after editing in TIA Portal): click the right arrows button, then click Sync.
• To pull changes from VCI (after editing in an external editor): click the left arrows button, then click Sync.

A confusing detail: both “Export All” and “Export Changes” seem to give the same result. “Export All” still only exports changed files. New files will not export automatically – you have to drag them into the VCI area first.

VS Code Integration

Here is a workflow I find very productive: after setting up your VCI folder, you can edit source files directly in VS Code (or any text editor). When you finish editing, just import from VCI using the left arrows. This skips the extra steps of importing through the External Source Files menu, making the workflow much faster.

Which Approach Should You Choose?

Plain Git if you are a solo developer, want maximum simplicity, and do not need to see code diffs. It is free, requires no setup in TIA Portal, and gives you full project snapshots including hardware and HMI.

VCI in V20 if you need code-level version control with real diffs, work in a team, or need code review workflows. Accept that you will also need a separate strategy for hardware and HMI versioning.

VCI in V21 if you work with Ladder or FBD and want truly readable diffs. The Simatic SD format makes version control for graphical languages practical for the first time. This is the approach I would recommend for any new project starting on V21.

Regardless of which approach you choose, the most important step is choosing one and using it consistently. Even plain Git on the project folder is infinitely better than no version control at all.

Planning a project? Contact us to discuss how we can help.