BLOG / TIA-PORTAL

Version Control for TIA Portal Projects: Git, Workspaces and What Actually Works

16 May 2025 TIA PortalGitVersion ControlEngineering

Software teams stopped emailing zip files twenty years ago; automation is finally catching up. Recent TIA Portal versions can export a project as a workspace of readable files suitable for Git — a real step beyond archiving .zap files.

What you get

The workspace export serializes blocks and configuration into structured files, so Git shows history, authorship and — within limits — diffs of PLC code. Combined with a normal Git server (Gitea self-hosted works fine on a plant network) you get:

  • Every change traceable to a person, date and commit message.
  • Branches for the risky experiment that used to be “Copy of Project_final_v2_REAL”.
  • A clean answer to auditors and customers asking for change history.

Honest limits: diffs of graphical languages are structural rather than pretty pictures; merging parallel PLC work through Git remains harder than in text-based languages — Multiuser Engineering still owns hot parallel development, and Git owns history and releases. The combination is the current best practice.

The discipline that outranks the tool

Commit at functional milestones with messages a stranger understands; tag every version that ran production; never let the only copy live on the commissioning laptop. Teams that manage this with plain .zap archives beat teams with Git and chaos.

FAQ

Which Portal version do I need? Workspace/Git support arrived in the V19-era toolchain and is improving each release — check the exact feature level of your version before promising a workflow.

Binary .zap in Git as fallback? Works for history (Git LFS recommended); you lose diffing but keep the audit trail. Better than the USB stick either way.


Zone Otomasyon delivers projects with version history included — ask your last integrator for theirs. Our engineering standards.