# Version Control

## 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](https://docs.devin.fm/guides/versions/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`.

<figure><img src="https://3674518083-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4WyrF9yRB5bw5h1SRZke%2Fuploads%2F6uc32yhKrU3b3sqmO91t%2FBranching3.jpeg?alt=media&#x26;token=cec350dc-bec5-4713-bd0a-9bbdf4052f9d" alt=""><figcaption><p>Branching a File in Devin</p></figcaption></figure>

Then, whenever we feel the `dev` file is stable and tested enough (see [regression-testing](https://docs.devin.fm/features/regression-testing "mention")), we can [release](#releases) 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.

<figure><img src="https://3674518083-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4WyrF9yRB5bw5h1SRZke%2Fuploads%2Fou8EWj7g6YO0dGQ8kJ5d%2FBranches3.jpeg?alt=media&#x26;token=97f8cee0-cf94-4c96-b496-cf41baf1d8f1" alt=""><figcaption><p>Overview of a Module's Branches and associated Versions</p></figcaption></figure>

{% hint style="info" %}
Once you add a development file to a project (see [Adding .fmp12 files to a project](https://docs.devin.fm/getting-started/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.&#x20;
{% endhint %}

### 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.

<figure><img src="https://3674518083-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4WyrF9yRB5bw5h1SRZke%2Fuploads%2FTa11IyzHFBZGosoqMr9X%2FVersioning4.jpeg?alt=media&#x26;token=705ef50c-7918-43e8-ac2f-24a58f100acd" alt=""><figcaption><p>Saving a Version in Devin</p></figcaption></figure>

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

<figure><img src="https://3674518083-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4WyrF9yRB5bw5h1SRZke%2Fuploads%2FBdc0pCE6Ucsc57kmEG8N%2FVersionHistory.jpeg?alt=media&#x26;token=6d9fe953-82a8-40f5-ab46-8be2c66b1581" alt=""><figcaption><p>Version history for selected branch</p></figcaption></figure>

### 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.&#x20;

<figure><img src="https://3674518083-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4WyrF9yRB5bw5h1SRZke%2Fuploads%2Fdra3lUXbj2WL399CEfPg%2FReleasing3.jpeg?alt=media&#x26;token=73a7dce8-07fa-44e4-8ffe-34ba3b244fb5" alt=""><figcaption><p>Releasing a Version in Devin</p></figcaption></figure>

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.

<figure><img src="https://3674518083-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4WyrF9yRB5bw5h1SRZke%2Fuploads%2FgmrtSwGsrkKE0gBgR9No%2Frelease7.jpeg?alt=media&#x26;token=3584f0d8-863a-45bf-9497-2df839cdb795" alt=""><figcaption><p>Releasing 1.3 on <code>dev</code> to <code>main</code></p></figcaption></figure>

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.