Version control for fun and profit:¶

the tool you didn't know you needed¶

Sources of this material:¶

This tutorial is adapted from "Version Control for Fun and Profit" by Fernando Perez

For an excellent list of Git resources for scientists, see Fernando's Page.

Fernando's original notebook specifically mentions two references he drew from:

• "Git for Scientists: A Tutorial" by John McDonnell
• Emanuele Olivetti's lecture notes and exercises from the G-Node summer school on Advanced Scientific Programming in Python.

Via Fernando, some of the images below are copied from the Pro Git book

Also see J.R. Johansson's tutorial on version control, part of his excellent series Lectures on Scientific Computing with Python

What is Version Control?¶

From Wikipedia:¶

“Revision control, also known as version control, source control or software configuration management (SCM), is the management of changes to documents, programs, and other information stored as computer files.”

Reproducibility?¶

• Tracking and recreating every step of your work
• In the software world: it's called Version Control!

What do (good) version control tools give you?

• Peace of mind (backups)
• Freedom (exploratory branching)
• Collaboration (synchronization)

Git is an enabling technology: Use version control for everything¶

• Paper writing (never get paper_v5_jake_final_oct22_9.tex by email again!)
• Grant writing
• Everyday research
• Teaching (never accept an emailed homework assignment again!)
• Code management
• Personal website history tracking

The plan for this tutorial¶

• Overview of Git key concepts

• Hands-on work with Git

• 5 "stages" of using Git:

  1. Local, single-user, linear workflow
  2. Single local user, branching
  3. Using remotes as a single user
  4. Remotes for collaborating in a small team
  5. Full-contact github: distributed collaboration with large teams

High level picture: overview of key concepts¶

The commit: a snapshot of work at a point in time

Credit: ProGit book, by Scott Chacon, CC License.

Looking at my current directory:¶

A repository: a group of linked commits

Note: these form a Directed Acyclic Graph (DAG), with nodes identified by their hash.

A hash: a fingerprint of the content of each commit and its parent

And this is pretty much the essence of Git!

First: Configuring Git¶

The minimal amount of configuration for git to work without pestering you is to tell it who you are. All the commands here modify the .gitconfig file in your home directory.

Modify these before running them:

Other settings¶

Change how you will edit text files (it will often ask you to edit messages and other information, and thus wants to know how you like to edit your files):

Password memory¶

Set git to use the credential memory cache so we don't have to retype passwords too frequently. On Linux, you should run the following (note that this requires git version 1.7.10 or newer):

Github offers in its help pages instructions on how to configure the credentials helper for Mac OSX and Windows.

Double-checking the result:¶

Stage 1: Local, single-user, linear workflow¶

Simply type git to see a full list of all the 'core' commands. We'll now go through most of these via small practical exercises:

git init: create an empty repository¶

Note: all these cells below are meant to be run by you in a terminal where you change once to the test directory and continue working there.

Since we are putting all of them here in a single notebook for the purposes of the tutorial, they will all be prepended with the first two lines:

%%bash
cd test

that tell IPython to do that each time. But you should ignore those two lines and type the rest of each cell yourself in your terminal.

Let's look at what git did:

Now let's edit our first file in the test directory with a text editor... I'm doing it programatically here for automation purposes, but you'd normally be editing by hand

git add: tell git about this new file¶

We can now ask git about what happened with status:

git commit: permanently record our changes in git's database¶

For now, we are always going to call git commit either with the -a option or with specific filenames (git commit file1 file2...).

This delays the discussion of an aspect of git called the index (often referred to also as the 'staging area') that we will cover later. Most everyday work in regular scientific practice doesn't require understanding the extra moving parts that the index involves, so on a first round we'll bypass it. Later on we will discuss how to use it to achieve more fine-grained control of what and how git records our actions.

In the commit above, we used the -m flag to specify a message at the command line.

If we don't do that, git will open the editor we specified in our configuration above and require that we enter a message.

By default, git refuses to record changes that don't have a message to go along with them (though you can obviously 'cheat' by using an empty or meaningless string: git only tries to facilitate best practices, it's not your nanny).

git log: what has been committed so far¶

git diff: what have I changed?¶

Let's do a little bit more work... Again, in practice you'll be editing the files by hand, here we do it via shell commands for the sake of automation (and therefore the reproducibility of this tutorial!)

And now we can ask git what is different:

The cycle of git virtue: work, commit, work, commit, ...¶

git log revisited¶

First, let's see what the log shows us now:

Sometimes it's handy to see a very summarized version of the log:

Defining an alias¶

Git supports aliases: new names given to command combinations. Let's make this handy shortlog an alias, so we only have to type git slog and see this compact log:

git mv and rm: moving and removing files¶

While git add is used to add fils to the list git tracks, we must also tell it if we want their names to change or for it to stop tracking them. In familiar Unix fashion, the mv and rm git commands do precisely this:

Note that these changes must be committed too, to become permanent! In git's world, until something hasn't been committed, it isn't permanently recorded anywhere.

And git rm works in a similar fashion.

Exercise¶

Add a new file file2.txt, commit it, make some changes to it, commit them again, and then remove it (and don't forget to commit this last step!).

2. Single Local user, branching¶

What is a branch? Simply a label for the 'current' commit in a sequence of ongoing commits:

Mulitple Branches¶

There can be multiple branches alive at any point in time; the working directory is the state of a special pointer called HEAD. In this example there are two branches, master and testing, and testing is the currently active branch since it's what HEAD points to:

Once new commits are made on a branch, HEAD and the branch label move with the new commits:

This allows the history of both branches to diverge:

But based on this graph structure, git can compute the necessary information to merge the divergent branches back and continue with a unified line of development:

Branching Example¶

Let's now illustrate all of this with a concrete example. Let's get our bearings first:

We are now going to try two different routes of development: on the master branch we will add one file and on the experiment branch, which we will create, we will add a different one. We will then merge the experimental branch into master.

3. Using remotes as a single user¶

We are now going to introduce the concept of a remote repository: a pointer to another copy of the repository that lives on a different location. This can be simply a different path on the filesystem or a server on the internet.

For this discussion, we'll be using remotes hosted on the GitHub.com service, but you can equally use other services like BitBucket or Gitorious as well as host your own.

If you don't have a Github account, take a moment now to sign up

git remote: view/modify remote repositories¶

Since the above cell didn't produce any output after the git remote -v call, it means we have no remote repositories configured.

Configuring a remote¶

Log into GitHub, go to the new repository page and make a repository called test.

Do not check the box that says Initialize this repository with a README, since we already have an existing repository here. That option is useful when you're starting first at Github and don't have a repo made already on a local computer.

We can now follow the instructions from the next page:

Let's see the remote situation again:

Pushing changes to a remote repository¶

Now push the master branch to the remote named origin:

We can now see this repository publicly on github.

Using Git to Sync Work¶

Let's see how this can be useful for backup and syncing work between two different computers. I'll simulate a 2nd computer by working in a different directory...

Let's now make some changes in one 'computer' and synchronize them on the second.

Now we put this new work up on the github server so it's available from the internet

Now let's fetch that work from machine #1:

An important aside: conflict management¶

While git is very good at merging, if two different branches modify the same file in the same location, it simply can't decide which change should prevail. At that point, human intervention is necessary to make the decision. Git will help you by marking the location in the file that has a problem, but it's up to you to resolve the conflict. Let's see how that works by intentionally creating a conflict.

We start by creating a branch and making a change to our experiment file:

And now we go back to the master branch, where we change the same file:

The conflict...¶

So now let's see what happens if we try to merge the trouble branch into master:

Let's see what git has put into our file:

At this point, we go into the file with a text editor, decide which changes to keep, and make a new commit that records our decision. I've now made the edits, in this case I decided that both pieces of text were useful, but integrated them with some changes:

Let's then make our new commit:

Merge Tools¶

Note: While it's a good idea to understand the basics of fixing merge conflicts by hand, in some cases you may find the use of an automated tool useful.

Git supports multiple merge tools: a merge tool is a piece of software that conforms to a basic interface and knows how to merge two files into a new one. Since these are typically graphical tools, there are various to choose from for the different operating systems, and as long as they obey a basic command structure, git can work with any of them.

4. Collaborating on github with a small team¶

Here we will set up a shared collaboration with one partner -- choose someone sitting next to you.

We will have two people, let's call them Alice and Bob, sharing a repository. Alice will be the owner of the repo and she will give Bob write privileges.

Find a partner & decide who will be Alice, and who will be Bob.

Note for SVN users: this is similar to the classic SVN workflow, with the distinction that commit and push are separate steps. SVN, having no local repository, commits directly to the shared central resource, so to a first approximation you can think of svn commit as being synonymous with git commit; git push.

1. Synchronization¶

We begin with a simple synchronization example. Working together, follow these steps:

Creating a new repository¶

• Alice: create a new repository on github called AliceBob
• Alice: create a file README.md, commit it, and push it to the remote.
• Alice: on github, go to the settings for AliceBob, and add your partner to the list of collaborators

Cloning your partner's repository¶

• Bob: clone the AliceBob repository using git clone [url]
• Bob: makes changes to the README.md file and commit locally.
• Bob: push changes to github.
• Alice: pull Bob's changes to the local repository.

Now Alice and Bob should both have the same README.md file on their own computer.

2. Dealing with conflicts¶

Next, we will have both parties make non-conflicting changes each, and commit them locally. Then both try to push their changes:

• Alice: create & commit a new file, alice.txt to the local repo
• Bob: create & commit a new file, bob.txt to the local repo
• Alice: push the latest commit to github
• Bob: try to push to github. What happens?

The problem is that Bob's changes create a commit that conflicts with Alice's, so git refuses to apply them.

Bob must do

git pull origin master

And then deal with the conflict manually, then push again.

5. Full-contact github: distributed collaboration with large teams¶

On large teams, you don't always want all contributors to have access to the main repository. So how do you move forward? Using Pull Requests.

Again, we'll do this as an exercise with your partner:

[Brief demo of how this works on scikit-learn]

We'll practice this here, by having Alice now fork Bob's repository.

1. Bob: create a new repository named BobAlice with a README.md file, and push it to the github remote.

2. Alice: go to Bob's github page and click the fork button. You now have your own remote version of the repository, that looks like http://github.com/Alice/BobAlice.git

3. Alice: use git clone [url] to get a local version of your fork on your own computer.

4. Alice: use git remote add upstream [url] to add a pointer to Bob's remote (the original)

5. Alice: type git remote -v, and you should see both your own fork (called origin) and Bob's fork (called upstream)

6. Alice: create a new branch called alice_changes

7. Alice: add a file called alice.txt commit, and use git push origin alice_changes to push to the remote.

8. Alice: reload the github page for your own fork: there should now be a button that says "compare and pull request". Click it and fill it out.

9. Bob: go to your own notifications page (the blue circle in the upper-left of GitHub) and you should see a notification of Alice's Pull request. Check the diff, add some comments, and merge the changes.

10. Alice: on your computer, checkout the master branch, and update it from Bob's fork with git pull upstream master

Congratulations! You're now a collaborator!

This is how virtually all open source collaboration proceeds on Github!

Other useful commands¶

• show
• reflog
• rebase
• tag

Git resources¶

Introductory materials¶

There are lots of good tutorials and introductions for Git, which you can easily find yourself; this is just a short list of things I've found useful. For a beginner, I would recommend the following 'core' reading list, and below I mention a few extra resources:

1. The smallest, and in the style of this tuorial: git - the simple guide

contains 'just the basics'. Very quick read.

1. The concise Git Reference: compact but with all the key ideas. If you only read one document, make it this one.

2. In my own experience, the most useful resource was [Understanding Git

Conceptually](http://www.sbf5.com/~cduan/technical/git). Git has a reputation for being hard to use, but I have found that with a clear view of what is actually a very simple internal design, its behavior is remarkably consistent, simple and comprehensible.

1. For more detail, see the start of the excellent Pro Git online book, or similarly the early parts of the Git community book. Pro Git's chapters are very short and well illustrated; the community book tends to have more detail and has nice screencasts at the end of some sections.

If you are really impatient and just want a quick start, this visual git tutorial may be sufficient. It is nicely illustrated with diagrams that show what happens on the filesystem.

For windows users, an Illustrated Guide to Git on Windows is useful in that it contains also some information about handling SSH (necessary to interface with git hosted on remote servers when collaborating) as well as screenshots of the Windows interface.

Cheat sheets

Two different

[cheat](http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html)
[sheets](http://jan-krueger.net/development/git-cheat-sheet-extended-edition)
in PDF format that can be printed for frequent reference.

Beyond the basics¶

At some point, it will pay off to understand how git itself is built. These two documents, written in a similar spirit, are probably the most useful descriptions of the Git architecture short of diving into the actual implementation. They walk you through how you would go about building a version control system with a little story. By the end you realize that Git's model is almost an inevitable outcome of the proposed constraints:

• The Git parable by Tom Preston-Werner.
• Git foundations by Matthew Brett.

Git ready

A great website of posts on specific git-related topics, organized

by difficulty.

QGit: an excellent Git GUI

Git ships by default with gitk and git-gui, a pair of Tk graphical

clients to browse a repo and to operate in it. I personally have
found [qgit](http://sourceforge.net/projects/qgit/) to be nicer and
easier to use. It is available on modern linux distros, and since it
is based on Qt, it should run on OSX and Windows.

Git Magic

Another book-size guide that has useful snippets.

The learning center at Github

Guides on a number of topics, some specific to github hosting but

much of it of general value.

A port of the Hg book's beginning

The Mercurial book has a reputation

for clarity, so Carl Worth decided to
[port](http://cworth.org/hgbook-git/tour) its introductory chapter
to Git. It's a nicely written intro, which is possible in good
measure because of how similar the underlying models of Hg and Git
ultimately are.

Intermediate tips

A set of tips that contains some very valuable nuggets, once you're

past the basics.