LabVIEW NXG and Git/Github

[andrewDJ]

Does anyone have documentation or links to such that would describe best practice usage of NXG and Github?  Particularly in respect to bringing an existing project into Github.

I have plenty of backups but I've been taking things a step-at-a-time and I'm at a point where I want to start investigating its integration with Github.

thanks

Andrew

[User002]

I came across a User Group today that may (or may not) be helpful for you.

Git User Group - NI Community - National Instruments

In the group description are links for 

• Getting Started: Git/GitHub Development Workflow
• Getting Started: Git and GitHub Setup
• Etc.

I'm not sure how applicable it is/isn't for NXG, but just glancing at the post dates, there's been activity this year, which is better than many groups, so if you have questions, someone in that group might be able to help.

Hope this isn't a waste of your time! 😅

-joeorbob

[andrewDJ]

That’s great, thanks.  I tried to find the user group but failed so I’ll check it out.

A

[User002]

---

@andrewDJ wrote:

That’s great, thanks.  I tried to find the user group but failed so I’ll check it out.

A

---

I only found it because I was looking for another User Group that I knew existed (Quick Drop Enthusiasts, as it happens). I eventually used Google and got there, then navigated up a level to what is called "More Groups":

HOME>>COMMUNITY>>USER GROUPS>>MORE GROUPS

Both "Quick Drop Enthusiasts" and "Git User Group" are under "More Groups", but I couldn't find a way to navigate to "More Groups" (or any of the groups in "More Groups") using just the community forum navigation tree.

Maybe NI is embarrassed? Trying to hide some of the groups they don't want to admit exist? 😉

Of course I'm totally joking, but I really was confused about how I couldn't get there without using Google to bypass the ni.com site navigation.

Maybe it's an oversight (over-site? 😄) with the NI rebranding or something?

-joeorbob

[andrewDJ]

That would explain why I couldn't find it, although I'm surprised it didn't come up in google.  I'd seen some of that information but was hoping for something a little more up to date.  I shall work it out.  

There's only me working on my apps so it's not a massive issue but I suspect there could be issues over the project file getting corrupted if multiple people make changes to things - merging this from branches could be a pain.  Also, I have .cache/ and Builds/ as entries in my .gitignore but I don't know if there should be anything else.

Thanks for taking the time to dig that info out.

A

[billko]

I think the only real LabVIEW-specific rules would be to always have your projects separate compiled code from source - which makes it so you only need to save VIs that actually got changed (e.g., a subVI changed, which would cause your VI to recompile, but since the source from that VI wasn't changed, it doesn't need to be committed) - and to ignore *.aliases and *.lvlps files, which don't need to be committed to your repository.

Note:

These aren't Git-specific rules; they apply any time you are going to use source control.

[andrewDJ]

Thanks Bill.  This is my .gitignore that I settled on:

# Libraries

*.lvlibp

*.llb

# Shared objects (inc. Windows DLLs)

*.dll

*.so

*.so.*

*.dylib

# Executables

*.exe

# Metadata

*.aliases

*.lvlps

.cache/

Builds/

[billko]

Seems reasonable.  🙂