This year 624 is using Git with LabViewGitEnv (
https://github.com/joerg/LabViewGitEnv).
It went
okay, but once we got a significant number of VIs in the project merging became such a long and protracted experience that we stopped doing it, keeping everything on a single branch, because for every single changed VI (and they change for some reason whenever you open them) it has to start up LVMerge over again, which takes quite a while to load, and then the project fills up with "file conflicts" that you have to manually accept for every single changed VI. That negated one of the most significant features of Git, which is that you're (usually) able to maintain parallel branches with easy merging between them, allowing your team to collaborate and multitask.
We found that it was helpful to use auto-populating folders for VIs in the LabVIEW project, and to review changes before committing them to avoid including a VI that wasn't really modified. We also removed the .aliases and .lvlps files from the repository, because merging would corrupt them and they seem to be regenerated by LabVIEW anyways. Git would also corrupt our lvproj file sometimes in merges, which we fixed by hand when it occurred (It's an XML file).
All in all, I don't know if it was worth it. The benefits of collaboration and multiple branches were nice early in the build season as we prototyped different elements of the code, but once we started integrating different code elements together and editing the same VIs merging became very tedious. However, the ability to go back to your code at any point in time in the past is very helpful.
If you use Git (and this may apply to other version control systems as well), I would recommend to really try to avoid working on the same VI in different branches, because merging really isn't fun.