# Guide for Version Control with Ignition **URL:** \ **Category:** Ignition\ **Tags:** docker, ignition81\ **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:** 2
**Author:** ![emmanuel.gyasibaaye](https://avatars.discourse-cdn.com/v4/letter/e/dbc845/32.png) [@emmanuel.gyasibaaye](https://forum.inductiveautomation.com/u/emmanuel.gyasibaaye)\ **Post date:** [March 18, 2025, 5:11pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/21 "2025-03-18T17:11:07Z")
Thank you for creating this guide! I am currently working on a guide for a customer, but there is one issue with the repo I was hoping you and/or the IA team could clarify. Are the repos ok to fork (with/without attribution)? Since there is no license defined the repos are assumed proprietary by default. Adding an explicit license to the repos would also be appreciated! ---
**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 20, 2025, 3:38am UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/22 "2025-03-20T03:38:19Z")
Everything is free to use as you'd like. I'll add an MIT license for good measure. ---
**Author:** ![Eugene49](https://avatars.discourse-cdn.com/v4/letter/e/c6cbf5/32.png) [@Eugene49](https://forum.inductiveautomation.com/u/Eugene49)\ **Post date:** [March 22, 2025, 3:26pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/23 "2025-03-22T15:26:56Z")
Again, beginner here. As I studied, I learned that Git is doing the version control mechanism, and Github is a repository hosting services for Git. I understood that, Github is optional for single developer, but required for multiple developer. As you may all knows, clients, companies, do not want to put resources on third party cloud. Ideally, version control needs a dedicated server for repository hosting? Do we have an option to self host this? What software similar to Github we can use? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [March 22, 2025, 3:32pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/24 "2025-03-22T15:32:16Z")
> [@Eugene49](#): > > Github is optional for single developer, but required for multiple developer No, hosting a git repository does not require Github, or any cloud service. It doesn't need anything more than a server with command line git and SSH installed. Git repo URLs for this look like `git+ssh://user@somehost.somedomain:folderName`, where the folder name is in the user's home directory. (This is what I do for my own business repos.) Various open-source projects offer github-like web services, but that is all optional. ---
**Author:** ![Eugene49](https://avatars.discourse-cdn.com/v4/letter/e/c6cbf5/32.png) [@Eugene49](https://forum.inductiveautomation.com/u/Eugene49)\ **Post date:** [March 22, 2025, 3:46pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/25 "2025-03-22T15:46:48Z")
> [@pturmel](#): > > It doesn't need anything more than a server with command line git and SSH installed. That make sense (as usual), since all you need is a storage and something that do the compare, which Git is already doing. I have fundamental question, regarding setup of each developer machine's, segregation of each dev's codes, etc. but I will post it as soon as, I got the question right. Thank you. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [March 22, 2025, 3:59pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/26 "2025-03-22T15:59:49Z")
When using just git+ssh, the users should have SSH keys configured so that password login to the repo server is disabled. That also means the user names on the repo server do not have to correspond to actual users, though that is wise for any private repos. For shared repos, simply create a dedicated username for that repo, and set every desired user's public key in that account. ---
**Author:** ![Eugene49](https://avatars.discourse-cdn.com/v4/letter/e/c6cbf5/32.png) [@Eugene49](https://forum.inductiveautomation.com/u/Eugene49)\ **Post date:** [March 22, 2025, 4:58pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/27 "2025-03-22T16:58:14Z")
Thinking about it now.. Do you think, Git tool skills, is too much to acquire and maintain? From experience, its very rare occasion or never, that we need to revert back to a version in the past, if necessary, we might only need to change few codes. What we really need: In an environment where each developer is working on its own use case. It is a waste of time and effort (for dev and tester) if we miss to promote (to test env) the modified resources (views, named queries, project scripts). Is there a way to detect which resource have changed? I am thinking of a tool to compare before and after of gateway backup. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [March 22, 2025, 5:02pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/28 "2025-03-22T17:02:11Z")
I find git to be extremely valuable. I don't revert very much, but stashing and patch splitting are often helpful. Most importantly, regular commits make a history that have really helped me when troubleshooting. Git will be much more useful in v8.3, of course. ---
**Author:** ![Chris\_Bingham](https://avatars.discourse-cdn.com/v4/letter/c/e5b9ba/32.png) [@Chris\_Bingham](https://forum.inductiveautomation.com/u/Chris_Bingham)\ **Post date:** [March 23, 2025, 5:06pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/29 "2025-03-23T17:06:01Z")
> [@Eugene49](#): > > Do you think, Git tool skills, is too much to acquire and maintain? Loaded (& excellent) question... there is a learning curve (to developer & user alike) and might not be justifiable to a client that might be paying for it. However, after implemented & utilized, version-control **always** = 'worth it' in my book. > [@Eugene49](#): > > Is there a way to detect which resource have changed? For many resources, a query of the audit log might be a quick way to see **that** something was modified (when and by whom). ---
**Author:** ![Eugene49](https://avatars.discourse-cdn.com/v4/letter/e/c6cbf5/32.png) [@Eugene49](https://forum.inductiveautomation.com/u/Eugene49)\ **Post date:** [March 27, 2025, 12:45am UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/30 "2025-03-27T00:45:15Z")
I enrolled myself on online git courses. The video instructor, was working on a single server. Where he do stuff like checkout and commit, and working directory (actual files use by applications lives) gets spawn and respawn. How does this relates to a multi-machines environment, where each developer has its own machine, and we have 3 environments (Dev, Test, and Prod). I assume there needs to be a dedicated git server? I assume that, when a developer works on a feature, he needs to checkout from git server into his machine? In this case how does git maintain code on a different machine? Finally, how do you deploy codes to the Dev, Test, and Prod server? Does these server has it own .git Folder? Someone please put a light on this. ---
**Author:** ![Leor\_Fishman](https://avatars.discourse-cdn.com/v4/letter/l/e19adc/32.png) [@Leor\_Fishman](https://forum.inductiveautomation.com/u/Leor_Fishman)\ **Post date:** [March 27, 2025, 1:43am UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/31 "2025-03-27T01:43:14Z")
This is where CI/CD comes in -- the big q is what sort of code is generally changing and how you want to merge changes ---
**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 27, 2025, 1:55am UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/32 "2025-03-27T01:55:16Z")
We use this process in Sales Engineering to develop our internal applications. We have a team of developers working locally on their machines, all pointing up to a remote Github repo. This is where we handle PRs, reviews, etc. For applications that go through multiple environments, we create derived Ignition images that are pushed to a container registry. It is verified in Test before being pushed to Prod. If changes need to be made, we make them locally, merge it into the remote repo, then make another version with a new image to push to Test. This is _one_ way to do it, but it's by no means the _only_ way to do it. ---
**Author:** ![Leor\_Fishman](https://avatars.discourse-cdn.com/v4/letter/l/e19adc/32.png) [@Leor\_Fishman](https://forum.inductiveautomation.com/u/Leor_Fishman)\ **Post date:** [March 27, 2025, 1:57am UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/33 "2025-03-27T01:57:22Z")
You can also set scripts to run on any commit/push or specific tagged ones Rather than github, use [Download and install GitLab | GitLab](https://about.gitlab.com/install/) if you want to selfhost ---
**Author:** ![Eugene49](https://avatars.discourse-cdn.com/v4/letter/e/c6cbf5/32.png) [@Eugene49](https://forum.inductiveautomation.com/u/Eugene49)\ **Post date:** [March 27, 2025, 2:41am UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/34 "2025-03-27T02:41:32Z")
Thanks for the inputs.. I miss one important ingredient, that is part of the solution to my questions. - That is having a central git repository (with branches) where developers can push their code to.. and will act as main source of codes, to be deployed on ignition gateways.. - at least this is what I understand one workflow of using git. Question: If we replace/modify directly the files in ignition project folder. Does Ignition (including opened designer) updates on the fly? - is this a usual practice even, when using git? ---
**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 27, 2025, 2:52am UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/35 "2025-03-27T02:52:51Z")
The default scan rate is 5 minutes, but this can be changed in [ignition.conf](https://docs.inductiveautomation.com/docs/8.1/getting-started/installing-and-upgrading/ignition-8-upgrade-guide/80to81-upgrade-guide#gateway-scan-of-project-directory) file. We typically update ours to 10 seconds. In the designer, you may need to merge changes by using the [Update Project](https://www.docs.inductiveautomation.com/docs/8.1/platform/designer/designer-user-interface#file-menu) button. ---
**Author:** ![Eugene49](https://avatars.discourse-cdn.com/v4/letter/e/c6cbf5/32.png) [@Eugene49](https://forum.inductiveautomation.com/u/Eugene49)\ **Post date:** [March 27, 2025, 2:54pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/36 "2025-03-27T14:54:53Z")
I think I figured it out.. 🙂 General git workflow. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/b/1/b1f754029162a3854520e06b33a8ec43cc76b121.png) Dev would update Dev's working directory and commit changes to Dev's local git repository. Push changes to Dev branch. I would merge Dev Branch to Tst branch, only cherry picked (done) features. Do a clone from Tst Branch to Tst working directory for testing. If testing pass, merge Tst Branch to Prd Branch so on and so forth. else if test fail do the modification in Dev working directory-that is Dev's designer. ---
**Author:** ![Eugene49](https://avatars.discourse-cdn.com/v4/letter/e/c6cbf5/32.png) [@Eugene49](https://forum.inductiveautomation.com/u/Eugene49)\ **Post date:** [August 29, 2025, 1:11am UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/37 "2025-08-29T01:11:15Z")
I’ve been using git for awhile now, professionally. I admit its fun, I even bought a git merch shirt. That aside, I don't find git necessary for deployment, you can always, easier to do, export import resources from one gateway to another. And really how often you need to revert back to previous application version, you can always restore previous backup. I really find unnecessary burden dealing with merge conflict because merge was not done timely. What you guys think? I guess I am here want to justify the love using git. ---
**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:** [August 29, 2025, 1:23am UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/38 "2025-08-29T01:23:02Z")
We’re seeing more customers who are actually _requiring_ git integration for their ignition systems - either from their IT team or for compliance. Other customers with large deployments find that it’s easier to use git to merge changes from different contractors in and promote through their staging and production environments. We have found that with the proper convention, there aren’t many merge conflicts at all! Regarding rollbacks - they’re never useful… until they are. The whole version control story is already much better in 8.3! ---
**Author:** ![Eugene49](https://avatars.discourse-cdn.com/v4/letter/e/c6cbf5/32.png) [@Eugene49](https://forum.inductiveautomation.com/u/Eugene49)\ **Post date:** [August 29, 2025, 1:27am UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/39 "2025-08-29T01:27:28Z")
> [@Eric\_Knorr](#): > > We’re seeing more customers who are actually _requiring_ git integration for their ignition systems - either from their IT team or for compliance. Ahh 👍 Thank you. ---
**Author:** ![Brian\_Stilson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/brian_stilson/32/73410_2.png) [@Brian\_Stilson](https://forum.inductiveautomation.com/u/Brian_Stilson)\ **Post date:** [September 23, 2025, 1:57pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/40 "2025-09-23T13:57:52Z")
> [@paul-griffith](#): > > You don't need to care about, nor should you commit, the `.resources/` folder. I’m curious about this. I installed 8.3, and in my data/projects folder there is only a folder for my projects and the .resources folder. If what I’m working on is just one project, could I just make the project folder my repository and not need a .gitignore file at all? [Previous page](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004.md?page=1) [Next page](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004.md?page=3)