1. 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.

2. 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

3. 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

4. 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

5. 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.

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. .gitignore
Tells git which files you want to ignore

13. Resources
labview-merge/

14. 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.

15. .gitattributes
Tells git about the attributes of files