Version Control

Let there be collaboration

Joey Freund, CSC301, Fall 2014

The Problem

• Collaboration is difficult.
• Coordinating tasks
• Communicating quickly and efficiently
• Keeping everybody up to date all the time

Collaboration

• Not just a software problem:
• Organize dinner for 10 people
• Camping trip with a large group
• Team student project
• etc.�
• We’ll focus on collaboration between software developers.

Requirements

1. Multiple people can edit the same codebase.

Very Simple Solution

• Shared folder + some conventions:
• Read/write files in the folder.
• Use email (or instant messaging) to avoid stepping on each other’s toes.

New Requirements

• Multiple editors
• Rollback to any previous version.

​

Simple Solution

• Use Google Docs �(or any of its equivalents)
• Collaboration is built-in

New Requirements

• Multiple editors
• Rollback to previous versions
• Coding-specific requirements
• Load code in an IDE (e.g. Eclipse) or text editor.
• Work locally and commit when ready
• Support binary files
• And more ...

Solution - Version Control System

• VCS software is installed on a server.
• Code is stored in a repository on the server.
• Team members can ...
• Checkout a copy of the repository to their local machine, and make changes.
• When changes are ready, they get committed (i.e. saved) back to the repository.
• The VCS requires conflicts to be resolved before they can be committed to the repository.

New Requirements

• Multiple editors
• Rollback to previous versions
• Coding-specific requirements
• Better support large teams and open-source collaboration.

Solution - Distributed VCS

• No single “official” repository.
• Repositories (with their complete history) can be cloned at any point in time.
• Changes (aka commits) can be pushed/pulled between repositories that were once identical clones.

VCS vs. DVCS

Advantages of DVCS

• Work offline and push changes later.
• Granularity - Make small commits and push them together.
• Delegate responsibilities from a project maintainer (single person) to the developers (possibly many people).

Contribute to OSS with SVN

• One alternative:
• Ask project maintainer for write-permission
• Checkout local copy
• Commit all of your local changes�
• OK for teams of 2-3 people, but you cannot just give write permissions to anyone on a large project (e.g. Linux).

Contribute to OSS with SVN

• Another alternative:
• Checkout a local copy
• Do your work locally
• Generate a patch and send it to the project maintainer.�
• Better, but not perfect ...

Contribute to OSS with SVN

• Problems with our previous approach:
• Assigning too much work to a single project maintainer creates a bottleneck.
• If the code changed since checkout, patch might create conflicts.
• Cannot benefit from VCS features (like branching and rolling back) for experimental work.

Contribute to OSS with DVCS

• Clone a repository
• Work on the local clone
• Contribute changes back:
• Pull new changes from the original repository.
• Fix conflicts/bugs.
• Request project maintainer to pull changes from the local clone to the original repo.

Git

• In CSC207, you used SVN, a popular VCS,.
• In CSC301, we will use a DVCS, called Git.
• Git is free and open-source.
• Git is the industry standard for version control.

GitHub

• GitHub is a service/company that hosts Git repositories.
• Repositories are accessible over the internet.
• Great collaboration tools.
• Web UI with many useful features: Analytics, Issue management, Wiki, and many more.
• Automation & integration with external services.
• The industry standard for open-source projects.

Learning Git

Many resources on the web, for example:

• A Simple Guide
• Training page on GitHub and BitBucket
• An interactive tutorial
• Pro Git - A whole book on Git
• Git for Computer Scientists

Learning Git

• Git & GitHub are used by some of the largest software projects today.
• Both tools have many features.
• Start with the ones you use on a regular basis.
• Learn new features as your project and/or team have new needs.
• Let’s start with some basics ...

# Clone a remote repository

> git clone https://github.com/csc301-fall2014/test-repo.git

> cd test-repo

​

# Two useful commands

> git status

> git log

# Add (and commit) a new file

> echo "hello" > a.txt

> git add a.txt

> git commit -m "Adding a file"

# Try these now ...

> git status

> git log

# Push the changes to the remote repository

> git push origin master

> git status

​

​

# Workflow example

# ----------------

# Make local changes …

# Pull changes from the remote repository

> git pull

# Resolve conflicts manually, if necessary …

> git commit -a -m "Resolved conflicts"

> git push origin master

​

​

Branching

• Branching is one of the most important features in any version control system.
• A branch is like a “parallel timeline”.
• Allows us to work on a number of features in parallel.
• Common workflow: Branch out, work on some feature, merge back when ready.

# Create (and switch to) a new branch

> git checkout -b feature_branch

# Commit some changes to this branch

> echo "foo" > b.txt

> git add b.txt

> git commit -m "Adding another file"

# Let’s see the status and log …

> git status

> git log --graph

# Switch between branches

> git checkout master

> ls

> git checkout feature_branch

> ls

​

# Create the branch at the remote repository,

# and push the changes

> git push origin feature_branch

​

# Merge the branch back with the master branch

> git checkout master

> git merge feature_branch

# Push the changes to the remote repo’s master

> git push origin master

​

Git Terminology

• Init (i.e. create) a new repo.
• Clone an existing repo.
• Checkout (i.e. switch between) branches.
• Add changes to be committed.
• Commit changes.
• Push commits to a remote repo.
• Pull commits from a remote repo.

Git Terminology

• Familiarity with the terminology will make it easier for you to search answers on the Internet.
• It will also make it easier for you to communicate with your team members.

Git in practice

• Let’s look at a few scenarios, and think of how we can handle them using Git …

Usage Scenarios

• Who: Software developer
• What: Wants to work on a codebase, and go back to previous versions, if needed.
• Why: So that he/she can develop faster, and avoid the headache of backing up different versions.

Using Git

• Init a local repo.
• Add and commit changes periodically.
• If needed, revert to a previous version.

Usage Scenarios

• Who: Single developer
• What: Wants to be able to work on a number of features in parallel.
• Why: So that he/she can try different ideas separately without manually managing different copies of the codebase.

Using Git

• Use the basic features of Git.
• Create a branch for each feature.
• Merge the branch when the feature is ready and tested.

Usage Scenarios

• Who: Open Source Software developer
• What: Wants repo stored and backed up remotely, and made accessible over the internet.
• Why: So that he/she
• Doesn’t have to worry about backups.
• Can access the repo from different locations.

Using Git

• Sign up for a service like GitHub or BitBucket, and create a repo.
• Clone the repo, and use the same Git workflow as in the previous scenario.
• Push local changes to the remote repo.
• Pull remote changes to the local repo.

Usage Scenarios

• Who: Software Development Team Manager
• What: Wants insight into the dev process
• Who is committing what?
• Which features are being worked on? By whom? And, for how long?
• Why: So that he/she can better understand what individual team members are working on.

Using Git

• Use features like status, log and diff.
• Optionally, use services like GitHub or BitBucket that provide detailed analytics and graphs.
• Optionally, use other visualization tools to get a better view of the codebase, as it’s changing over time.

Usage Scenarios

• Who: Soft. Eng. University Instructor
• What: Wants to manage code distribution and submission.
• Why:
• Students will be able to work individually and in teams, using to modern tools.
• He/she can see which students are working on what.

Using Git

• Use a service like GitHub or BitBucket that provides user management, private repositories, and analytics.
• Use Git and some custom-built scripts to automate tasks.

Usage Scenarios

• Who: Soft. Eng. Team
• What: Wants to simplify and automate code releases.
• Why: In order to easily release code updates multiple times a day.

Using Git

• Advanced features of Git, like web hooks.
• Web hooks allow us to send a notification whenever an event occurs in the repo.
• For example: Whenever we are notified that someone committed code to master, we can:
• Run all automated tests.
• If all tests pass, release the new version.
• Otherwise, revert the commit.

Let’s stop here

Your Homework

• Sign up for our discussion board.
• Mini-exercise, due in a week.
• Sign up for a GitHub account.
• Let us know your GitHub username.
• Push some changes to your (private) repository (that will be created for you)on GitHub.