Version ControlDr. Ewan Barr Swinburne University of Technology Computing for Physics Honours Lectures 01/06/2015

Problems

Managing code that is constantly changing

Working on projects with many collaborators

Experimenting with code without breaking it

Always being backed up

Mo Code Mo Problems

As code bases or documents grow, they become harder to manage

Python has thousands of developers writing core libraries (millions lines of source code)

Everyone works to their own schedule, impossible to synchronize all developers

Enter version control...

Version Control 101Version control only stores changes

Changes are stored sequentially

A document/code base becomes a history of changes

Version Control 101Multiple collaborators can work on the document

Versions can be merged

Version control provides you with a time traveling,

dimension hopping safe for all your code

Common Version Control Tools

ModernLegacy

Git

Modern distributed version control system

Developed for Linux kernel configuration control

Linux kernel 3.6 has 15.9 million lines of code

Cross platform

CLI or GUI

Slowly being adopted by the scientific community

Git Key Terminology

Repository (“Repo”) -- Project files and their histories

Commit -- An individual change made to the repo

Branch -- A parallel version of a repo

Working directory -- The actual directory where we edit

Git Key Terminology

Repository (“Repo”) -- Project files and their histories

Commit -- Different times

Branch -- Different dimensions

Working directory -- The actual directory where we edit

Hands on: setup a repo

Let’s setup our own repo:

mkdir vcs_code

cd vcs_code

git init

Next check on the status of the repo:

git status

Making commits

A commit records changes to one or more files in the repo.

To make a commit we must first add our changes to a staging area:

File in working directory

Hands on: adding a fileLet’s write a little GUI that prints something:

edit ui.py (add some code)

git add ui.py

git commit

Let’s check the status and also commit log:

git status

git log

Aside - Good commit messages

Credit: http://chris.beams.io/posts/git-commit/

Making a change

Let’s modify our GUI a bit:

edit ui.py (let’s change what is printed)

git add ui.py

git commit -m “Alter print output”

Check the log

git log

The project history

1

2

Master

HEAD

Commits

Branch name

Points to head of current branch

The project history

1

2

Master

HEAD~1

HEAD~1 “Head minus one”

points to last but one commit

Reverting changesAll previous commits can be referenced by HEAD~N

Alternatively specific commits can be referenced by their unique SHA key

Let’s “checkout” an older version of ui.py

git checkout HEAD~1 ui.py

We can undo this with:

git checkout HEAD ui.py

Branching

1 2 master HEAD

How do I mess around with existing code without breaking it

Working but I want to add a new feature

Branching

1 2 master

HEAD

How do I mess around with existing code without breaking it

feature

git checkout -b feature HEAD

Branching

1 2 master

HEAD

How do I mess around with existing code without breaking it

feature3 4

Do some development on “Feature” branch

Merging

1 2 master HEAD

Combining branches

feature3 4

Merge new feature back into “Master” branch

5

Why not just do the new feature in “Master”?

Merging

1 2 master HEAD

feature3 6

Merge new feature back into “Master” branch

7

Branching allows for simultaneous development

4 5

Combining branches

Merging

1 2 master HEAD

feature3 6

Merge new feature back into “Master” branch

7

In the “Master” branch the merge is seen a single big commit of the entire “Feature” branch

4 5

Combining branches

Rebasing

1 2 master HEAD

feature3 6

74 5

Combining branches

Rebasing is an alternative to merging

Base of “Feature” replaced by HEAD of “Master”

Rebasing

1 2 master HEAD

feature3 6

74 5

Rebasing is an alternative to merging

Base of “Feature” replaced by HEAD of “Master”

Combining branches

Rebasing

1 2 master HEAD

feature3a 6a

74 5

Rebasing is an alternative to merging

Rebased commits are then recommited to “Master”This gives a linear project historyAll “Feature” commits in “Master”

Combining branches

Changing branches

1 2 master HEAD

feature3 6

74 5

git checkout feature

Changing branches

1 2 master

HEADfeature3 6

74 5

git checkout master

Advanced branches

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Collaborating

Central repo

Collaborating

Central repo

Collaborating

Central repo

User A local repo User B local repo

Clone Clone

Aside: Remotes

External repo’s are called “remotes”

When a you “clone” a repository, git automatically creates a remote called “origin”

“origin” points back to the original repository

Git stores local versions of all remote repos

These can be referenced like branches: “origin/master” is the master branch of the original repo

Collaborating

Central repo

User A local repo User B local repo

edit -> add -> commit

How do we make user A’s edits available to user B?

Collaborating

Central repo

User A local repo User B local repo

How do we make user A’s edits available to user B?

git push origin master

Collaborating

Central repo

User A local repo User B local repo

How do we make user A’s edits available to user B?

git pull origin master

Collaborating

Central repo

User A local repo User B local repo

What if both try to push?

Collaborating

Central repo

User A local repo User B local repo

git push git push FailPass

User B must first pull and merge A’s changes before pushing to the same branch.

Collaborating

Central repo

User A local repo User B local repo

git push

A pull first fetches any remote changes then merges them into the local repository

git pull

Pass

Hands on: using GitHub

Let’s make a new online public repo

Push our vcs_code repo

Try and clone our online repo

Git workflows

Workflows are different methods of collaboration

Type of workflow used depends on:

Size of project

Type of project

Familiarity of collaborators with Git (important!)

Centralised Workflow

Central repo

User A repo

User B repo

User C repo

Central repo online

Each user has their own clone

User workflow:

pull -> add -> commit -> push

Only master branch on central repo

Forking WorkflowUser A

online repoUser B

online repo “central”

User C online repo

User A repo

User B repo

User C repo

Each user has their own online repo and local repo

One online repo is designated “central”

Users develop own repo

“central” user merges other repos using “pull requests”

Resources

https://www.atlassian.com/git/tutorials

http://swcarpentry.github.io/git-novice/

http://gitolite.com/gcs.html

plus many, many more...

Do this!