Version Control for Du^H^HDevelopers

Learn why decentralized version control is good for you, and how to use it to full effect.

While not directly Python-related, version control should be mandatory knowledge for every single software developer out there. Knowing your tools will make you more productive and will let you concentrate more on the actual code.

Lately, decentralized version control has been all the rage. I aim to show you why, and what great benefits you will get from it, even if you work alone.

While the principles apply to any decentralized version control -- they are closer to each other than people normally expect -- I am most familiar with git, and will be talking about that.

This talk should apply equally to free software projects or for proprietary in house development.

Download as mp4.

Why decentralized version control is good for you

How to use it to full effect

Make you more productive

Alone or in a team

Workflows

Free software or proprietary

Me


Software

Mercurial

aka hg

Git

aka.. err..

Bazaar

aka bzr

Arch

aka TLA aka Baz

Monotone

aka mtn

Darcs

eh, screw it

BitKeeper

aka bk

git is to bk like Plan 9 is to AIX


Git but not really

Git

git is a fast, content-addressable, decentralized and symmetrically ad hoc synchronizable, cryptographically verified Ventiesque filesystem, stored as a Merkle tree-inspired directed acyclic graph of tags, commits, trees and blobs, in that order, with SHA-1 pointers as edges, backed by a POSIX filesystem, with both a simple storage format and a space- and seek-efficient, compressed delta chained pack format

Venti: http://plan9.bell-labs.com/sys/doc/venti.html

Merkle tree: http://en.wikipedia.org/wiki/Merkle_tree

Wha wha what?

Blob

git-storage

Tree

git-storage

Commit

git-storage

Branch ("ref")

git-storage

Remote branch

git-storage

Tag

git-storage

Identifiers

parallel allocation

no sequential numbers

SHA-1

Write Once

Crypto

git-storage

Signed tags


This is not a a git tutorial

... but we can do that during sprints, if you want?


Let's look at just the commits

After clone

git-history

Somebody else pushes

git-history

Fetch

git-history

Fetch (/pull) and push are the only operations using the network. Thus, they are the only ones suffering from delays due to slow network -- every other operation is completed nearly immediately. They are also the only operations needing e.g. SSH authentication.

Merge (fast-forward)

git-history

Commit

git-history

Merge

git-history

Later on

git-history


Rebase

Simple rebase

git-history

After rebase

git-history

Bigger rebase

git-history

Not the same commit

Write once!

Cannot mutate commits, can only rewrite everything after that point in the history (for all routes through the DAG).


Workflows

  • "just commit"
  • qa in branch
  • gatekeeper -lieutenants

pending in branches / other repos

policy per-repo / per-branch / per-person

Branch policy

when to branch

where to branch from

when to merge where

who merges

When to branch

always ;)

Where to branch from

current main branch head

last release

"known good"

Where to branch from

bugfixes: earliest supported where bug is found

Fix bugs in stable

fix-bugs-in-stable

Fix bugs in stable

fix-bugs-in-stable

Fix bugs in stable

fix-bugs-in-stable

Fix bugs in stable

fix-bugs-in-stable

Version branches

devel/stable

v1.x, v1.1, master

When to merge where

"next"

releases, settling period?

between developers

Topic branches

topic-branches

"next" branch


Spike

spike

Can do a development spike or a prototype, using the version control system as a mere backup mechanism with no concern to commit quality, and later combine/split commits to build atomic incremental changes with related unit tests. Can use temporary branches that are not public, and there's no need to publish the "ugly" work.


Other Cool Stuff

Bisect


Thank You

Questions?

Slides will be on eagain.net. See also articles/git-for-computer-scientists

Want git tutorial?

Use gitosis!