Report Using Git for Configuration Data revision control in Source Code Control Posted March 2, 2018 3 hours ago, smithd said: Well, I'd suggest keeping the simulation-related cfg in a separate location such that there is no way to run with simulation cfg even if everything goes bad, but...it looks like this does what you want: https://medium.com/@porteneuve/how-to-make-git-preserve-specific-files-while-merging-18c92343826b (windows instruction in first comment) I agree about keeping the sim related config separate - I have taken this approach and found it useful but it can also be tricky to ensure that configuration data that is added during development to the simulation files is merged into the deployment folder. I've personally found BeyondCompare to help solve this problem but it is a manual step that has been hard to enforce with process. The article you suggests looks really promising - I think it was exactly what I was looking for but failed to find by my own searching. I think this is going to help me avoid going down a fairly messy rabbit hole! 1 hour ago, JKSH said: I agree completely: Keep the Git-tracked config files separate from the deployment config files. Trying to make Git track the files and ignore the files at the same time is messy and unintuitive; if any errors occur in the process, they might be hard to detect and to fix. Some other possibilities to consider (these ideas aren't mutually exclusive; you can implement more than 1): Have your application search for config files in a "deployment" folder first. If those aren't found, then fall back to the simulation config files. This way, both deployment and development machines can run the same code yet read from different folders. This way, the "deployment" folders are untracked by Git and there's no risk of overwriting their contents. Make it visually obvious when your application is running in simulation mode (e.g. change the background colour and show a label). Deploy by building and distributing executables instead of pulling source code. It sounds like your deployment machines run the LabVIEW source code directly. How do you manage the risk of the code getting accidentally (or maliciously) modified by an operator? We're definitely not running source directly in our final deployment. We run from built exe's and leave no source code on the deployment machines. But the other points are definitely valid. I agree this is a suboptimal way to manage the configuration data. Ultimately what I think I want is for the auto-merging of the text to fail so that the developers can make intelligent decisions about what to merge - basically the way that binary files are treated (probably the only time I will ever think this way) - I think the article @smithd linked to will do that for me. Very appreciative of the help and advice!