Version ControlAnd how it will change your workflow

Key Topics

• What is version control?• Why is it important?• Should I be using it?• What Version Control app should I

use?

Version control started as scratching an itch…

• It’s why we use “Save As”. You want the new file without obliterating the old one. It’s a common problem, and solutions are usually like this:– Chances are you've already rolled your own without

knowing it...– Make a single backup copy (Document.old.txt).– If we’re clever, we add a version number or date:

Document_V1.txt, DocumentMarch2007.txt– We may even use a shared folder so other people

can see and edit files without sending them over email. Hopefully they re-label the file after they save it.

Version Control to the rescue

File Management

• Backup and Restore• The Ultimate Undo

Team Management

• Blame-Storming Credit!

• Sandboxing• Synchronization

TerminologyMake with the lingo jack…

• Repository (repo) – Database storing the files• Working Copy – Your local directory of files• Trunk / Master * – The primary location for code in the

repo.

Basics• Add – Begin tracking with VC• Revision – What version a file is on• Head – The latest version in the repo• Checkout – Download a file from the repo• Check in - Upload to the repo

– The file gets a new version number, people can check it out

• Change-log / History – List of changes to the file since it was created in VC

• Update / Sync – Synchronize your files with Head • Revert – Throw away your changes, and reload from

HEAD

*Some systems call this main

The Two Models

CentralizedDistributed

Can anyone tell me the potential problem with using a centralized approachto version control?

Bonus Question

Version Control What are my options?

VCS Name Type Rating

Git (the topic today) Distributed

SVN Centralized

Bazaar Distributed

Mercurial Distributed

Team Foundation Server

Centralized

CVS (Legacy) Centralized

Source: http://en.wikipedia.org/wiki/Comparison_of_revisoin_control_software

Cloning the Repository

Repo

mkdir ~/repository && cd repositorygit clone git@github.com:chuckbutler/dotfiles

Basic Checkins

TRUNK

MilkMilk

Bread

MilkBreadEggs

Rev 1 Rev2 Rev3

echo “Milk” >> list.txtgit add list.txtgit commit –m “Added milk to the list”git push origin master

Checkout and Edit

TRUNK

MilkEggsJuice

Check out

MilkEggsSoupRevert Check in

MilkEggsSoup

Basic Diffs

TRUNK

The repository has a history of changes as a file evolves. Diffs are the changes you made while editing: imagine “peeling” them off and applying

them to a file

MilkMilkEggs

MilkEggsJuice

MilkEggsSoup

+Eggs+Juic

e

- Juice

+ Soup

R1 R2 R3 R4

To go from R1 to R2, we add eggs. Imagine peeling off that red sticker and placing it on R1 to get to R2.

And from R2 to R3 we add Juice, from R3 to R4 we delete Juice and add Soup

Most VCS store diffs rather than full copies of the file. This saves disk space: 4 revs of a file doesn’t mean we have 4 copies; we have 1 copy with 4 small diffs.

Diffs help us notice changes. (“How did you fix that bug?”) and even apply them from one branch to another. -- more on that in a second.

git rev-list --all1bc4b508a68c4dc85873beb0836823a0799d695a286d7c1b00a4bf408a046ccfda1e6064d6fc59604a5e80a2e83671de7985852a94a6c43549c4c4ab...Git diff 1a3a050aaf29b9411552c5a66c85698414b0611d

Note: (git uses computed hash’s for revisions)

Bonus Question: in the previous diagram, whats the diff from R1 to R4

+ Eggs+ Soup

Notice how “Juice” wasn’t even involved – The direct jump from R1 to R4 doesn’t need that change, since Juice was overridden by Soup

Branching

TRUNK

New Feature

Milk EggsSoup

Milk EggsSoup

MilkEggsSoupRice

MilkEggsSoupBread

R4

R5 R6

R7

Other devs continue working, committing to trunk while you work out of your branch

We branch for our new, experimental ideas.

Now that we have a branch, and we are working IN that branch, we can change our code and work out the kinks. Testing in isolation, knowing our changes wont hurt anyone, and our branch history is under version control

It’s a tough concept for newbie's, so pretend you copied your code into a different directory.

git branch nomsgit checkout noms

Milk Egg

sSou

pMilkEggsSoupRice

MergingThis step is the most daunting of all and hangs up most first-time users

New Feature

Milk Egg

sSou

p

MilkEggsSoupBrea

dR4

R5

R6

R7

MilkEggsSoupBrea

dRice

TRUNK

R8

+Rice

Re-Integration of a branch usually winds up in conflicts – this is why it is seen as difficult. You will be making good use of the diff command

git branch experimentalgit branch

experimental * master

git checkout experimental

(edit file)git commit -agit checkout master

(edit same file in master)git commit –agit merge experimental

We now have a conflict. PANIC! What do I do? Relax, grab a beer and start resolving conflicts with git-diff

ValidCheckin

A charted example of conflicts

TRUNK

Milk Egg

sSou

p

- Eggs+Cheese

MilkCheese

Juice

- Eggs+Hot Dog

MilkHot Dog

Juice

Milk Cheese

JuiceR3

R3* Bob

R4

Conflicting Checkin(Cannot remove eggs)

R3* Judy

Tagging

• Version Control Systems support a method of easy identification on –stable branches that we branch out of our source-tree called “tags”

• They are snapshots, of feature-complete code. Typically releases.

• To learn more about this however, you’ll have to visit the git manpage or mr google

Milo proofs all my code