Managing a PLC project without version control means accepting avoidable risks: accidental overwrites, weak traceability, slow rollback and uncertainty about which version is actually running in production. Git is a strong answer for industrial automation too, but one point must be stated clearly: TIA Portal does not behave like a software IDE with a full built-in Git client. The correct workflow relies on the Version Control Interface (VCI), file-system workspaces and, in newer versions, SIMATIC Source Documents (SIMATIC SD).

Key correction: in TIA Portal V20/V21 Siemens documents integration with external version control systems such as Git through the Version Control Interface. The official documentation explicitly states that TIA Portal does not interact directly with the version control program: both access the same workspaces on the file system. Official V21 VCI manual →

Why automation really needs Git

In an industrial plant, PLC software has operational, maintenance and security implications comparable to software in IT. Git does not solve every problem on its own, but it meaningfully improves four areas:

  • Traceability — you know who changed what, when and why
  • Rollback — you can return quickly to a known baseline
  • Collaboration — the team works with branches, reviews and controlled integration
  • Auditability — change logs, tags and approval policies support change management

This does not mean Git alone guarantees compliance. It does mean it provides a much stronger technical foundation than shared folders, manual backups or files named Project_final_v7_final_2.

What Siemens actually supports

The Siemens documentation describes three key elements:

  1. Version Control Interface (VCI) — links TIA project objects to files exported into one or more workspaces
  2. External versioning tools — Git, Subversion or similar tools working on those files
  3. Text-capable export formats — XML, object-specific formats and, in newer versions, SIMATIC SD

This distinction matters because it prevents a common mistake: describing "native Git in TIA Portal" as if the official workflow exposed commands like Initialize Git repository, Commit, Push and remote management directly inside the IDE. In the official Siemens sources verified for this article, that workflow is not documented.

Realistic prerequisites

TIA PortalV20 or V21 recommended for mature VCI workflows and SIMATIC SD; earlier versions are possible but more limited
Version controlGit installed and kept reasonably up to date, using a CLI or external GUI client
PlatformGitLab, GitHub, Gitea, Azure DevOps or a self-hosted Git server
SkillsCommit, branch, merge, tags and basic conflict handling
Useful historical note: VCI did not start in V21. Siemens already documented in TIA Portal V16 the connection of external versioning tools such as Git and Subversion, with block comparison through the UI or third-party tools. V16 engineering options →

1. The correct model: TIA project, workspace and Git repository

The most robust model is not to blindly version the whole binary TIA project folder, but to version the files exported from the project into a workspace. In practice:

TIA Portal project
        ↓
Version Control Interface (VCI)
        ↓
Workspace on the file system
        ↓
Git (CLI or external GUI client)
        ↓
Local/remote repository

In this model, TIA Portal manages the association between project objects and workspace files, while Git tracks changes in the exported files.

2. Recommended repository structure

There is no single structure imposed by Siemens, but this layout is practical and aligns well with industrial workflows:

plant-project/
├── .gitignore
├── .gitattributes
├── README.md
├── workspace/
│   ├── plc/
│   ├── hmi/
│   ├── types/
│   └── libraries/
├── docs/
│   ├── commissioning/
│   ├── electrical/
│   ├── functional-specs/
│   └── changelog.md
├── scripts/
│   ├── export-vci.ps1
│   ├── backup-online.ps1
│   └── compare-workspace.ps1
└── test/
    └── plcsim/

The workspace/ directory is the key part: it contains the exported objects that Git can meaningfully diff and track.

.gitignore: what to exclude

Temporary files, cache and logs generally should not go into the repository. A cautious example:

# Temporary and backup files
*.tmp
*.bak
*.compiled

# Cache and logs
**/Cache/
**/Logs/
**/UserFiles/
**/.Trash/
**/BackupCopies/

# Regenerated compile information
**/*.compileinfo

# Operating system files
Thumbs.db
desktop.ini
.DS_Store

Questo elenco va adattato al progetto reale. Siemens non documenta la generazione automatica di un .gitignore ottimizzato da parte di TIA Portal, quindi conviene predisporlo e mantenerlo manualmente nel repository.

⚡
Git LFS: can be useful for large binary files, HMI graphic assets or technical attachments. It is not a Siemens requirement, but often a practical choice when repository size starts to grow too much.

3. Correct setup in TIA Portal V20/V21

The correct workflow with TIA Portal V20/V21 is:

  1. Open the project in TIA Portal
  2. Configure the Version Control Interface
  3. Create one or more workspaces on the file system
  4. Define export formats for supported object types
  5. Connect project objects to workspace files
  6. Synchronise project and workspace
  7. Version the workspace with external Git

For file comparison, Siemens also documents the configuration of an external comparison program. This is an official VCI feature, not a workaround. Configure an external comparison program →

4. Export formats: it is not just “XML”

Another common oversimplification is to say that TIA versioning is simply based on “XML export”. In reality Siemens uses different formats depending on the object type. In VCI documentation, for example:

  • LAD / FBD / GRAPH — historically exported as XML in the classic VCI workflow
  • SCL and STL — can use XML or block-specific formats, depending on configuration
  • DB and UDT — may use specific formats in addition to XML
  • HMI Unified scripts — exported as text files such as JavaScript and YAML in VCI workflows
  • V20/V21 — introduce and extend SIMATIC SD as a more readable text format better suited to versioning

Because of this, the statement “Project → Export → SimaticML and then Git” is too narrow. SimaticML and Openness remain important, but the actual picture is broader. Official export format overview →

5. SIMATIC SD: the practical turning point for version control

One of Siemens’ most useful improvements is SIMATIC Source Documents (SIMATIC SD), text-based files meant to be easier to read, edit and version than older formats.

In V20 Siemens highlights SIMATIC SD support for LAD, DB and PLC data types. In V21 support is extended to FBD, SCL and mixed-language blocks. This is probably the real breakthrough that makes Git much more practical in TIA Portal, more than any claim about “native Git”. What’s new in V21 – SIMATIC STEP 7 →

Siemens explicitly states that files exported in SIMATIC SD can be used independently of TIA Portal, edited with any text editor and managed in a version control system. Official SIMATIC SD guide →

6. Which objects are actually suitable for version control

VCI does not cover “the whole project” indiscriminately. Siemens documents versioning for several object types, including:

  • OBs, FBs and FCs
  • Data blocks and PLC data types
  • PLC tag tables
  • Technology objects
  • Global scripts for HMI Unified
  • Project library types in V21

There are also explicit limits. Siemens flags the following as unsupported or restricted depending on the case:

  • CEM blocks
  • Blocks with know-how protection
  • Password-protected fail-safe objects when the password is not known

So it is correct to say that Git + VCI significantly improve PLC project version control, but it is not correct to promise perfect and universal traceability for every single TIA artefact. Official VCI limitations →

7. Recommended branching workflow

A simple model works well for PLC projects:

main              ← released / production baseline
  └── develop     ← integration branch
       ├── feature/new-washing-cycle
       ├── feature/safety-alarms
       └── hotfix/fix-axis3-encoder
  • main contains approved versions that have been downloaded or are ready for deployment
  • develop integrates validated changes in simulation or test environments
  • feature/* isolates each meaningful functional change
  • hotfix/* handles urgent corrections starting from the actual field baseline

This model is not mandated by Siemens, but it aligns well with plant requirements: stability, quick rollback and a clear separation between development and production.

8. Commit messages matter more than most teams think

A good commit should say what changed, where and ideally why.

Weak messages

fix
update
various changes
test
Useful messages

Fixed axis 3 encoder timeout in FC30 and DB_Axes
Added CIP cycle for washing station in FB40
Updated HMI Unified diagnostics for furnace 2 alarm
Hotfix: corrected PT100 scaling on drying line

9. Conflict handling: no unrealistic promises

Conflicts do not disappear with Git; they become more manageable. The accurate message for TIA Portal is:

  • VCI allows comparison between project objects and workspace files
  • Siemens documents the use of external comparison tools
  • text-based formats such as XML, SCL, DB, UDT and especially SIMATIC SD make diff much more useful
  • binary files remain harder to merge and still require team coordination

The correct claim is not “TIA performs Git merges like a modern software IDE”, but rather: TIA provides a concrete basis for comparison and synchronisation, while Git versions the exported files.

10. CI/CD: possible, but through Openness and external tooling

For more advanced teams, Siemens provides TIA Portal Openness, which enables engineering automation. The official documentation covers, among other things:

  • opening and managing projects
  • compiling devices and blocks
  • downloading hardware and software to PLCs

This means workflows such as workspace export → commit → CI pipeline → compile check → validation → controlled download are realistic, but not because TIA Portal includes built-in CI/CD. They are possible through Git + external pipelines + Openness API. Compiling via Openness → · Downloading to a PLC via Openness →

11. Security and compliance: what can be said without overstating it

Git strongly improves audit trails, role segregation, review practices and release control. That supports change management practices that matter in regulated and industrial environments. But it would be inaccurate to claim that IEC 62443 or NIS2 “require Git” or that using Git alone amounts to compliance.

The more rigorous wording is this: Git is an excellent technical enabler for change control, review and traceability, but compliance also depends on governance, procedures, access management, backup, incident management and operational security.

12. A genuinely useful getting-started checklist

1. Choose the baselineIdentify with certainty which version is currently in production
2. Enable VCIConfigure workspaces, export formats and a comparison tool
3. Pick the right formatsUse SIMATIC SD where available; otherwise XML or object-specific formats
4. Create the repositoryVersion the workspace and the technical documentation
5. Define branchesmain, develop, feature/*, hotfix/*
6. Protect releasesTags, mandatory reviews and merge policies
7. Train the teamAtomic commits, clear messages and rules for PLC synchronisation

Our take

Git makes sense for PLC projects, but it works well only when adopted through the correct model. The most common mistake is to try to use TIA Portal as if it were a software IDE with a built-in Git experience everywhere. The Siemens-documented reality is more sober but also more practical: versioned workspaces, readable exports, external comparison tools and automation through Openness.

It is less “magical” than some articles make it sound, but it is still a major improvement over manual copies, sporadic backups and untracked change management.

Want to introduce a serious Git workflow into your automation projects?

Start from a stable baseline, choose the right export formats and define simple rules. The technology matters, but the team process matters even more.

Official resources and useful guidance