Version Control

Version Control (With Git)

The material in these slides was sourced from:

• gitref.org
• pro git
• git - the simple guide

First… Archiving?

What are some ways you’ve used to keep / save different versions of files? →

Sharing / Collaborating

Have you ever worked on a programming project with more than one person? How did you share your code? →

Enter: Version Control

What’s Version Control?

Version control software allows you to record changes to a file or set of files over time so that you can inspect or even revert to specific versions.

• can be applied to any kind of file, but we’re mostly using text files
• with version control, you can:
  • leave comments on changes that you’ve made
  • revert files to a previous state
  • review changes made over time, and track who made them
  • you can easily recover from accidentally breaking or deleting code
  • automatically merge changes to the same file

So… Why?

Version control can help us:

• stop using .bak files!
• collaborate with others
  • share our code
  • merge changes from different sources
• document our work
• group related changes
• And it’s kind of expected that you know this as a professional programmer.

We’re Using Git!

• Git is the version control system that we’re using
• it’s a modern distributed version control system
• it has emerged as the standard version control system to use
• (some others are…)
  • mercurial
  • subversion (svn)
  • cvs

A Bit About Git

It was developed by Linus Torvalds… who? →

By the way, does the name, Git, sound familiar? Where have seen it before?

Github vs Git

GIT AND GITHUB ARE DIFFERENT!

• so… we used github to submit assignments
• github is a website that hosts git repositories
• on it’s own git is just version control

Who Uses Git and Github?

Git is used to maintain a variety of projects, like:

• the Processing IDE
• or Twitter’s Bootstrap
• or Ruby on Rails
• or The City Tech OpenLab!

Some people use github to distribute open source code… for example:

• id software has a bunch of stuff hosted on git

Local Version Control

See the diagram on pro git

• equivalent to what we may have done manually:
  • save files in folder with locally as a snapshot of current state of code
  • recover by going through folders on computer
  • see versions by the timestamped folder name
• all of this is automated through software
  • stores changes to your files in a local database
  • an example of local version control is RCS

Centralized Version Control

See the diagram on pro git

• promoted collaboration; everyone got code from the same place
• single server that has all of the versioned files
• everyone working on it had a working copy, but not the full repository
• an example is subversion (SVN)

Distributed Version Control

See the diagram on pro git

• everyone has full repository
• can connect to multiple remote repositories
• can push and pull to individuals, not just shared or centralized servers
• single server that has all of the versioned files
• everyone working on it had a working copy

We’re Using Git, a Distributed Version Control System

Some Terminology

repository - the place where your version control system stores the snapshots that you save

• think of it as the place where you store all previous/saved versions of your files
• this could be:
  • local - on your computer
  • remote - a copy of versions of your files on another computer

Some More Terminology

• git - the distributed version control system that we’re using
• github - a website that can serve as a remote repository for your project

What’s a remote repository again? →

Where Are My Files

In your local repository, git stores your files and versions of your files in a few different conceptual places:

• the working directory / working copy - stores the version of the files that you’re currently modifying / working on
• index - the staging area where you put stuff that you want to save (or… that you’re about to commit)
• HEAD - the most recent saved version of your files (or… the last commit that you made)

Another Way to Look at It

• the working directory / working copy - stuff you’ve changed but haven’t saved
• index - stuff that you’re about to save
• HEAD - stuff that you’ve saved

And, More Terminology.

• commit - save a snapshot of your work
• diff - the line-by-line difference between two files or sets of files

Two Basic Workflows

1. Creating and setting up local and remote repositories
2. Making, saving, and sharing changes

Creating Repositories

• create a local repository
• configure it to use your name and email (for tracking purposes)
• create a remote repository
• link the two

Making, Saving, and Sharing Changes

• make changes
• put them aside so they can staged for saving / committing
• save / commit
• send changes from local repository to remote repository

Ok. Great!

Remind me again, what’s github? →

• github is a website
• it can serve as a remote git repository
  • that means it can store all versions of your files
  • (after you’ve sent changes to it)

We can now submit assignments using the commandline

Submitting Assignments

• we will continue to use github to submit assignments
• however, instead of using the web interface and copying and pasting …
• we can use a combination of git commands to send files to github

Let’s Start Off With Creating Repositories