CPSC 491 Today: Source code control
Source Code (Version) Control Exercise:
1. Pretend like you don’t have a version control system (e. g., no git, subversion, cvs, etc.)
2. How would you manage your source code as a team? ○ imagine what this might be like, e.g.:
○ editing different files
○ editing different parts of the same file
○ maintaining different versions of software
Examples of problems:
● could delete a file (or worse, many files)
● make changes but want to go back to an older version ● could overwrite other people’s changes
○ e.g., if 2 people work on same file, last one to save wins
● have to deal with a proliferation of files
○ different versions of software (v1.0, v1.2, v1.4.6, v2.0, …)
○ feature freeze and bug fix (merge back changes)
● In general, requires a lot of communication/coordination ○ which will take up a lot of time ...
Version Control Version control software tries to alleviate this mess …
● goes by many names
● … version, revision, course (code) control ● … configuration management
A “best” (and now standard) practice in software eng. ● automates many otherwise tedious tasks
● manages versions efficiently (diffs)
● allows concurrent editing (some restrictions) ● many tools (git, svn, cvs, team foundation, etc.)
The plan ... 1. Talk about basic concepts in version control
2. Talk about different “workflows” (“flows”) ○ how to organize versions of software
○ how to organize your development/deployment workflow
3. Go over basics of using git
What can be versioned? Usually any kind of file …
● source code
● build scripts (make, ant, …) ● configuration files
● images ● libraries
● documentation ● and so on
Configuration Item: An atomic object in the SCM system ● usually at the level of a file
Configuration: Collection of specific configuration items ● all the objects (files) needed for the software product
Basic Concepts Version: A “snapshot” of a file or configuration at some time
● a version is “frozen” … can’t be changed ● new versions can be created and saved
Version id: unique identifier for the version of the item ● used to obtain or compare previous versions
Basic Concepts Branch: named copy of the configuration
● like a tree (but with special merge edges) ● paths through the tree are the branches
● main branch called the “head” or “master” branch
At the configuration level Basic Concepts At the item level Version 1 Version 4 Version 2 Version 3 Version 5 Version 6 merge changes
Repository: where versions are stored
● a central location (server) where files stored ● e.g., ada houses a number of svn repos
● typically one repository per product (but not required)
Basic Concepts Workspace: local system where modifications happen Check out: initial download of a repository to a workspace
● in git this is called a “clone”
Commit: save local changes to the repository
● creates a new version id for item(s) being committed ● stores a copy of the item under the new id
● most SCM systems are “smart” about storage: ○ e.g., store first version then just “diffs”
Basic Concepts Update: get most recent versions of item(s)
● e.g., to get changes made by others ● in git this is called a “pull”
Conflict: This can be bad! (sometimes)
● item changed and committed “at the same time”
Basic Concepts “At the same time” means ...
● A & B update from same version
● A checks in first (becomes “upstream” change for B) ● B now has an out-of-date version
● B checks in
Most systems won’t let you check in if there is a conflict!
How could this have been avoided? ● Always update before checking in!
● Many systems will handle the conflicts automatically ○ as long as different parts of the code were changed
Merge: incorporate changes into a revised item 1. Alice and Bob update to v10
2. Alice modifies v10
3. Alice updates & commits to v11 4. Bob modifies v10
5. Bob updates …
6. System tries to merge changes (if can’t, a conflict exists) 7. Bob commits to v12
Fixing conflicts is done manually:
● e.g., using a text editor (on text files)
● or, by accepting yours or theirs (binary files)
Basic Concepts
Optimistic vs. Pessimistic Concurrency
Most systems use “optimistic” concurrency by default ● allow parallel modifications (of files)
● handle conflicts as needed This works in practice since …
● conflicts are rare
● people don’t usually work on the same thing ● if they do, they work together (communicate!)
Basic Concepts Using “pessimistic” concurrency …
● ensures sequential modifications using file locks
● default in rcs for modifying files (cvs, svn, git precursor) ● how it generally works
○ check out file with a write lock (if not existing write locks)
○ only person holding write lock can modify file
○ after changes, check in and release write lock
○ anyone can get a read lock
Basic Concepts Tag: a named point in history (configuration snapshot)
● typically used to mark a release point ● e.g., “rc1.0” or “v2.0”
● once tagged, doesn’t change (different than a branch) ○ the tag only denotes the configuration at that point in time
Both are open-source and free version control systems Subversion: Central repository, distributed clients
● Predates git, but after cvs (which was after rcs) ● local changes aren’t versioned until checked in ● only the central repository has complete history Git: Fully distributed
● cloning a repository copies entire history
● allows for local versioning & faster ops (not over network) ● can control access by controlling “pull requests”
● branching is a core concept (e.g., local repos are branches)
Workflows [Atlassian] Centralized Workflow
● essentially the subversion model ● only one “master” branch
● developers clone master ● make changes
● pull changes from master ● then push changes to master
Workflows [Atlassian] Feature Branch Workflow
(aka GitHub Flow)
still use a centralized master branch
○ holds a “stable” / deployable version of the product
all feature development done in a dedicated branch ○ descriptively named according to the feature
○ stored in the central repository
○ so multiple people can work on a feature branch
once a feature branch is ready to become part of master ○ a “pull request” is issued (ask to be merged w/ master)
○ team can review & discuss changes
○ once accepted, the feature branch is “pulled” into master
Workflows [Atlassian] Git-Flow Workflow
“stricter” (& more complicated) version of GitHub Flow ○ specific roles for different branches
○ how and when they interact
historical branches
○ a “master” and a “develop” branch
○ master stores official history
○ develop is an integration branch for features
Git-Flow Workflow (cont) Feature branches
○ each feature in a separate branch
○ but off of develop (parent branch) instead of master
○ when completed, feature merged back into develop
Release branches
○ once ready for a release …
○ fork (copy) a release branch off of develop
○ can then continue adding new features to develop
○ once ready to deploy, merge release with master (and tag)
○ release also merged back with develop
Workflows [Atlassian] Git-Flow Workflow (cont)
Maintenance (“hotfix”) branches
○ used to quickly patch production releases (e.g., bug fixes)
○ these are the only branches off of master
○ as soon as the fix is complete, merge into master & develop
Workflows [Atlassian] Git-Flow Workflow (cont)
Next Time … We’ll look at using some actual git commands
