View
10
Download
0
Category
Preview:
Citation preview
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!
Recommended