Version Control

Introduction to Version Control in FileMaker

The Essence of Version Control in FileMaker

Version control is the practice of tracking and managing changes to your FileMaker solutions—scripts, custom functions, tables, layouts and more. It’s essential in modern FileMaker development and creates a safe space for experimentation, knowing that any unwanted changes or deployments can be quickly and reliably rolled back.

Why Version Control Matters

  • History and Accountability: It keeps a history of who made which changes and when, adding a layer of accountability and transparency to the development process.

  • Collaboration: Enables multiple developers to work on either individual or shared development files.

  • Risk Mitigation: Offers the ability to quickly roll back to a previous version, reducing the risk of disruptions or significant setbacks in development.

Devin's approach to Version Control

For years, version control has been a missing piece in the FileMaker development toolkit. Devin changes that. As the first platform to offer integrated version control for FileMaker, Devin makes managing versions and branches not only possible, but seamless.

With our recent releases, we’ve taken things even further. Our new Compare Versions feature—powered by our XML Analysis API—lets developers instantly see what’s changed between their saved .fmp12 versions, with fast, GitHub-style code diffs for Scripts and Custom Functions. It’s version control built for how FileMaker developers actually work—integrated with deployment automation features you expect from tools like OttoFMS.

Branches

A branch in Devin acts as an isolated copy of a development file, named in the format <filename>_<branch>.fmp12. Each project has a default branch that we call main and the basic idea is that instead of making modifications directly to the main file, we create new branches for different purposes. For instance, a branch for development could be called dev.

Branching a File in Devin

Then, whenever we feel the dev file is stable and tested enough (see Regression Testing), we can release it back to main (or another branch). This way, main will always represent the latest stable version of our development file.

In the Project Workspace's Modules tab, developers can see an overview of all files that are part of a project. Clicking on a file will show a visual graph of branch, version and release history performed by all team members.

Overview of a Module's Branches and associated Versions

Once you add a development file to a project (see Adding .fmp12 files to a project), a copy of the file will automatically be placed on the main branch, named <filename>_main.fmp12. The original development file without the branch name will not be used by Devin and can be deleted manually.

Versions

Devin manages version control by allowing developers to save versions of the branched fmp12 files as snapshots at various stages of development. These snapshots are the equivalent to git commits, except they are either clones or full backups of the branched file. The idea is that they act as key milestones or backups of stable stages of the file, offering a straightforward way to save backups, document progress and revert back to an earlier version if needed.

Saving a Version in Devin

The Project Workspace's Branches view shows all versions for the selected branch.

Version history for selected branch

Releases

The release process in Devin offers a method to integrate changes from any branch into another. Traditional merging, common in other development ecosystems where code changes from multiple branches are combined (like with git), isn't currently possible in FileMaker due to limitations in Claris technologies. Instead, Devin's release function simply replaces the target branch file with the file from the source branch.

Releasing a Version in Devin

In the Branches view, selecting a version opens a sidebar with more information about the snapshot and buttons to perform actions such as releasing the version to another branch.

Releasing 1.3 on dev to main

While this approach does not yet support merging of branches, and thus the idea of working on parallel branches simultaneously, we're committed to enhancing these capabilities as soon as Claris technologies allow it. Until these capabilities are in place, it's recommended to designate a primary development branch as the central source of truth for your projects and use other branches for more temporary use cases such as testing or experimentation.

Last updated

Was this helpful?