Reading 5: Version Control

Version control systems are essential tools of the software engineering world. More or less every project — serious or hobby, open source or proprietary — uses version control. Without version control, coordinating a team of programmers all editing the same project’s code will reach pull-out-your-hair levels of aggravation.

Version control systems you’ve already used

• Dropbox
• Undo/redo buffer
• Keeping multiple copies of files with version numbers

Project Report	Project Report v2	Project Report v3	Project Report final	Project Report final-v2	Project Report final-v2-fix-part-5

Suppose Alice is working on a problem set by herself.

She starts with one file Hello.java in her pset, which she works on for several days.

At the last minute before she needs to hand in her pset to be graded, she realizes she has made a change that breaks everything. If only she could go back in time and retrieve a past version!

A simple discipline of saving backup files would get the job done.

Alice uses her judgment to decide when she has reached some milestone that justifies saving the code. She saves the versions of Hello.java as Hello.1.java, Hello.2.java, and Hello.java. She follows the convention that the most recent version is just Hello.java to avoid confusing Eclipse. We will call the most recent version the head.

Now when Alice realizes that version 3 is fatally flawed, she can just copy version 2 back into the location for her current code. Disaster averted! But what if version 3 included some changes that were good and some that were bad? Alice can compare the files manually to find the changes, and sort them into good and bad changes. Then she can copy the good changes into version 2.

This is a lot of work, and it’s easy for the human eye to miss changes. Luckily, there are standard software tools for comparing text; in the UNIX world, one such tool is diff. A better version control system will make diffs easy to generate.

Alice also wants to be prepared in case her laptop gets run over by a bus, so she saves a backup of her work in the cloud, uploading the contents of her working directory whenever she’s satisfied with its contents.

If her laptop is kicked into the Charles, Alice can retrieve the backup and resume work on the pset on a fresh machine, retaining the ability to time-travel back to old versions at will.

Furthermore, she can develop her pset on multiple machines, using the cloud provider as a common interchange point. Alice makes some changes on her laptop and uploads them to the cloud. Then she downloads onto her desktop machine at home, does some more work, and uploads the improved code (complete with old file versions) back to the cloud.

If Alice isn’t careful, though, she can run into trouble with this approach. Imagine that she starts editing Hello.java to create “version 5” on her laptop. Then she gets distracted and forgets about her changes. Later, she starts working on a new “version 5” on her desktop machine, including different improvements. We’ll call these versions “5L” and “5D,” for “laptop” and “desktop.”

When it comes time to upload changes to the cloud, there is an opportunity for a mishap! Alice might copy all her local files into the cloud, causing it to contain version 5D only. Later Alice syncs from the cloud to her laptop, potentially overwriting version 5L, losing the worthwhile changes. What Alice really wants here is a merge, to create a new version based on the two version 5’s.

At this point, considering just the scenario of one programmer working alone, we already have a list of operations that should be supported by a version control scheme:

• reverting to a past version
• comparing two different versions
• pushing full version history to another location
• pulling history back from that location
• merging versions that are offshoots of the same earlier version

Multiple developers

Multiple branches

The shocking conclusion

Distributed vs. centralized

Version control terminology

Features of a version control system

The version control system we’ll use in 6.005 is Git. It’s powerful and worth learning. But Git’s user interface can be terribly frustrating. What is Git’s user interface?

• In 6.005, we will use Git on the command line. The command line is a fact of life, ubiquitous because it is so powerful.

• The command line can make it very difficult to see what is going on in your repositories. You may find SourceTree (shown on the right) for Mac & Windows useful. On any platform, gitk can give you a basic Git GUI. Ask Google for other suggestions.

An important note about tools for Git:

• Eclipse has built-in support for Git. If you follow the problem set instructions, Eclipse will know your project is in Git and will show you helpful icons. We do not recommend using the Eclipse Git UI to make changes, commit, etc., and course staff may not be able to help you with problems.

• GitHub makes desktop apps for Mac and Windows. Because the GitHub app changes how some Git operations work, if you use the GitHub app, course staff will not be able to help you.

Getting started with Git

The Git object graph

How do you get the object graph from Athena to your local machine in order to start working on the problem set? git clone copies the graph.

Suppose your username is bitdiddle:

git clone ssh://.../psets/ps0/bitdiddle.git ps0

Hover or tap on each step to update the diagram below:

1. Create an empty local directory ps0, and ps0/.git.
2. Copy the object graph from ssh://.../psets/ps0/bitdiddle.git into ps0/.git.
3. Check out the current version of the master branch.

Diagram for highlighted step:

We still haven’t explained what’s in the object graph. But before we do that, let’s understand step 3 of git clone: check out the current version of the master branch.

The object graph is stored on disk in a convenient and efficient structure for performing Git operations, but not in a format we can easily use. In Alice’s invented version control scheme, the current version of Hello.java was just called Hello.java because she needed to be able to edit it normally. In Git, we obtain normal copies of our files by checking them out from the object graph. These are the files we see and edit in Eclipse.

We also decided above that it might be useful to support multiple branches in the version history. Multiple branches are essential for large teams working on long-term projects. To keep things simple in 6.005, we will not use branches and we don’t recommend that you create any. Every Git repo comes with a default branch called master, and all of our work will be on the master branch.

So step 2 of git clone gets us an object graph, and step 3 gets us a working directory full of files we can edit, starting from the current version of the project.

Let’s finally dive into that object graph!

Here’s the output of git lol for this example repository:

* b0b54b3 (HEAD, origin/master, origin/HEAD, master) Greeting in Java
*   3e62e60 Merge
|\  
| * 6400936 Greeting in Scheme
* | 82e049e Greeting in Ruby
|/  
* 1255f4e Change the greeting
* 41c4b8f Initial commit

The history of a Git project is a directed acyclic graph (DAG). The history graph is the backbone of the full object graph stored in .git, so let’s focus on it for a minute.

Each node in the history graph is a commit a.k.a. version a.k.a. revision of the project: a complete snapshot of all the files in the project at that point in time. You may recall from our earlier reading that each commit is identified by a unique ID, displayed as a hexadecimal number.

Except for the initial commit, each commit has a pointer to its parent commit. For example, commit 1255f4e has parent 41c4b8f: this means 41c4b8f happened first, then 1255f4e.

Some commits have the same parent: they are versions that diverged from a common previous version. And some commits have two parents: they are versions that tie divergent histories back together.

A branch — remember master will be our only branch for now — is just a name that points to a commit.

Finally, HEAD points to our current commit — almost. We also need to remember which branch we’re working on. So HEAD points to the current branch, which points to the current commit.

Check your understanding…

reading exercises

HEAD count

How many commits are in this project?

(missing answer)

(missing explanation)

How many different versions of hello.txt are there?

(missing answer)

(missing explanation)

How many times has a new file been added to the project?

(missing answer)

How many times has an existing file been modified?

(missing answer)

And how many times has a file been deleted?

(missing answer)

(missing explanation)

check explain

First impression

What was the original contents of hello.txt?

(missing answer)

(missing explanation)

check explain

Graph-ical

Which of these are a correct representation of the history of this repository?

Choose all the correct answers.

(missing answer)

(missing answer)

(missing answer)

(missing answer)

(missing answer)

(missing answer)

(missing explanation)

check explain

Around and around

What would be the meaning of a cycle in the history graph?

Diverging changes were made in parallel(missing answer)

More than two diverging histories were merged in a single merge(missing answer)

Some commit is its own ancestor(missing answer)

Some commit is a descendant of itself(missing answer)

A pair of commits contain inverse changes(missing answer)

This is bad(missing answer)

(missing explanation)

check explain

The history graph is the backbone of the full object graph. What else is in there?

How do we add new commits to the history graph? git commit creates a new commit.

In some alternate universe, git commit might create a new commit based on the current contents of your working directory. So if you edited Hello.java and then did git commit, the snapshot would include your changes.

We’re not in that universe; in our universe, Git uses that third and final piece of the repository: the staging area (a.k.a. the index, which is only a useful name to know because sometimes it shows up in documentation).

The staging area is like a proto-commit, a commit-in-progress. Here’s how we use the staging area and git add to build up a new snapshot, which we then cast in stone using git commit:

Modify hello.txt, git add hello.txt, git commit

Hover or tap on each step to update the diagram, and to see the output of git status at each step:

1. If we haven’t made any changes yet, then the working directory, staging area, and HEAD commit are all identical.
2. Make a change to a file. For example, let’s edit hello.txt.
   Other changes might be creating a new file, or deleting a file.
3. Stage those changes using git add.
4. Create a new commit out of all the staged changes using git commit.

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

nothing to commit, working directory clean

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

    modified:   hello.txt

no changes added to commit (use "git add" and/or "git commit -a")

$ git add hello.txt 
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

Changes to be committed:
  (use "git reset HEAD ..." to unstage)

    modified:   hello.txt

$ git commit
[master 8a8858a] Update the greeting again
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

nothing to commit, working directory clean

Use git status frequently to keep track of whether you have no changes, unstaged changes, or staged changes; and whether you have new commits in your local repository that haven’t been pushed.

Sequences, trees, and graphs

⋮
*   commit 82e049e248c63289b8a935ce71b130a74dc04152
|   Author: Ben Bitdiddle <ben.bitdiddle@example.com>
|   Greeting in Ruby
|     
| * commit 64009369c5ab93492931ad07962ee81bda921ded
|/  Author: Alyssa P. Hacker <alyssa.p.hacker@example.com>
|   Greeting in Scheme
|  
* commit 1255f4e4a5836501c022deb337fda3f8800b02e4
| Author: Max Goldman <maxg@mit.edu>
| Change the greeting
⋮

⋮
*   commit 3e62e60a7b4a0c262cd8eb4308ac3e5a1e94d839
|\  Author: Max Goldman <maxg@mit.edu>
| | Merge
| |   
* | commit 82e049e248c63289b8a935ce71b130a74dc04152
| | Author: Ben Bitdiddle <ben.bitdiddle@example.com>
| | Greeting in Ruby
| |   
| * commit 64009369c5ab93492931ad07962ee81bda921ded
|/  Author: Alyssa P. Hacker <alyssa.p.hacker@example.com>
|   Greeting in Scheme
|  
* commit 1255f4e4a5836501c022deb337fda3f8800b02e4
| Author: Max Goldman <maxg@mit.edu>
| Change the greeting
⋮

We can send new commits to a remote repository using git push:

git push origin master

Hover or tap on each step to update the diagram:

1. When we clone a repository, we obtain a copy of the history graph.
   Git remembers where we cloned from as a remote repository called origin.
2. Using git commit, we add new commits to the local history on the master branch.
3. To send those changes back to the origin remote, use git push origin master.

And we receive new commits using git pull. Note that git pull, in addition to fetching new parts of the object graph, also updates the working copy by checking out the latest version (just like git clone checked out a working copy to start with).

Now, let’s examine what happens when changes occur in parallel:

Create and commit hello.scm and hello.rb in parallel

Hover or tap on each step to update the diagram:

1. Both Alyssa and Ben clone the repository with two commits (41c4b8f and 1255f4e).
2. Alyssa creates hello.scm and commits her change as 6400936.
3. At the same time, Ben creates hello.rb and commits his change as 82e049e.
   At this point, both of their changes only exist in their local repositories. In each repo, master now points to a different commit.
4. Let’s suppose Alyssa is the first to push her change up to Athena.
5. What happens if Ben tries to push now? The push will be rejected: if the server updates master to point to Ben’s commit, Alyssa’s commit will disappear from the project history!
6. Ben must merge his changes with Alyssa’s.
   To perform the merge, he pulls her commit from Athena, which does two things:
   (a) Downloads new commits into Ben’s repository’s object graph
7. (b) Merges Ben’s history with Alyssa’s, creating a new commit (3e62e60) that joins together the disparate histories. This commit is a snapshot like any other: a snapshot of the repository with both of their changes applied.
8. Now Ben can git push, because no history will go missing when he does.
9. And Alyssa can git pull to obtain Ben’s work.

In this example, Git was able to merge Alyssa’s and Ben’s changes automatically, because they each modified different files. If both of them had edited the same parts of the same files, Git would report a merge conflict. Ben would have to manually weave their changes together before committing the merge. All of this is discussed in the Getting Started section on merges, merging, and merge conflicts.

public class Hello {
    public static void greet(String name) {
        System.out.println(greeting() + ", " + name);
    }
    public static String greeting() {
        return "Hello";
    }
}

public static void greet(String name) {
    System.out.println(greeting() +
                       ", " + name + "!");
}

public static String greeting() {
    return "Ciao";
}

public class Hello {
    public static void greet(String name) {
        System.out.println(greeting() + ", " + name);
    }
    public static String greeting() {
        return "Hello";
    }
}

public static String greeting() {
    return "Ciao";
}

public static void greet(String name) {
    greeting();
    System.out.println(", " + name);
}
public static String greeting() {
    System.out.println("Hello");
}

public class Hello {
    public static void greet(String name) {
        System.out.println(greeting() + ", " + name);
    }
    public static String greeting() {
        return "Hello";
    }
}

    public static String greet(String name) {
        return greeting() + ", " + name;
    }

public class Main {
    public static void main(String[] args) {
        // print a greeting to Eve
        Hello.greet("Eve");
    }
}

We’ve defined a commit as a snapshot of our entire project, but if you ask Git, it doesn’t seem to see things that way:

$ git show 1255f4e
commit 1255f4e4a5836501c022deb337fda3f8800b02e4
Author: Max Goldman <maxg@mit.edu>
Date:   Mon Sep 14 14:58:40 2015 -0400

    Change the greeting

diff --git a/hello.txt b/hello.txt
index c1106ab..3462165 100644
--- a/hello.txt
+++ b/hello.txt
@@ -1 +1 @@
-Hello, version control!
+Hello again, version control!

Git is assuming that most of our project does not change in any given commit, so showing only the differences will be more useful. Almost all the time, that’s true.

But we can ask Git to show us what was in the repo at a particular commit:

$ git show 3e62e60:
tree 3e62e60:

hello.rb
hello.scm
hello.txt

Yes, the addition of a : completely changes the meaning of that command.

We can also see what was in a particular file in that commit:

$ git show 3e62e60:hello.scm
(display "Hello, version control!")

This is one of the simplest ways you can use Git to recover from a disaster: ask it to git show you the contents of a now-broken file at some earlier version when the file was OK.

We’ll practice some disaster recovery commands in class.

How does version control relate to the three big ideas of 6.005?

Safe from bugs

find when and where something broke
look for other, similar mistakes
gain confidence that code hasn’t changed accidentally

Easy to understand

why was a change made?
what else was changed at the same time?
who can I ask about this code?

Ready for change

all about managing and organizing changes
accept and integrate changes from other developers
isolate speculative work on branches