How to avoid the “IT WAS
WORKING…”
● Most software projects rely on version control (VC) to maintain changes
○ Ever see software with names like “programxyz_v.
1.2.3” or “programxyz_r123”
● VC also allows multiple developers to work on same parts at same time
● Some popular VC programs are:
○ CVS (Concurrent Version System)
○ SVN (Subversion)
○ GIT (Distributed, we’ll be focusing on this)
○ Hg (Mercurial, like Git)

Poor Man’s Version Control
● Simplest way: commenting/uncommenting code (OK, but a pretty poor solution, hard to remember which comments worked, didn’t)
● Slightly better way: saving multiple versions of file (ie. main_v0.co, main_v1.c, etc.)
○ Without changelog, hard to remember what changed
○ Difficult if project requires multiple files (does main_v1.c correspond to aux_v1.c?)
○ Hard to manage concurrent edits

Centralized VC Systems
● A central server holds version control database
● Users checkout current version locally
○ Make edits locally
○ Different users might make different edits
● After making sufficient changes, users commit changes back to main database
○ If multiple users were working on same file, merge changes (ie. diff to see differences in file, and reconcile changes). This can be tedious on large projects!
● All users update to see latest version

SVN Example:
1. Download Tortoise SVN (Windows)
2. Checkout repository
3. Edit some of the files a. If creating a new file, needs to be “Added” to repository
4. Commit changes
5. Repeat (Updating if others are concurrently working)

Distributed Version Control
● Everybody has copy of VC database (hence distributed)
● Most changes are done locally
● More robust to failure
○ If Master dies, everyone has a backup
○ Don’t even need a master sometimes
● Since everyone has repository, can do different work styles (ie. hierarchical)

Git (git-scm.com, adapted from http:
//git-scm.com/book/en/v2)
● Git is distributed VC system
○ Github is a web host that holds master versions of
Git repositories
● Git is based on snapshots

Git (git-scm.com, adapted from http:
//git-scm.com/book/en/v2)
● Git uses SHA-1 for integrity
● Git has three stages:
○ 1) Working directory (where you modify files)
○ 2) Staging area (a file that keeps track of what will be in next commit)
○ 3) .git (Repository)
Terms:
If it is in .git it is committed
If it is changed since being checked out it is modified
If it is modified but not committed, it is staged

Git (git-scm.com, adapted from http:
//git-scm.com/book/en/v2)
● Getting Git: http://git-scm.com/download/win
○ Linux: It’s probably in your distro’s software repos
○ MacOS: http://git-scm.com/download/mac
Initial Config:
$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com
$ git config --global core.editor emacs (vim)
Check:
$ git config --list

Git (git-scm.com, adapted from http:
//git-scm.com/book/en/v2)
● Initial Repo:
○ Locally: Go to project directory, type:
$ git init
■ This creates .git directory which contains the repository
■ Nothing is actually versioned at this point
○ Existing Repo:
$ git clone https:://www.repourl.com/reponame or
$ git clone git:://repourl.com/reponame or
○ $git clone user@server:path/to/repo.git

Git (git-scm.com, adapted from http:
//git-scm.com/book/en/v2)
● Adding files (start versioning a file):
○ $ git add filename.c
○ $ git add *.c
○ $ git add -u (updates all modified files to staging)
○ $ git add -a (updates all modified files, and adds all new, untracked files)
● Commit project:
○ $ git commit -m ‘Initial project version’
■ -m puts a message for the changelog
■ MAKE MEANINGFUL CHANGE MESSAGES SO
YOU KNOW WHERE YOU ARE IN YOUR
PROJECT!!!

Git (git-scm.com, adapted from http:
//git-scm.com/book/en/v2)
● Git Lifecycle:

Git (git-scm.com, adapted from http:
//git-scm.com/book/en/v2)
● When ready to commit a new version:
○ $ git commit -m ‘Log Message Goes Here’
● Some useful Git commands:
○ $ git status
■ Shows status of files
○ $ git diff
■ Shows diff of modified files
○ $ git mv
■ Moves files
○ $ git log
■ Shows the changelog

Git (git-scm.com, adapted from http:
//git-scm.com/book/en/v2)
● Working with remotes (if you cloned from a server):
○ $ git remote
● Get data from remotes:
○ $ git fetch
● Push data to remotes:
○ $ git push
■ Typically: $ git push origin master

Demo Time:
● Using Git with Dropbox http://blog.shvetsov.
com/2013/04/using-git-with-dropbox.html
● For PSoC Projects:
○ Create a new project
○ Open Git Bash, go to project directory
○ Make initial commit
○ After building in PSoC Designer,, make sure to add the lib directory
$ git add project/project/lib
(cloning won’t work if it’s not there, other build files may not be necessary)