Skip to content

You are viewing documentation for Instruqt 2.0 Labs which is in Beta currently. Official release date - 29 September, 2026. For Tracks documentation, please visit docs.instruqt.com.

Overview


The version control feature allows you to collaborate in real-time across the UI and code workflows without accidentally overwriting each others changes and gives you a history of all changes.

Multiple team members can work on the same content at the same time without risk of overwriting each other’s changes. If there are conflicting changes made by multiple users, they can be compared, resolved and merged directly in the UI or using git from the command line.

All changes made to content are stored, and function as an audit log showing who changed what, when, and why the changes were made. The changes include the creation and deletion of files as well as edits to their contents.

Having the complete history and being able to annotate each change with the date, an author and a message describing the purpose and intent of the change, enables you to revert back to previous versions. This capability is crucial when needing to fix problems and being able to compare changes with earlier versions of the content. For instance when doing root cause analysis of bugs, or when trying to figure out why a certain change was made.

If you are already using version control systems such as GitHub, the new integration allows you to connect your GitHub organization directly to Instruqt without the need for GitHub actions and the Instruqt CLI to push your content. This enables you to use your standard git workflow best practices already adopted by your organization.

Branches are parallel working copies of a lab. Switch between them with the branch selector in the top bar; the whole editor — instructions, sandbox, tabs, and layouts — reflects the branch you currently have selected.

You create a branch when you publish: in the Save changes dialog choose Save to new branch… and give it a name (see Editing & Publishing). Your changes are committed to that new branch instead of the one you started from.

Each branch can be launched, played, and previewed on its own, independently of the live version. That makes branches a good fit for keeping a purpose-built version of a lab around, for example:

  • A work-in-progress version you’re still building, kept separate until it’s ready.
  • A variation tailored to a specific audience or customer, maintained alongside the main version.

Because each branch is independent, you can edit and play any of them without touching the live version.

A tag is a frozen, point-in-time version of a lab. Where a branch keeps moving as you publish to it, a tag captures the lab exactly as it was at one moment and never changes.

Tags are useful when you need to return to the exact version a group saw — for example the version a specific cohort ran — even after the lab has continued to evolve.

Tagged versions appear in the Tagged versions tab of the branch selector, alongside the Branches tab. Switch to a tagged version there the same way you switch branches, to view or play the lab exactly as it was when the tag was created.

While we continue to improve Labs, there are a few current limitations you should be aware of:

  • Version Control only integrates with GitHub. Other platforms are not supported yet.
  • While you can import a lab from a mono-repository, Labs created through the UI cannot be connected to remote repositories that already contain files.
  • Only Labs using / as their Lab directory can be disconnected. If you import a Lab from a GitHub repository, you will only be able to disconnect it if its path is set to /.

We are actively working to lift these restrictions in future updates.