Version Control, Git, and GitHub Class Eight: January 23, 2014 

Version  Control Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. Any type of file on a computer can be placed under version control. Think Dropbox but with a whole lot more control. 

Version  Control  System  (VCS) Allows you to: • Revert files back to a previous state • Revert the entire project back to a previous state • Review changes made over time • See who last modified something that might be causing a problem • See who introduced an issue and when Using a VCS also means that if you screw things up or lose files, you can generally recover easily. In addition, you get all this for very little overhead. 

Methods  of  Source  Control • Copy/Paste: Move to another Directory • Centralized Version Control Systems (CVCSs) Examples: CVS, Subversion Single point of failure in the centralized server • Distributed Version Control Systems (DVCSs) Examples: Git, Mercurial Fully mirrored repository Nearly every operation is local since you have a copy of the entire repository 

Centralized  Version  Control  Systems 

Distributed  Version  Control  Systems 

Version  Control  Systems  and  Time A  CVCS,  with  a  set  of  files  and  the  changes  made  to  each  file  over  9me 

Linus  Torvalds,  Presumably  HaAng  on  the  Haters 

Git:  What’s  the  Benefit? No single point of failure (since it’s distributed) You can work when offline (no need to contact remote server for info) It's very difficult to lose data 

Git:  The  Three  States Committed: Stored in your local database Modified: Changed but not committed to your database Staged: Marked a modified file in its current version to go into your next commit snapshot 

Git  and  Time  (Snapshots,  not  Differences) Git,  data  as  a  set  of  snapshots   A1  is  not  stored  again  in  Version  3  since  it  hasn't  changed. 

Git:  Three  Main  SecAons  of  a  Project Git Directory: Where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer. Working Directory: A single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify. Staging Area: A simple file, generally contained in your Git directory, that stores information about what will go into your next commit. 

Git:  Basic  Workflow 1. You modify files in your working directory. 2. You stage the files, adding snapshots of them to your staging area. 3. You perform a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory. 

Git:  Basic  Workflow 

Git:  Your  IdenAty The first thing you should do when you install Git is to set your user name and e-mail address. This is important because every Git commit uses this information, and it’s immutably baked into the commits you pass around: $ git config --global user.name "John Doe"
 $ git config --global user.email [email protected] If you want to check your settings, you can use the git config --list command to list all the settings Git can find at that point: 

GitHub:  Octocat 

GitHub:  What  is  it? GitHub is a Git repository hosting service, but it adds many of its own features. While Git is a command line tool, GitHub provides a Web- based graphical interface. It also provides access control and several collaboration features, such as a wikis and basic task management tools for every project. 

GitHub:  What  is  it? The flagship functionality of GitHub is “forking” – copying a repository from one user’s account to another. This enables you to take a project that you don’t have write access to and modify it under your own account. If you make changes you’d like to share, you can send a notification called a “pull request” to the original owner. That user can then, with a click of a button, merge the changes found in your repo with the original repo. 

GitHub:  What  is  it? These three features – fork, pull request and merge – are what make GitHub so powerful. Before GitHub, if you wanted to contribute to an open source project you had to: • Manually download the project’s source code • Make your changes locally • Create a list of changes called a “patch” • E-mail the patch to the project’s maintainer The maintainer would then have to evaluate this patch, possibly sent by a total stranger, and decide whether to merge the changes. 

GitHub:  What  is  it? This is where the network effect starts to play a role in GitHub... When you submit a pull request, the project’s maintainer can see your profile, which includes all of your contributions on GitHub. If your patch is accepted, you get credit on the original site, and it shows up in your profile. It’s like a resume that helps the maintainer determine your reputation. The more people and projects on GitHub, the better idea picture a project maintainer can get of potential contributors. Patches can also be publicly discussed. 

Git File Status Lifecycle Review 

Git Commands git init Initialize a repository in an existing directory Creates a repository skeleton git clone [url] Cloning an existing repository Remember that each file in your working directory can be in one of two states: tracked or untracked. Tracked files are files that were in the last snapshot; they can be unmodified, modified, or staged. Untracked files are everything else — any files in your working directory that were not in your last snapshot and are not in your staging area. When you first clone a repository, all of your files will be tracked and unmodified because you just checked them out and haven’t edited anything. 

Git Commands git status Check the status of your files git add [file name] To begin tracking a new file. If it's a folder, all files are added recursively you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved git diff What have you changed but not yet staged? And what have you staged that you are about to commit? git diff shows you the exact lines added and removed — the patch, as it were. 

Git Commands git commit Remember that anything that is still unstaged — any files you have created or modified that you haven’t run git add on since you edited them — won’t go into this commit. You can type your commit message inline with the commit command by specifying it after a -m flag, like this: git commit -m "Story 182: Fix benchmarks for speed" Skipping the staging area (skip the git add part): git commit -a -m 'added new benchmarks' 

Git Commands git rmv To remove a file from Git, you have to remove it from your tracked files (more accurately, remove it from your staging area) and then commit. The git rm command does that and also removes the file from your working directory so you don’t see it as an untracked file next time around. git log View the commit history. Lots of switches available. git log -p: Shows the diff introduced Using gitk as a visual git log tool 

Git Branching Git’s “killer feature” Branching means you diverge from the main line of development and continue to do work without messing with that main line The way Git branches is incredibly lightweight, making branching operations nearly instantaneous and switching back and forth between branches generally just as fast. Visual tutorial: