Using Visual Studio Code with git-server and openHABian

I’m no developer. This up front! :wink:

But I see the possibilities with a git repository and running openHAB to have a Version history, comparisons and so on…
Presently I don’t have a clue on how to achieve this:

  1. running Visual Studio with a git Server in the first place
  2. deploying (or copying or whatever) the files to openHABian
  3. keeping track of changes

Is there a good howto for Dummies like me to Setup VS Code with git in the first place? I don’t seem to find a foolproof tutorial.
Do I need to use the Project for openHABian within the SMB-share of openHAB or is it better to deploy/copy the files differently?
How is the best practise for tracking changes in openHAB Environment?

Thanks for help!

PS:

  • I have an own git server running on my Synology
  • I have the openHAB-conf presented by SMB-share in the local network
1 Like

VSCode will recognize you’ve opened a git controlled folder automatically Soo as you came files and such it will keep track of what has changed and let you commit and push changes and such. So there is nothing special to do there.

I don’t know what capabilities VSCode had to come a repo in the first place though, but I’d be shocked if it isn’t there somewhere in the menus.

The big thing to remember with git is each repo is it’s own independent thing. So you make changes, added files, and commit changes to your local git. Then you push them to the upstream using a push. For you upstream is your Synology server.

So let your in use files (e.g. /etc/openhab2) be a clone of your upstream repo. VSCode will recognize it as a git repo even over samba.

I posted somewhere how I set mine up using .gitignore to only get the important stuff from userdata. I’m on my phone with sorry service so can’t really find it. Let me know if you can’t and I’ll try to dig it up again when I get back to service.

1 Like

I confess I already was on that thread - and forgot about it… :wink:

Just as a thought:

I am using a GitHub private repo as second remote.
This could be an additional option for keeping a versioned “backup” of your config files.
Easy too et up and you are doing all the stuff for the productive repo anyway already.