Skip to main content

File History & Restore

Coming soon

Per-file history and restore is on the way. This page previews what it will do; we'll update it when the feature ships.

Overview​

Every file in your project - dashboards, models, datasets - will get its own File History: a timeline of every version of that file, showing who changed it, when, and why. From that history you'll be able to restore a single file to any past version without touching anyone else's work.

Today, restoring a past version works at the project level: rolling back reverts the entire project, including teammates' unrelated changes since then. File history makes rollback precise - one file, nothing else.

Key capabilities​

  • Trace a file's history - see every version with author, timestamp, and commit message, plus what each version changed.
  • Restore a single file - roll one file back to a past version. Only that file changes.
  • Duplicate to a new file - fork a past version into a new file to preview or compare, leaving the current file untouched.
  • Jump to project history - if a change spanned several files, open the full project history at that point to see everything that moved together.

How it works​

Open a file's History panel to see its version timeline. Each entry shows who made the change, when, and why, and you can open any version to see exactly what it changed.

When a version is captured depends on your project's version-control mode:

  • On Git flow (explicit commits), a new version is recorded each time you commit.
  • On non-git flow (auto-commit), every change you make is captured automatically as you work - no manual commit needed.

Restoring affects only the file you're viewing. A single commit often touches several files at once. When you restore from one file's history, Holistics rolls back only that file's changes from the version you picked - every other file stays exactly as it is.

What happens when you restore also depends on your mode:

  • On Git flow, the restored file appears as an uncommitted change, so you can review it one last time before committing it yourself.
  • On non-git flow, the restore is committed automatically, like any other save.

You can also duplicate a past version to a new file to compare side by side without overwriting your current work. And because history is preserved, a restore is itself just another change - if it wasn't what you wanted, restore again.

Open Markdown
Let us know what you think about this document :)