Summary
Everything you produce in Linkr — projects, plugins, scripts, schemas, wiki — is versionable and shareable. Two mechanisms coexist: ZIP export / import, available everywhere with no installation, and git integration, to link projects and workspaces to remote repositories.
Why versioning matters
A study, a dashboard, an analysis plugin represent work you want to keep, find again and pass on. Without versioning, every analysis starts from scratch and nothing circulates between teams. So Linkr treats projects and workspaces as objects you archive, share and version — just like code.
This follows directly from a principle seen in the previous chapter: a project is a file tree (entity.json, scripts/, cohorts/, dashboards/…). Versioning a project means versioning those files. See Workspaces and projects.
Two ways to share
ZIP export / import
Download a whole project or workspace as an archive, re-importable into any Linkr instance. Available in both modes, no backend.
Git integration
Link a project or workspace to a remote repository (GitLab, GitHub). Cloning on import works everywhere; push / pull needs server mode.
ZIP export / import
This is the simplest path, available right away. You download a project — or an entire workspace — as a ZIP archive, then re-import it elsewhere. Re-importing the same entity updates it in place rather than creating a duplicate: every entity carries an identity that follows it from one instance to another. It is the recommended way today to back up your work and pass it to a colleague or another centre.
Workspace export is granular: you choose what to include (projects, wiki, schemas, databases, SQL scripts, ETL, mappings, plugins), and you can strip connection credentials from databases so passwords are never exported.
Git integration
A project, a workspace — but also a SQL script collection, an ETL pipeline or a mapping project — can be linked to a remote git repository. Cloning (fetching a repository on import) works in client-only mode. Push and pull need server mode, which alone ships a git client.
Pulling happens item by item: Linkr shows what is coming from the repository and you decide on each entry — accept or decline. What you decline stays yours and comes back as a change to push. Until every entry has a decision the pull is not finished, and while the repository is ahead of you the push is blocked: you never push over someone else’s work without having seen it.
Data files are excluded by default: you explicitly mark the ones to version, file by file. Large files can go through Git LFS.
What depends on the mode
ZIP export / import and git cloning on import work everywhere, including in the browser. Push / pull and multi-user management need server mode: a browser has no git client. See Deployment modes.
The “git links” pattern
How do you share a workspace containing dozens of projects without duplicating everything into one giant archive? Linkr uses an approach inspired by git submodules.
When a project (or other content) is linked to its own git repository, the workspace export does not carry its full content: it carries only its metadata and a pointer to the repository. The workspace then becomes a manifest of links rather than a large monolithic block. At deployment time, each linked repository is cloned and the full content is reconstituted.
The benefit is direct: each team versions its projects in its own repository, at its own pace, then links them into a shared workspace. You combine each team’s autonomy with a pooled overview — without copying the same files in ten places.
Deploying a pre-loaded instance: Linkr Portal
Reassembling these linked repositories at deployment time is handled by a dedicated tool, Linkr Portal: it aggregates the Linkr code and the content repositories, reconstitutes the workspaces and publishes a pre-loaded Linkr instance (for example on GitLab or GitHub Pages), with an optional split between public and private content. Its setup will be detailed in the Administration section (coming soon).
Tracing origin and versions
Sharing means knowing where a resource comes from and how it evolved. Plugins carry a built-in traceability for this.
Plugin traceability
Each plugin keeps: a content hash (a technical identifier recomputed on every save, distinct from the human-readable version number), its origin (creator, organisation, repository), an optional lineage (the version it was forked from) and a changelog. You can thus tell precisely which version of a plugin produced a result, and trace the lineage of a plugin picked up and adapted by another centre.
Collaborating
Collaboration rests first on shared workspaces: a common container where several people find the same projects, databases, plugins and wiki. See Workspaces and projects.
In full-stack mode, a workspace will have members with roles — admin, editor, viewer — that determine who can edit, publish or only view. This access control and authentication belong to the backend and are planned, not yet available.
Standardisation, from the bottom up
This sharing machinery serves a conviction: standardisation in healthcare works better when it emerges from the field than when it is decreed in advance.
Each team starts by solving its local problems — cleaning its data, aligning its vocabulary, writing its analysis scripts. By then sharing projects, plugins and mappings via git or ZIP, good practices circulate, are picked up and adapted elsewhere. Standardisation is thus built gradually, through adoption, instead of being imposed from above.
No effort is wasted: data cleaning, semantic alignment, analysis scripts — everything produced for one study feeds the next.
This is the collaborative counterpart of cumulative investment: quality and reusability build up project after project, team after team.
Further reading
- Workspaces and projects — the shared container and the unit of work.
- Concept mapping — evaluation — multi-reviewer review in practice.
- Deployment modes — what the full-stack mode unlocks.