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.
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
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
Where to branch from
current main branch head
last release
"known good"
Where to branch from
bugfixes: earliest supported where bug is found
Version branches
devel/stable
v1.x, v1.1, master
When to merge where
"next"
releases, settling period?
between developers
"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
