Version Control

GIT, WORKFLOW & TOOLS

What is version control?

System that tracks changes to files
Allows a user to:

Recall specific versions of a file

Revert (roll back) file changes
View changes over time
Work out who to blame for changes

Allows multiple users to work on the same file and merge changes
safely

COMP204-16B (HAM) - CAMERON GROUT

What software options exist?

Centralised version control

Subversion (SVN)
Team Foundation Server (TFVC)
Perforce
Concurrent Versions System (CVS)

Distributed version control

Git
Mercurial (Hg)
Bazaar
Bitkeeper
Darcs

COMP204-16B (HAM) - CAMERON GROUT

Why distributed?
No single point of failure
If one developer machine explodes, other developers still have a complete
copy
Simple to restore

Common operations are fast

Committing, checking revisions, reverting are quick and dont disrupt
workflow

Can work disconnected from a network

Can develop at home, on a train, bus wherever

COMP204-16B (HAM) - CAMERON GROUT

Git
Distributed version control system (DVCS)
Primarily command-line based

Written by Linus Torvalds (Linux kernel)

Initially written for kernel development needs, now generalised

Most widely used DVCS[1]

Useful for your careers to have experience with this

Free software (GNU License)

You will be using Git for your assignments
[1] http://ianskerrett.wordpress.com/2014/06/23/eclipse-community-survey-2014-results/

COMP204-16B (HAM) - CAMERON GROUT

Getting Git
For Windows
Download installer from http://git-scm.com/download/win
Install
Select Use Git from the Windows Command Prompt option during
installation for optimal experience

For Linux, install via your package manager of choice

aptitude install git for debian systems

For Mac, multiple solutions depending on preference

brew install git for homebrew

COMP204-16B (HAM) - CAMERON GROUT

Graphical frontends
Will be covering command line usage primarily, recommended you
learn this
Helps you better understand what is happening
If the command is long and archaic, you probably shouldnt be doing it!

Will save you time in the future

Graphical tools exist, and do have some use-cases where they beat out
the command line
Check http://gitscm.com/downloads/guis for options
A personal recommendation would be TortoiseGit or SourceTree

COMP204-16B (HAM) - CAMERON GROUT

Getting started with Git

First up, you need to tell Git about yourself

In a terminal
git config --global user.name Cameron Grout
git config --global user.email cgrout@waikato.ac.nz
git config --global color.ui true

This tells git about you so that it can add this information to your commits
Useful for collaboration, you know who to contact about changes

These are global settings and act as defaults. You can set repository specific
settings if you want to maintain a personal/professional identity gap
COMP204-16B (HAM) - CAMERON GROUT

Git config?
The git application is actually a suite of commands
config is one of the sub-commands
Used for modifying configurations without diving in with a text editor

Git provides the help sub-command to provide usage information for

commands
git help will give you a list of basic sub-commands
git help config will give you information specifically about the config
subcommand

If you ever need help with syntax, check help first

COMP204-16B (HAM) - CAMERON GROUT

Starting from scratch

Navigate to your project directory on your file system
The project can be empty or already have code in it

In a terminal, type
git init

You have just created a git repository

You will now have a .git folder in your project directory (hidden directory)
This is where the repository information is kept
DO NOT MODIFY THIS FOLDER OR ITS CONTENTS

COMP204-16B (HAM) - CAMERON GROUT

10

Getting an existing repo

Navigate to the directory where you want the code to go
In a terminal, type
git clone https://gitlab.cms.waikato.ac.nz/cgrout/Git-Introduction.git

The directory will now contain a folder called `Git-Introduction` containing

the code and repository information
Again, do not touch the .git folder

The clone URL listed is just an example, yours will differ. You can use any
sort of path there, not just URLs

COMP204-16B (HAM) - CAMERON GROUT

11

Look at what we have

git status will show you the current repository state
Are there files that arent tracked?
Have files been modified/removed?
Are you looking at the most recent commit (tip)?

On a cloned repository, git status will tell us everything is up to date

On a new repository, it will tell us that any files that were in the folder
need to be tracked

COMP204-16B (HAM) - CAMERON GROUT

12

Setting the stage

When a file is added or changed, you need to tell git that you want to
track this change.
git add file.ext will tell git to track the change (add/modify) to file.ext

git add --all will tell git to track all new files and changes
git add *.java will tell git to track all new or changed .java files (note

the quotes)

When you want to remove a file from the repo, you need to indicate
this to git
git rm file.ext will tell git to stop tracking file.ext, and will delete to file

from disk
git rm --cached file.ext will tell git to stop tracking file.ext without

deleting it
COMP204-16B (HAM) - CAMERON GROUT

13

Taking a snapshot
Once you have told git about items that have been added, removed or
modified, you need to tell it to commit this to memory
git commit

This will prompt you to add a commit message by opening your editor
Can avoid this by supplying the commit message inline
git commit -m This is my commit message

Commit messages tell others (and you) what changed between the
current and previous commit
Helpful for working out when a bug was fixed (or not)

COMP204-16B (HAM) - CAMERON GROUT

14

What does it all mean?

Version control stores snapshots of the repository

Before you take a snapshot, you have to arrange (stage) the shot
Just like with a camera, you dont just snap a picture
Frame and organize the scene before taking the picture

Once you have staged all the repository changes, you are ready to take a
snapshot

COMP204-16B (HAM) - CAMERON GROUT

15

So what does our workflow

look like?
Edit and add files
Text editor/IDE as per normal

Stage new and changed files

Remember, you need to git add file.ext for modified files to stage the
changes

Commit the changes

Include a useful message! Avoid trite messages like context, or commit,
they are not useful and you will kick yourself later

COMP204-16B (HAM) - CAMERON GROUT

16

How can you see commits?

git log will give information about prior commits
Who made the commit
When it was done
What changed (commit message)

git log --stat will tell you what happened to which files
More verbose, useful when looking at a specific commit

git show <commit-id> will show the exact file changes for the specified
commit
This is an area where GUI tools excel
Picking specific commits to look at using the command line is clunky

COMP204-16B (HAM) - CAMERON GROUT

17

Local workflow
init|clone ((add|rm|log|status)* commit)*

Simple, only a few commands to worry about

init/clone
status
add/rm
commit
log

COMP204-16B (HAM) - CAMERON GROUT

18

How regularly should you

commit
Whenever you make a significant change

Create new file with skeleton class

Modify a method body
Fix a bug
Add new binary files/assets

Keep it granular so that you can easily track down where issues were
introduced
One commit with 200 lines of code changed isnt that helpful

Not too granular though, not one per line of code if not needed

COMP204-16B (HAM) - CAMERON GROUT

19

Connecting to a remote
repository
Keep track of remote repositories using remotes that are stored in
your local repository
Can have as many of these as you like
If you cloned a repository, git will add the clone path as a remote
automatically named origin

If you initd your repository, you need to add the remote manually
git remote add <alias> <path>
git remote add origin http://gitlab.waikato.ac.nz/cgrout/GitIntroduction.git

You can now exchange files and changes with the remote
COMP204-16B (HAM) - CAMERON GROUT

20

Communicating with the

remote
Pushing is sending commits from your local repository to a remote one
git push u origin master

Send the changes from master (local repo) to the origin (remote repo)
The -u stores the origin/master part, so in future you just use git push

Pulling is bringing changes from the remote repository to the local one
git pull origin master

Gets the changes from origin (remote repo) and brings them into master
(local)

You should always pull before pushing

COMP204-16B (HAM) - CAMERON GROUT

21

How do you undo/discard

changes?
git reset <filename> will un-stage a file
Use this if you have run git add but have changed your mind about adding
that file to the stage
Wont destroy your changes, merely un-stage them

git clean df will delete any and all untracked files

Use this if you created a new file but didnt stage or commit it and want it
gone
This is destructive, make sure you actually want these untracked files gone
before running this
Use git clean i to interactively select what files to get rid of
git checkout -- .

recent commit

will take all un-staged files back to the most

This will undo any changes you have made to files

COMP204-16B (HAM) - CAMERON GROUT

22

How do you get back to old

commits?
Checkout a specific commit by number
git log will list a commit id, a long alpha-numeric sequence that uniquely
identifies a commit
git checkout <commit_id> .
(NOTE: the trailing period)
git checkout e49800d .

Dont need to specify the whole commit id, just enough to make the id
unambiguous

To get back to the tip (most recent commit)

git checkout <branch_name>
git checkout master

COMP204-16B (HAM) - CAMERON GROUT

23

Repository permissions
If you dont have write permissions to a repository, you cant push to it
Makes collaboration annoying

Enter repository Forking

A feature found on most repository hosting services, including our hosted
GitLab instance

Performs a deep copy of the repository, and puts the copy in your
namespace, giving you write permissions to the copy
Your copy remembers how it relates to the original, which makes
collaboration using pull requests/merge requests a lot nicer
Pull requests/merge requests outside of scope for now
COMP204-16B (HAM) - CAMERON GROUT

24

Experience it
We have set up a GitLab instance for you to use for this course
http://gitlab.cms.waikato.ac.nz/
Go here and sign in with your normal username, with the last 8-digits of your
student ID barcode as your password.

Follow the instructions listed in the Readme tab of this repository

http://gitlab.cms.waikato.ac.nz/cgrout/Git-Introduction
Make sure it all works for you! You will be using this service for your
assignments, so let us know if there is a problem now, rather than on the
assignment due date

COMP204-16B (HAM) - CAMERON GROUT

25

Important Note
We can, and intend to, look at your GitLab repositories. Setting your
repositories to private just means that other students cannot see them,
but it does not prevent us from looking in.

Keep this in mind when uploading files and content to your repos. If you
dont want us to see or read something, dont upload it!

COMP204-16B (HAM) - CAMERON GROUT

26