Using git for Ignition project version control

I have been trying to use git for version control on an Ignition perspective project, and I have ran into some issues. I am running a gateway at my work station, so that I can make changes to my project and test them locally before integrating the changes into production.

I initialized a git repo in my projects folder, created a development branch, then created another branch to work on refactoring a few of the scripts on one of the views in my project. After refactoring the code and making several commits, I tried to checkout my development branch:

$ git checkout development
Unlink of file 'com.inductiveautomation.perspective/session-props/props.json' failed. Should I try again? (y/n) y

I figured that it failed to unlink some of the files because I still had the gateway running in the background, so I stopped that, but still got the same message. Not knowing what to do, I told git to not try again for all the files that it couldn’t unlink, so now I am in my development branch with a whole list of untracked changes that belong in the other branch.

I am beginning to think that my life might be easier without using git with Ignition, but I wanted to check here first to see if I am doing it wrong, or if somebody else has a solution to version control in Ignition.

Thanks in advance!


I’m trying to set up the same type of development environment you describe (gateway on localhost using multiple Git branches in a project), but I’m struggling with it. Switching branches in Git does not consistently update the project in the Designer. None of the following steps seem to force the Designer to load the branch’s files:

  • update project (Ctrl+Shift+U)
  • reopen the project
  • close and reopen the designer
  • delete the .resource directory in the projects directory

Eventually, the Designer does seem to detect a change, and I’m able to use the “Update Project” function, but it’s unclear what triggers this. It just happens at random a minute or two after switching branches.

If anyone has any advice about how to properly switch branches in an Ignition project, I’d love to hear it.

1 Like

What version are you using?

As of 8.1.0 the filesystem is only scanned every 5 minutes for changes.

This can be modified to e.g. every 30 seconds by setting
in the additional parameters section of ignition.conf.


Thanks! We’re using 8.1.1. I’ll give this a try and see how it works.

Do we just add -Dignition.projects.scanFrequency=30 at the bottom of the ignition.conf file?

Also, what’s the meaning of the -D at the beginning? I noticed this other forum post that doesn’t include the -D.

No you add it to the “Java Additional Parameters” section.

It might end up looking something like this:

# Java Additional Parameters,server=y,suspend=n,address=*:8000

You’ll have to pay attention to whatever your own parameter numbers are and make sure they increment.

Unlink of file 'com.inductiveautomation.perspective/session-props/props.json' failed. Should I try again? (y/n) y

Do you have permissions? I just made a thread about having to run Git as admin since the project files live in Program Files

I’ve changed the ignition.conf file, and this appears to work. Is there a different way we can trigger Ignition to scan the file system immediately instead?

No, not right now. It’s something we’ve discussed implementing but there is no movement on it yet.

Thanks for the update. Any Ignition updates that would improve how we use Git with projects would certainly be appreciated.


Interested in this too. We have Azure DevOps pushing projects to gateways from Pull Requests and a triggered project refresh would be cool. For now we will just set the scan to 60 seconds.


We use git (bitbucket) as well for ignition version control.
The engineers have local branch for development and then we merge changes to dev branch which is pulled on dev on-prem server and then merge to prod branch which is pulled on prod server.
As such everything is working well.

The challenge (other than running sourcetree in admin, which I have a solution for but not a big deal) is that code review during pull request is painful.
Even a small change results in many many files changing which we dont really care about.
Cant ignore those json files as they are needed for a clean installs.

How does your team perform code reviews?

1 Like

Code review can be a challenge for us, too. We generally skip over resource.json files during the review.

Perhaps the biggest challenge is reviewing Python code in view.json files, since it’s typically all stored on one long line in json. For these files, we have a script for Beyond Compare that translates escape sequences (i.e. new lines and tabs) to be displayed as their actual characters. This really improves the readability of the code and helps with code reviews. Here’s the Python code that Beyond Compare runs each time it opens a view.json file:

import sys

input_file_path = sys.argv[1]
output_file_path = sys.argv[2]

with open(input_file_path, 'rb') as input_file:
    input_file_contents =

output_file_contents = input_file_contents.decode('unicode-escape')

with open(output_file_path, 'w') as output_file:

Thanks for sharing Alan.

First thing I just changed on bitbucket is to ignore resource.json and prop.json files in pull request so at least it will keep the file differences to relevant ones.
Next I will look at your suggestion.

Keep in mind there are times you definitely do not want to ignore changes to resource.json files. For instance, named queries use resource.json to store input parameters. If these parameters change on a named query, you’ll want to commit the change made to the query’s resource.json file.

1 Like