F15 Modern Version Control with Git Andrew Benson Sign in on the attendance sheet!

Why should you take this course? To become smarter than Fox News

Git ≠ Github ≠

What this course isn’t For seasoned Linuxbeards

What this course isn’t A crashcourse on git commands

What this course is about Forming a mental model for how git interacts with versions of files Understanding how to use git (and a bit of Github) in a collaborative setting

Grade Breakdown Pass/No Credit, like every StuCo. To pass, get 70% out of: 20% Weekly Lectures (Thursdays 6:30-7:20 pm, Porter Hall 126A) 30% Weekly Homework (due following lecture, turned in via git, except the first few weeks, which will be via ) 20% Midterm (Date TBA) 30% Final (Date TBA)

More Course Details Prerequisite: Basic Unix Survival 3 Free Elective credits No official textbook, but I recommend Pro Git by Scott Chacon No office hours Piazza Slides and lecture notes posted online

Course Policy By StuCo Policy, students with more than 2 unexcused absences must be given a No Pass in the course. Thus, tell me if you’re going to miss class for a legitimate reason, and you might get an excused absence. More than 15 minutes late = unexcused absence Academic integrity applies. Don’t cheat. No late homework.

Waitlists

The Problem – “Version Control” I want to be able to go back to any prior version of any file in my project I want to be able to easily share a change to my project with someone else who has an older version

ing Tars Memory-intensive Can be slow Can be hard to track

Diff and Patch Idea: store only one version of each file, and store diffs between different file versions

Diff and Patch Apply and reverse-apply diffs to retrieve the needed version of the file Instead of sharing entire tars, developers share a diff file (“patch”) for each changed file Faster, uses less memory, but inconvenient because it’s dependent on order of applying patches when there are many patches

Centralized Version Control Systems A central, blessed repository determines the order of patches/commits If a commit directly precedes another commit in this order, then it is the parent commit of that other commit (so A is the parent of B) Any new commits must be compatible with the latest commit. If accepted, it becomes the latest commit’s child original file from my project Patch A Patch C Patch B … Patch Z Central, Blessed Repository Patch α Any new patches must be compatible with the latest version of the central repo, Patch Z

Distributed Version Control Systems No central repository Every repository has every commit Central Repository Developer A’s local files Developer D’s local files Developer C’s local files Developer B’s local files Commit Checkout Commit Checkout Dev A’s Repo Dev B’s Repo Dev C’s Repo Dev D’s Repo Commit Push/Fetch Centralized Version Control System Distributed Version Control System

Git Created in 2005 by Linus Torvalds to maintain the Linux kernel. Oh, and he also created that too. DVCS

Changes: Project-Tracking, No Diffs Other VCSs track changes to individual files Git tracks changes to the project, so commits can change more than one file Also, git doesn’t actually keep diffs around like other VCSs - it keeps a copy of every file from every commit, and uses magic and compression to keep the repo fast and small So think of the git history as a series of snapshots of what the repository looked like at each commit. You can retrieve files from any commit Commit 1: A_v1.txt B_v1.txt Commit 2: A_v2.txt B_v1.txt Commit 3: A_v3.txt B_v2.txt Commit 4: A_v3.txt Commit 5: A_v4.txt C_v1.txt

Git Clone Example use: git clone Creates a copy of the entire repository on your computer

Git Log Example use: git log Lists all the previous commits made up to the current commit

Demo

Homework Make a Github account Clone Angular Answer the homework questions, which will be posted this weekend