When developing FileMaker solutions, one of the issues that always comes up is the lack of Version control options. How can you use Version control with FileMaker, and what is it? Read this article to find out.

When developing software, Version control works by comparing changes in files over time. It allows you to implement a change or feature, and then document those changes to see what has changed. It also allows you to roll back to states in the development cycle history.

How does it work?  Imagine you are writing a sentence, “Hello World!”, you save it in a file that stores the content as text. You then commit that to a Version control system calling the commit something like “My First Sentence”. Then you change the sentence to “Hello big world!”, save and commit that to the Version control system and call it something like  “I added the word big”. The Version control system would now have a history of the changes you made, and you would be able to see the differences that you made. In this instance you added the word “ big” to the sentence. This works because the file is stored as text and any changes to the file can be compared and you can see differences between changes. It also makes storing references to those changes small because it only records the changes and doesn’t store the entire file over and over again with each change.

This isn’t the same with a FileMaker file. While you can store the changes that you make to a FileMaker file, you won’t know what those changes are. This is because the FileMaker file is a binary file and is not stored in a text format that can be easily compared. When changes are made, the entire binary file changes. This means you can’t easily see what change has been made, you can only see that the file has changed. It also means that you are storing a complete copy of the file each time you commit it to your Version control system.

So how can you leverage Version control to see the development changes that you make to a FileMaker file? One process we have come up with, is to utilize the Database Design Report  (called DDR) for the file as you work on it. It adds a little bit of overhead, but provides you with detailed files about design changes that can be compared. Geist Interactive has a great article on how to create a DDR

Once you have created a DDR for your FileMaker file, you can then use Version control on the DDR files. When you make design changes to the FileMaker file, and are ready to commit them to Version control, re-create the DDR. Using Version control on the DDR will show you those changes between commits of the DDR. Although the DDR is extremely verbose and difficult to navigate, it can still prove to be useful when tracking changes.

Finding and configuring Version control can be a little daunting. I like to use Github or GitLab to store the repositories and I like to use GitKracken to compare differences and make my commits.

Using these tools makes it easy. I won’t go into lengthy detail of how to set it all up, but I will outline the process.

1. Create a git account with a provider ( or host your own )

2. Configure GitKracken to connect to that account

3. In GitKracken, Initialize (Init) a new repository to a folder on your machine. Then open the repo. This is where you will store the files you will be monitoring with Version control.

4. Put the FileMaker files* into the repository folder you created, and generate a DDR into that same folder.

5. Commit the changes that you have made to that repository – this will push all the files in the repo folder to the git host.

6. After making some changes to the FileMaker file, generate the DDR again ( overwriting the existing DDR)

7. Commit the changes that you have made to that repository.

8. Repeat 6 and 7 as needed.

*You may or may not choose to store the FileMaker file itself in the repository. For smaller FileMaker files, I like to store it in the repository. This allows me to roll back to a design state while I am developing the solution. The drawback is that the FileMaker file is stored in its entirety and the repo will rapidly grow in size depending on the size of the FileMaker file.

Another option, is to develop on a hosted FileMaker solution.  Scheduling regular backups can provide you the option for recovery of the FileMaker file at different stages without bloating the repository. Then you can forgo adding the FileMaker file itself, and just use the DDR. Later, if you need to recover the file at a specific state you would pull that copy from server backup.

~Xandon Frogget