# Guide for Version Control with Ignition **URL:** \ **Category:** Ignition\ **Tags:** ignition81, docker\ **Created:** [January 9, 2024, 7:52pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004 "2024-01-09T19:52:05Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Eric\_Knorr](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/eric_knorr/32/53150_2.png) [@Eric\_Knorr](https://forum.inductiveautomation.com/u/Eric_Knorr)\ **Post date:** [January 9, 2024, 7:52pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/1 "2024-01-09T19:52:05Z")
> πŸ“Œ **Update (May 2026):** The repositories shared in this post have been consolidated > into [**ignition-guides**](https://knorrlabs.github.io/ignition-guides/), a community resource that I'll be adding to periodically. The original repos are now archived and can now be found here: > > - [Version Control Guide](https://knorrlabs.github.io/ignition-guides/docs/guides/version-control/intro) > - [Version Control Lab](https://knorrlabs.github.io/ignition-guides/docs/labs/version-control-lab) > - [Style Guide reference](https://knorrlabs.github.io/ignition-guides/docs/reference/git-style-guide) Hey all, I've been working on developing some guides on how to use version control with Ignition in a team-based environment. If you've never used git, or just don't understand the nuances of how to use it with Ignition, you may find these documents useful to get you started. These are by no means comprehensive and are not any _gold standard_, but merely some guideposts as you find what will work best for you. Note: This isn't designed to be a substitute for studying the intricacies of Git, GitHub (GitLab, etc.), or Ignition. _See an typo or problem or want to contribute? Submit a PR or an issue!_ **1. [Version Control with Ignition](https://github.com/ia-eknorr/ignition-version-control)** This guide covers the basics of version control and shows you how to use it with Ignition. Good for learning or just a quick reference. **2. [Version Control / Ignition Lab](https://github.com/ia-eknorr/git-ignition-lab)** A hands-on lab to help you apply version control concepts to Ignition projects. Admittedly, it's a bit contrived, but it's a start. **3. [Version Control Style Guide](https://github.com/ia-eknorr/ignition-git-style-guide)** This is a basic style guide for version control in a team-based environment. Everyone has their two cents on how this should be done, here's mine. If you already have a convention, you may not need this. **4. [Project Template](https://github.com/ia-eknorr/project-template)** This is a sample of what we in Application Engineering use internally on our projects. This is basically a copy of what @Kevin.Collins has put together in previously, but all in one place and curated for a small-medium sized project. **Post-8.3 Release Edit:** We have released a [Version Control Guide](https://docs.inductiveautomation.com/docs/8.3/tutorials/version-control-guide), specifically for use with 8.3. The documents above may still be generally useful, but are not specific to 8.3. ---
**Author:** ![adam.haney](https://avatars.discourse-cdn.com/v4/letter/a/4bbf92/32.png) [@adam.haney](https://forum.inductiveautomation.com/u/adam.haney)\ **Post date:** [January 15, 2024, 6:03pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/2 "2024-01-15T18:03:29Z")
@Eric_Knorr This is great stuff. I really appreciate it! ---
**Author:** ![msteele](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/msteele/32/77889_2.png) [@msteele](https://forum.inductiveautomation.com/u/msteele)\ **Post date:** [January 16, 2024, 9:45pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/3 "2024-01-16T21:45:13Z")
@Eric_Knorr and IA staff, are you able to share if we might expect git integration/capabilities or anything that would substantially affect this workflow when 8.3 is released? ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [January 18, 2024, 10:13pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/4 "2024-01-18T22:13:18Z")
Don't expect any first party Git (or any other VCS) _integration_ in 8.3.0. _Capabilities_ will expand significantly, since gateway config is moving to the filesystem in a similar manner to the existing project resource mechanism. Expect some other improvements in the management of resources on disk, such as less hassle with the `resource.json` file. ---
**Author:** ![msteele](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/msteele/32/77889_2.png) [@msteele](https://forum.inductiveautomation.com/u/msteele)\ **Post date:** [January 23, 2024, 6:58pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/5 "2024-01-23T18:58:00Z")
@Eric_Knorr @Kevin.Collins would you be able to provide some context around your use of the project template? It's using git to manage a compose stack including a .gwbk and other assets to spool up, correct? But are you using SCM for the gwbk and projects within this? Do you also have a repo for your /data (gwbk) directory? That's what we've been testing as a root dir for our repo, then we can all run local dev gateways and push changes into SCM with a DevOps pipeline to update test gateways. ---
**Author:** ![Eric\_Knorr](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/eric_knorr/32/53150_2.png) [@Eric\_Knorr](https://forum.inductiveautomation.com/u/Eric_Knorr)\ **Post date:** [January 24, 2024, 4:01pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/6 "2024-01-24T16:01:30Z")
The way we use this in Application Engineering is pretty much only to source control whatever is currently held in files, so projects, any non-standard modules, additional icons, etc. Then the gateway backup is there to hold everything else. The only difference is that the gateway backup has the projects stripped out of it (using the script in the repo) such that when the `-r` flag is run on `docker-compose up`, it doesn't overwrite the bind mounted project folder. I'm working on a way to version control tags using Design Group's [Tag CICD module](https://github.com/design-group/ignition-tag-cicd-module), but it's still WIP. To answer your last question, we do not have a separate repo for the `data` dir. We do mount a volume to hold `data`, but that's more of a convenience thing to save the gateway data - we haven't had a need to version control any deeper than that. So if a gateway change was made, we would take a new gateway backup, strip the projects, then commit that to the repo. ---
**Author:** ![tctx](https://avatars.discourse-cdn.com/v4/letter/t/d78d45/32.png) [@tctx](https://forum.inductiveautomation.com/u/tctx)\ **Post date:** [January 25, 2024, 8:29pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/7 "2024-01-25T20:29:55Z")
Can you expand on how y'all use the gateway backup script `download-gateway-backups.sh`? Do you just manually run it from the host while the container is running prior to the next commit? ---
**Author:** ![Eric\_Knorr](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/eric_knorr/32/53150_2.png) [@Eric\_Knorr](https://forum.inductiveautomation.com/u/Eric_Knorr)\ **Post date:** [January 25, 2024, 8:47pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/8 "2024-01-25T20:47:35Z")
Sure, that's exactly correct. After bringing the docker stack up, running the `download-gateway-backups.sh` script will go through the running containers, take backups, strip the projects, and put them in the `gw-init/` dir. I have a short paragraph in the [readme](https://github.com/ia-eknorr/ignition-version-control/blob/main/Workstation%20Setup.md) about how to use this script as well. πŸ˜‰ ---
**Author:** ![tctx](https://avatars.discourse-cdn.com/v4/letter/t/d78d45/32.png) [@tctx](https://forum.inductiveautomation.com/u/tctx)\ **Post date:** [January 25, 2024, 9:21pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/9 "2024-01-25T21:21:31Z")
Ah, I must have missed it. Thanks for this though, this fits nicely in with the workflow I had going. Just FYI, the script as is was silently failing to actually remove the `projects/` folder from the zipped gwbk. Adding an asterisk to the `zip -d` seemed to do the trick: ```auto ... zip -q -d "${ZIP_FILE}" "projects/*" > /dev/null 2>&1 || \ ... ``` Not sure if this is just some quirk of running the script in WSL. ---
**Author:** ![richardNZ15](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/richardnz15/32/33373_2.png) [@richardNZ15](https://forum.inductiveautomation.com/u/richardNZ15)\ **Post date:** [February 5, 2024, 4:51am UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/10 "2024-02-05T04:51:05Z")
Looks like an amazing start! Thank you for publishing this. Lots to read through πŸ™‚ ---
**Author:** ![wdougmiller](https://avatars.discourse-cdn.com/v4/letter/w/a9a28c/32.png) [@wdougmiller](https://forum.inductiveautomation.com/u/wdougmiller)\ **Post date:** [February 15, 2024, 3:06am UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/11 "2024-02-15T03:06:34Z")
Is there any guidance if you’re using project inheritance and want to bring git version control into the game? Are they competitive or complementary? ---
**Author:** ![Eric\_Knorr](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/eric_knorr/32/53150_2.png) [@Eric\_Knorr](https://forum.inductiveautomation.com/u/Eric_Knorr)\ **Post date:** [February 21, 2024, 6:56pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/12 "2024-02-21T18:56:12Z")
Hey @wdougmiller, there shouldn't be any issues with project inheritance and version control. Inherited project resources aren't copied into the child project unless the resource is overridden, so there is no duplication of resources that would look funny from a version control perspective. In the case that you do have overridden resources, it will be found in the child project (with any saved changes) as well as in the parent project (as the unchanged version). ---
**Author:** ![tyler.robertson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/tyler.robertson/32/18299_2.png) [@tyler.robertson](https://forum.inductiveautomation.com/u/tyler.robertson)\ **Post date:** [April 15, 2024, 6:32pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/13 "2024-04-15T18:32:39Z")
How are you guys setting up your workflow with Perspective/Vision projects and Designer? What I'm doing feels clunky but I'm not too sure how to improve it at the moment. Nothing I'm doing is mission critical and I'm a developer of one, but we've been successful enough with Ignition that it is at risk of becoming otherwise - Ignition is on a server running VM, with Azure Dev ops for repos. - 'projects' folder of the Ignition install is set up in a git repo, so all projects are contained in one folder - I had it this way to manage .resource folder. Is this managed now and I'm out of touch? - My designer is connected to the server gateway, I work on 'Dev' projects and then when satisfied I push it to server, and export data in Designer to the relevent 'Prod' project. This means I could accidently overwrite a project in production I want to build this export workflow in DevOps, any issue there? Are people running local gateways for their designer and pulling filesystem locally? Thanks! ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [April 15, 2024, 6:47pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/14 "2024-04-15T18:47:34Z")
Consider reading this article: > **[Ignition 8 Deployment Best Practices](https://inductiveautomation.com/resources/article/ignition-8-deployment-best-practices)** > > Inductive Automation provides this helpful guide for deploying Ignition applications. The guide offers Ignition 8 best practices for setting up development and testing workflow. Some general points of advice: - You don't need to care about, nor should you commit, the `.resources/` folder. - I'd generally recommend a git repo per-project, although a "monorepo" is possible. It's going to be a lot more meaningful/achievable in 8.3, though. - I would suggest setting up a **local** dev Gateway, managed through a VM or Docker or whatever, for _each_ developer. Pushes can be initiated from your local repo to a remote hosted on a forge like Github/Gitlab/Gitea/whatever, _or_ directly pushed from local to the production system. A CI system like Jenkins could be used to ensure the local disk copy on the production VM is up to date with upstream. ---
**Author:** ![tyler.robertson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/tyler.robertson/32/18299_2.png) [@tyler.robertson](https://forum.inductiveautomation.com/u/tyler.robertson)\ **Post date:** [April 15, 2024, 8:09pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/15 "2024-04-15T20:09:30Z")
Thanks! Yeah I'm not sure at all why I had one repo for everything, it's been a particular pain and not at all how I work my 'regular' software development pipeline. Thanks for the clarify on the .resources/, I think when I set this all up I just saw changes in that whenever I saved and figured they needed to be captured. Glad to hear if I get that going 8.3 will improve the experience. The local repo makes sense as well - I think early on I was doing more work just getting _devices_ working with our network that working directly with projects on the gateway that this all would connect to seemed logical, but I like working locally and just moving a connection over when ready. Thanks for the second set of eyes! I might keep my Dev Projects because being able to open up a Vision Client on a custom machine with like, three different devices on the floor in the exact setup it'll be used on is nice, when I have only 15-30 minutes to do so between shifts \>\_\< ---
**Author:** ![Trevor\_Speckman](https://avatars.discourse-cdn.com/v4/letter/t/a6a055/32.png) [@Trevor\_Speckman](https://forum.inductiveautomation.com/u/Trevor_Speckman)\ **Post date:** [May 8, 2024, 5:37pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/16 "2024-05-08T17:37:15Z")
@Eric_Knorr Really appreciate these resources! I've been playing around with the project template and I have a few questions: 1. Are you using the Projects folder to hold all projects in the gateway or for an individual project? I see that one repo per project is recommended by @paul-griffith but this template seems to work more like a monorepo to me. Obviously there's more than one way to do things. Just curious what the intention was. 2. I would like to use containers for development but still be able to use a VM in production. With this project structure how would I be able to strip out the project files for production? I played around with Git submodules so the project/projects and the project template have their own repos. It works but adds an extra layer of complexity. I'm still pretty new to containers/docker workflows so any feedback is appreciated. Thanks! ---
**Author:** ![Eric\_Knorr](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/eric_knorr/32/53150_2.png) [@Eric\_Knorr](https://forum.inductiveautomation.com/u/Eric_Knorr)\ **Post date:** [May 10, 2024, 4:59pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/17 "2024-05-10T16:59:55Z")
Hey Trevor, 1. If the objective I'm working on has more than one project, such as an inherited project, I would create a bind mount for each of the projects, but I would keep this to only related projects to the objective. Some of our initiatives such as the Public Demo have many projects in one gateway. We use 1 repo to hold all of those projects. 2. This broaches a much larger topic about deployment. ---
**Author:** ![Trevor\_Speckman](https://avatars.discourse-cdn.com/v4/letter/t/a6a055/32.png) [@Trevor\_Speckman](https://forum.inductiveautomation.com/u/Trevor_Speckman)\ **Post date:** [May 10, 2024, 10:18pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/18 "2024-05-10T22:18:31Z")
1. That makes a lot of sense. I would prefer to keep the projects folder limited to only related projects. I will probably create separate repos for anything gateway scoped (e.g. tags, gateway backups, images, etc.) and manually move those resources into the project repos when necessary. 2. I would like to eventually run containers in production, but for the time being I will most likely perform manual project exports between different VM environments. I also played around with git sparse-checkout and it seemed to be more trouble than it was worth. Appreciate the response! ---
**Author:** ![Eugene49](https://avatars.discourse-cdn.com/v4/letter/e/c6cbf5/32.png) [@Eugene49](https://forum.inductiveautomation.com/u/Eugene49)\ **Post date:** [March 16, 2025, 2:40am UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/19 "2025-03-16T02:40:49Z")
I am new to Git. I am ready and eager to learn now, specifically application of Git to Ignition. I know the root concept of Git. BUT, I can't imagine visually, how do you track changes, using Git for Ignition. For example, in perspective, view's essentially are just code under the hood. Does that mean when I use Git for Ignition, I track changes by looking at json codes? Not visual, as in designer? If yes, does that mean, I need to learn to interpret json code, to identify properties, components, etc? edit: I found the answer: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/1/5/159a969259e4caa3b1577ad769166f9f3fbfcab0.jpeg) from this youtube: [https://youtu.be/qJVfmQ54M70?si=PA9dyqGoKBXLq7us](https://youtu.be/qJVfmQ54M70?si=PA9dyqGoKBXLq7us) ---
**Author:** ![Eric\_Knorr](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/eric_knorr/32/53150_2.png) [@Eric\_Knorr](https://forum.inductiveautomation.com/u/Eric_Knorr)\ **Post date:** [March 17, 2025, 3:46am UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/20 "2025-03-17T03:46:34Z")
Yes, that video is a great resource. To add my two cents in as well, because each Ignition resource is comprised of 2-3 files within a directory, I always commit them together. So as long as you are able to keep track of what you are doing in the designer and understand a little bit of the underlying structure, I would always add and commit the entire view directory at the same time. [Next page](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004.md?page=2)