1. Version Control
Philip Ritchey
slides generously gifted by Jeff Huang

2. Source & Configuration Management (SCM)
What is it?
Version (snapshot) code, docs, config files, etc. at key points in time
Complete copy of every versioned file per snapshot
Implementation: deltas? complete file copy? symlink?
Why do it?
Roll back if introduce bugs
Separate deployed from development version of code
Keep separate branches of development
Documented history of who did what when
Track what changed between revisions of a project

3. 40 Years of Version Control
SCCS & RCS (1970s)
CVS (1986)
Subversion (2001)
Git (2005)
Image © TheSun.au

4. Merge Conflict A A A A A A A A D’oh! push resolve & push pull & merge
GitHub
Shopping list:
pacifiers for Maggie
beer for Homer
salty snacks...mmm, snacks
Shopping list:
pacifiers for Maggie
<<<<<<<< HEAD
beer for Homer
salty snacks...mmm, snacks
========
alcohol-free beer for Homer
>>>>>>>> 770dfb346ace24:shop_list.txt
D’oh!
push
“remote” A A A
resolve & push
push
clone
pull & merge
770dfb346ace24
One remote is designated as origin, but that's a convention. To Git, a remote is any copy of the repo that isn't this one A A A A A
Simpsons characters © 20th Century Fox Television. Parody use for educational purposes only.

5. Pull = Fetch + Merge
Merge two repos = try to apply commits in either one to both
Conflict if different changes to same file “too close” together
git pull = git pull origin master
Successful merge implies commit!
Always commit before merging/pulling
Commit early & often—small commits OK!

6. Commit: a Tree Snapshot Identified by a Commit-ID
40-digit hex hash (SHA-1), unique in the universe…but a pain
use unique (in this repo) prefix, eg 770dfb
HEAD: most recently committed version on current branch
ORIG_HEAD: right after a merge, points to pre-merged version
HEAD~n: n’th previous commit
770dfb~2: 2 commits before 770dfb
last commit on master branch prior to 1-Sep-2012

7. Undo! git reset --hard ORIG_HEAD git reset --hard HEAD
git checkout commit-id -- files…
Comparing:
git diff commit-id -- files…
git diff -- files
git blame files
git log files
git commit (and push) when all done

8. Version Control with Conflicts
pull or clone
commit (resolved)
edit files
git add files & commit
auto merge &
commit
manual edit
git push
Hard conflict?
git pull & manually resolve
Conflict?
time passes...
git pull
Conflict?

9. Branches Development master vs. branches
Creating branch is cheap!
switch among branches: checkout
Separate commit histories per branch
Merge branch back into master
...or with pushing branch changes
Most branches eventually die
Killer use case for agile SaaS: branch per feature

10. Creating New Features Without Disrupting Working Code
To work on a new feature, create new branch just for that feature
many features can be in progress at same time
Use branch only for changes needed for this feature, then merge into master
Back out this feature  undo this merge
In well-factored app, 1 feature shouldn’t touch many parts of app
Worse if long time; branches shouldn't be long-lived in agile development

11. Mechanics Create new branch & switch to it
git branch CoolNewFeature
git checkout CoolNewFeature current branch
Edit, add, make commits, etc. on branch
Push branch to origin repo (optional):
git push origin CoolNewFeature
creates tracking branch on remote repo
Switch back to master, and merge:
git checkout master
git merge CoolNewFeature  warning!!

12. Branches & Deployment Feature branches should be short-lived
otherwise, drift out of sync with master, and hard to reconcile
git rebase can be used to “incrementally” merge
git cherry-pick can be used to merge only specific commits
“Deploy from master” is most common
“Branch per release” is alternate strategy

13. Branch vs. Fork Git supports fork & pull collaboration model
If you have push/admin access on repo:
branch: create branch in this repo
merge: fold branch changes into master (or into another branch)
If you don’t:
fork: clone entire repo on GitHub to one that you can branch, push, etc.
Finalize your work on its own branch
pull request asks owner of original repo to pull specific commits from my forked repo

14. Fixing Bugs: The Five R’s (ESaaS §10.6)

15. No Bug Fix Without a Test!
Report
Reproduce and/or Reclassify
Regression test
Repair
Release the fix (commit and/or deploy)

16. Report Pivotal Tracker GitHub “issues” feature
bug = 0-points story (but not zero effort!!)
automation: GitHub service hooks can be configured to mark Tracker story “delivered” when properly-annotated commit is pushed
GitHub “issues” feature
Full-featured bug tracking, e.g. Bugzilla
Use the simplest tool that works for your team & project scope

17. Reclassify? or Reproduce + Repair?
Reclassify as “not a bug” or “won’t be fixed”
Reproduce with simplest possible test, and add it to regression
minimize preconditions (e.g. before blocks in RSpec, Given or Background steps in Cuke)
Repair == test fails in presence of bug, passes in absence of bug
Release: may mean either “pushed” or “deployed”

18. Agile & Reviews?
Pivotal Labs – Pair programming means continuous reviewing => no special reviews
GitHub – Pull Requests instead of reviews
A developer requests his/her code be integrated into main codebase
All developers see each request & determine how might affect own code
If concern, online discussion on pull request
As occur daily, “mini-reviews” continuously => no special reviews
Pair is continuous reviews
Pull requests everyday

19. Pitfall
Pitfall: Dividing work based on software stack rather than features
E.g., front-end/back-end specialist, customer liaison, …
Agile: better results if each team member delivers all aspects of a story
Cucumber scenarios, RSpec tests, views, controller actions, model logic, …
Everyone on team has “full stack” view of product
Benefit for team if you know all steps, and better for career as well if doing a story all the way through
Pair programming also spreads knowledge – front end and back end info communicated

20. Pitfall
Accidentally stomping on changes after merging or switching branches
In wrong branch, write over merged changes from old version in editor, …
Before you pull or merge, commit all changes
After you pull or merge, reload files into editor
Or quit editor before commit

21. Pitfall
Letting your copy of the repo get too far out of sync with the origin (authoritative) copy
Means merges will be painful
Do git pull before starting, git push as soon as your locally-committed changes are stable enough
If long-lived branch do periodic git rebase
With the rebase command, you can take all the changes that were committed on one branch and replay them on another one

22. Administrivia Create Github repo for your project
Sign Up and experience Heroku
Get account for “public projects” on PivotalTracker.com, add me
Public projects are free
Get account on CodeClimate.com
Provides code analysis
Free for an open source (OSS) repo
Sign in with your GitHub account
Reading response 2 due 4 Jan