Git & Version Control

1. Git & Version Control Kevin Scannell, David FerryCSCI 5030 – Principles of Software Development Saint Louis UniversitySt. Louis, MO 63103

2. Version Control 101 Project files (source code, etc.) are stored in a “repository” and are shared with all developers. All changes are “committed” to the repository with a descriptive log message. Developers work independently, but commit meaningful increments back to the project when they are finished. CSCI 5030 – Principles of Software Development

3. Historic Reasons for Version Control • Shared, up-to-date code base • There is no “master” copy of the code • Multiple programmers can work on the same code simultaneously • Committed code is always backed up • Tracks and attributes all changes to code • All changes have a log message that records why the change was made • These are things that programmers did before version control, just manually CSCI 5030 – Principles of Software Development

4. Modern Reasons for Version Control Modern techniques have evolved around the use of version control. Allows branching of project – e.g. stable branch, experimental branch, specific release branches Feature branches – can develop each feature in it’s own branch with “pristine” code base. When feature is done and tested it is merged Allows “diff” between any two versions of code Allows debugging and “root cause analysis.” Can find the exact commit (and why) that introduced a bug Allows “blame view” – can see files with each line annotated by the person who added it and the log message Bigger systems (like GitLab) incorporate project planning, code reviews, etc. into repository CSCI 5030 – Principles of Software Development

5. Scope of Version Control Meant for source code • Works really well for plain text files Also: data files, config files, build scripts, test code, documentation, READMEs, license, the project web site, etc. • Again, works great when things are plain text Generated products are not stored • E.g. object files and other intermediate build results, including final binary Other project’s source code and libraries are up for debate • Replicating where code lives is usually not great • What if your build script automatically fetches remote libraries if they’re not present on your system? • Dependencies and version numbers should at least be documented CSCI 5030 – Principles of Software Development

6. Centralized VC Systems First VC systems were centralized “client-server” systems. Only one official master copy All clients communicate to-from that official master The official master has control: e.g. can enforce policy by “locking” files, etc. These are systems such as CVS and SVN CSCI 5030 – Principles of Software Development

7. Distributed VC Systems Distributed VC adopts a peer-to-peer model • Every copy of the repository contains the entire repository and its entire history • No master copy- all copies are equal • Don’t confuse “master branch” in Git with a “master repository” • Developers can work locally using VC features without having to talk to any upstream VC server • Multiple local copies can all have revisions, must be manually synchronized (e.g. with git pull) • Allows for different workflows that don’t make sense in centralized VC • Integrator workflow, dictator & lieutenants, etc. CSCI 5030 – Principles of Software Development

8. Git LinusTorvalds in 2005 (where else have I heard that name…?) Needed a fast, distributed, and safe version system for the Linux kernel StackOverflow survey in 2018 said 88% of professional developers used Gitin their work (next highest was SVN at 17%) CSCI 5030 – Principles of Software Development

9. Git in a Picture (e.g. at SLU) git.cs.slu.edu Ex: on machine 1git pull origin master <make changes> git commit * -m “xyz” git push origin master Remote(origin) Machine 1 Machine 2 Local Local Working Copy Working Copy CSCI 5030 – Principles of Software Development

10. Git in a Picture (e.g. at SLU) git.cs.slu.edu Ex: on machine 1git pull origin master <make changes> git commit * -m “xyz” git push origin master Remote(origin) Machine 1 Machine 2 Local Local Working Copy Working Copy CSCI 5030 – Principles of Software Development

11. Basic Git Terminology origin – the remote repository that you originally cloned the project from master – the master branch remotes – copies of the repository that are stored on a remote server (contrast with local copies that are stored on each developer’s machine) working copy – the file system where developers look at and modify code on their own machine (but is not the local repository) branches – “copies” of the master branch used for developing new features forks – real copies of the repository used for developing new features CSCI 5030 – Principles of Software Development

12. Common Git Commands git clone – fetch a new repository and create a new working copy of that repository git add – add files to version control git commit – save changes to the local repository git push – send changes from the local repository to a remote git fetch – update your local repository without modifying the working copy git pull – update your local repository and merge those changes with the working copy CSCI 5030 – Principles of Software Development