How l learned to work with others instead of working around them. & Or How l learned to work with others instead of working around them.

Working Around Others Working around hard to understand how code works, and can continue to work up until it doesn’t. It usually stops working at the worst possible time. Notes test

Technical Considerations Ability to commit and checkout previous versions locally without access to central repository; good for onsite work. Pull requests as code reviews are possible without cloning another copy and removing what you are currently working on Better branching tools than some other VCSs Reasons to use GIT Merging code is not as smooth as text languages; can be a time consuming process. Lack of native support in LabVIEW development environment No file locking. Reasons not to use GIT

Reasons to use GIT Reasons not to use GIT Human Considerations Git has become the standard VCS for many workplaces Branching allows for parallel development by teams on branches without changing production code. Your boss told you to Reasons to use GIT Steep learning curve Having to talk to coworkers about what you disagree with in a merge. General reluctance to change Reasons not to use GIT

Tools There are lots of options! Most of them can be easily linked to VIMege and VIDiff Git SVN allows you to import SVN repos including history into git. Knowing how to navigate the bash git environment is best, GUI based interfaces should not be used until you understand the bash.

Tools Inform Process If you are working with Perforce there is a central reop. To edit a file you have to check it out. So to try something that might not work you either create a separate copy of the work, than try and manu

A different vocabulary Because you have a full copy of the repo locally you can edit it without interacting with the remote depot. Ideally you move code from the workspace to the local HEAD whenever meaningful changes are made. No skipping from workspace to remote. Checkout – rectify workspace with LR Add – stage files for commit Commit – move files to HEAD of local repo

Branching in Individual Contributor Workflow Interim check-ins possible without connection to central repo Possible to reset to previous version without connection to central repo Branch creates a logical separation of field work and office work Branch swapping is useful for sleep deprived development Local branches do not need to be shared

Team Workflow Multiple developers working on a single codebase Possible to reset to previous version without connection to central repo Branch creates a logical separation of field work and office work Branch swapping is useful for sleep deprived development Similar to the fis

Source of conflict OR Place for discussion Ideally you have structured your code so there are no conflicts ever. But hey, edge cases come up. Process in place for how merges take place Don’t be like that one guy at Microsoft and throw a chair off the 4th floor balcony Bring a non-team member to moderate Have design docs in place that can pre-judge style conflicts

Avoiding Merge Conflicts Code that is not highly coupled will result in fewer merge conflicts. Shared being minimized or released with a package manager so it is outside source control is helpful. Hopes for NXG: project based package management. Something equivalate to require/include

.gitignore Tells git which files you want to ignore

Resources http://delacor.com/configuring-hg-or-git-to-use-labview-compare-and- labview-merge/ https://github.com/smithed/vicompare https://www.youtube.com/watch?v=ZvV-ja1h6DE https://www.chiefdelphi.com/t/labview-github/147377 https://github.com/ansible42/LabVIEWGitCheatSheet

GITing started If you have been using SVN there are tools for importing SVN into GIT and keeping the history. The major cloud providers all provide good web interfaces that can be used for the initial creation of repos. After creating a repo online you can clone the mostly blank repo and start adding code.

.gitattributes Tells git about the attributes of files