ifc-commit

Git-native workflows for IFC

An experiment started at the Porto OpenBIM Hackathon. Live at ifcc.gitaec.org.

Background

IFC and the openBIM ecosystem have made significant progress in enabling data exchange between the many disciplines involved in a construction project. As workflows grow more complex — more actors, more iterations, more concurrent modifications — a gap becomes apparent: there is no standard way to track who changed what, when, and why across the lifetime of a model.

Git has answered this question for software development for decades, with a mature model for branching, ownership, and modification history. ifc-commit explores how that same paradigm can be applied to IFC, with the goal of contributing a useful building block to the openBIM ecosystem.

Overview

ifc-commit is a tool for working with IFC files in a git-based workflow. It allows parts of a model to be extracted, modified, and merged back — operations that can be declared in a configuration file, executed automatically, and committed to a repository with a full trace of what changed and who triggered the change.

The project covers three layers:

Command-line interface — composable operations for extracting, merging, splitting, moving, and removing IFC elements.
Pipeline system — simple configuration files that chain operations together and commit the results back to a git repository on every run.
Provenance inside the model — git metadata embedded directly in the IFC file using standard property sets, so every touched element carries a full record of who changed it and why.

Built on IfcOpenShell and hosted on gitaec.org.

Git Inside IFC

The central idea is to store git metadata directly inside the IFC file, using mechanisms that already exist in the IFC specification. This way, any IFC-aware tool — viewer, validator, or plugin — can read the provenance data without any custom extension.

Two layers are used:

File level. IfcApplication.Version stores the current commit hash as a lightweight stamp on the whole file. Every tool that reads IfcOwnerHistory sees it automatically.

Example — what this looks like in the IFC STEP file:
#2=IFCAPPLICATION(#1,'a1b2c3d4','ifc-commit','ifc-commit');

Element level. A Pset_GitCommit property set is attached to every element touched by an operation. It carries the full commit context: hash, message, author, date, and branch.

Example — reading the property set back in Python:

for rel in element.IsDefinedBy:
    if rel.is_a("IfcRelDefinesByProperties"):
        pset = rel.RelatingPropertyDefinition
        if pset.Name == "Pset_GitCommit":
            props = {p.Name: p.NominalValue.wrappedValue
                     for p in pset.HasProperties}
            # props = {
            #   "CommitHash":    "a1b2c3d4f5e6c7b8",
            #   "CommitMessage": "Fix wall thickness in level 2",
            #   "CommitAuthor":  "alice <***@***>",
            #   "CommitDate":    "2026-03-24T14:30:00Z",
            #   "CommitBranch":  "feature/level-2-walls",
            # }

Unknown property sets are silently preserved by Revit, ArchiCAD, and other tools, so the metadata travels with the model through the full exchange chain.

This makes it possible to apply the full git workflow to BIM: branches, forks, hotfixes, pull requests, and merge reviews — with every element carrying a traceable record of who changed it and from which branch.

Pipeline System

An ifccommit.yaml file in any repository declares which operations to run:

operations:
  - name: extract-structure
    command: extract
    input: models/full.ifc
    output: dist/structure.ifc
    types: [IfcWall, IfcSlab]

  - name: split-by-storey
    command: split
    input: models/full.ifc
    outdir: dist/storeys/

  - name: apply-modification
    command: replace
    base: models/full.ifc
    space: A102
    part: dist/team_updates.ifc
    output: dist/merged.ifc

The web app fetches this file from the forge, shows a preview of the operations, and streams execution logs in real time while committing the results back to the repository.

IFC Compliance

A deliberate design constraint is that ifc-commit introduces no proprietary extensions. Every mechanism it relies on is already part of the IFC specification:

IfcOwnerHistory — the native per-element change record, carrying timestamps, authorship, and change action.
Pset_GitCommit — a custom property set following the standard extension pattern. Tools that do not recognise it silently preserve it; tools that do can surface full git provenance per element.
IfcApplication.Version — a zero-overhead file-level stamp holding the current commit hash.

Because custom property sets survive round-trips through Revit, ArchiCAD, and other tools, the metadata travels with the model through the full exchange chain — without requiring any plugin or custom viewer.

For a detailed account of the research behind this approach — the IFC mechanisms surveyed, the tradeoffs considered, and the implementation — see the research notes.