Theory Session 4: Version control

=================================

Version control

So, now we're comfortable with Markdown, which allows us to write documents like we were writing code, we can use the tools first designed to allow coders to collaborate on our documents.

This is transformative - these tools were developed to permit teams of thousands of coders work together, including open source communities.

They allow merging of work of distributed teams, automatically helping to resolve conflicts where different authors attempt to make changes to the same part of a program.

We'll review a few concepts from version control tools, before working practically with github.

Commits

Each set of changes we make forms a commit. A commit has an author, and, critically, a short comment describing the intent of the change.

By reviewing the commit log, we see a summary of changes.

Commits as a network

Each commit has a parent: the change before, and a child the change after.

When two people make changes based on the same parent, it has two children.

When two sets of changes are merged, (resolving any potential conflicts), they create a commit with two parents.

(Computer scientists call this network a directed graph).

Branches

What if you're working on some changes, and you're not ready for them to be part of the main project yet - you're not quite finished. You do your work on a named branch.

Pull Requests

So, if your work is on a branch, how do you get it back into the "trunk"? You file a "pull request", which allows the rest of the team to review your changes, before merging your work.

Note this creates a much more careful trail of approval than the wiki, where anyone can make changes at will.