CS 2112 Lab: Version Control
29 September–1 October, 2014
Version Control
What is Version Control?
You’re emailing your project back and forth with your partner. An
hour before the deadline, you and your partner both find different
bugs and work feverishly to correct them. When you try to submit,
you find that you have two different versions of the code, and you
don’t have enough time to figure out who changed what, how to
merge them together into one final project, and what, if any, bugs
were introduced along the way!
Version Control
What is Version Control?
Version control allows multiple people to work on a project simultaneously by keeping versioned copies of each file in your project for each edit that you make. This makes it easy to:
I Revert files back to a previous state if you make a mistake.
I Look over any changes made by you or those you are working with.
I Recover any files if they are lost.
Distributed version control lets you store the different versions of
your files on a remote server.
Overview
Git!
Several widely used version control systems exist. Some of the most popular free ones are Git, Mercurial, and Subversion.
Perforce is often used in industry. We will take a look at Git, which
is popular, freely available, and powerful. Subversion is simpler to
use but less powerful; Mercurial is similar to Git; perhaps a little
slower. Eclipse has some support for projects that use Git, but it’s
safer to get Git at the command line.
Overview
Setting Up a Repository
A couple of sites host free repositories, including:
I github.com (Git - though you will need to request a student account for private repositories)
I bitbucket.org (Git and Mercurial)
I xp-dev.com (Subversion, Git, and Mercurial)
You will need to follow the specific instructions for whichever host
you choose in order to initialize a Git project and add your new
remote repository. (This will make more sense later!)
Structure
The Local Repository
Your local repository contains 3 trees:
I Working Directory - This is where you will look at, modify, and add files to your project.
I Staging Area/Index - When you add a file (git add hfilei from the command line, or Add to Index in Eclipse), the file is added to this second tree, the staging area. This is where you prepare the files that you would like to eventually commit to your repository.
I Repository - When you commit the changes made to your
files (git commit by command line, Commit in Eclipse),
changes made to the files in your staging area are added to
the repository as new versions of those files. You must specify
a commit message with each commit to let others know what
you have changed.
Structure
The Local Repository
Figure: Local Repository Workflow
Structure
The Remote Repository
I When you are ready for others on your team to be able to view and pull your changes into their own local repositories, you can push your committed changes to the remote repository.
I If anyone else has pushed changes to your remote repository, Git will make you pull those changes into your own local repository before pushing any new changes.
I If you and your partner have been working on different parts
of your code, Git will automatically merge in your partner’s
changes smoothly. If you have been working on the same
code, however...
Structure
The Remote Repository
Figure: Remote repository workflow
Conflicts and Reverting
Merge conflicts
If you and your partner have both modified the same code, Git will be unsure about which version you would like it to use - yours, or theirs? To fix this, Git will ask you to resolve merge conflicts.
Figure: Eclipse Merge Conflict Tool
Conflicts and Reverting
Merge conflicts
Once you have your Local File Workspace version of the file looking
how you would like, you can right click on the file to mark it as
merged. You can then commit your merge, and push it as normal.
Conflicts and Reverting
Git Workflow - Reverting a File
Figure: A Git Workflow
CS 2112 Lab: Version Control
Conflicts and Reverting
EGit Commands to Remember!
I Team → Add to Index — Add a file to your Index if you want to track the changes you make in it, and commit those changes later.
I Team → Commit — Commit changes in your working directory to your local repository; these changes will be pushed to the remote repository on the next Push command.
I Team → Synchronize Workspace — This will pull from the remote repository and make sure that your local repository is up to date (needed especially before a Push)
I Push or Team → Push Branch — Pushes all your
committed changes to the remote repository
The shell: a lower-level interface
A shell is a command-line interface to your computer’s operating system. Less pretty than the GUI interface, more functional.
I Windows: cmd, Cygwin (Unix on Windows), or PowerShell
I Unix (Mac OS X, Linux): sh (bash), (t)csh
Shell commands
A shell command consists of a program name followed by some optiona command-line arguments. Spaces separate the command and the arguments from each other.
Examples:
I rm hfilenamei (Windows: del hfilenamei) : remove a file
I ls hdirectoryi (Windows: dir hdirectoryi): list contents of directory
I echo hmessagei : print the message to standard output
I cat hfilenamei (Windows: type hfilenamei) : print the contents of the file.
I cd hdirectoryi : change the current directory (shell built-in
command)
Command context
Every command is executed with some context provided by the operating system:
I The current directory in which the command runs. All files accesses are relative to this directory. Note: folders are known as directories at the operating system level.
I A set of environment variables that can be looked up by the running program. 1
I Standard input and output devices. Normally standard input reads from the shell’s input and output goes to the shell.
However, it is possible to override these. The syntax >
hfilenamei redirects output to the specified file.
1
The ShellShock vulnerability exploits a bug in how the bash shell handles
environment variables.
Pathnames and directories
I Files and directories are specified by pathnames: names separated by slashes (Unix, Cygwin) or backslashes (Windows).
I Pathnames starting with a slash (backslash) are absolute and start from the root of the file system.
I The special directory “.” means the current directory, and
“..” means the parent directory of the current directory.
I
To go up a directory: cd ..
I
To go to the root directory: cd /
I
