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
Tree
Commit
Branch ("ref")
Remote branch
Tag
Identifiers
parallel allocation
no sequential numbers
SHA-1
Write Once
Crypto
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
Somebody else pushes
Fetch
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)
Commit
Merge
Later on
Rebase
Simple rebase
After rebase
Bigger rebase
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
Version branches
devel/stable
v1.x, v1.1, master
When to merge where
"next"
releases, settling period?
between developers
Topic branches
"next" branch
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!