CPSC 491 Lecture 19 & 20: Source Code Version Control VCS = Version Control Software SCM = Source Code Management Exercise: Source Code (Version) Control 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 3. What might be some problems with this?
Version Control 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, source (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 (command-line) git What can be versioned? Usually any kind of file source code build scripts (make, ant, ) configuration files images libraries documentation and so on So, more general than just source code
Basic Concepts 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 systems differ on how versions assigned (and to what)
Basic Concepts Branch: named stream of changes to the configuration branches form a tree (but with special merge edges) paths through the tree are the branches main branch sometimes called the master branch At the configuration level Basic Concepts Version 1 At the item level Version 3 Version 5 Version 2 Version 4 merge changes Version 6
Repository: where versions are stored Basic Concepts a central location (server) where files stored e.g., ada (used to) house 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 called a push in git, check in in svn
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 At the same time means... A & B update from same version Basic Concepts 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 Basic Concepts 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) Optimistic vs. Pessimistic Concurrency Basic Concepts 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
Subversion & Git 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 Git-Flow Workflow Workflows [Atlassian] 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 commits tagged in master w/ version number (v0.1, v1.2)
Git-Flow Workflow (cont) Workflows [Atlassian] 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 master tagged with updated version number
Workflows [Atlassian] Git-Flow Workflow (cont) Using Version Control Exercise: Within your team Determine the workflow you are currently using Determine what workflow you think will work best for your team and why consider: Centralized workflow Github-flow Git-flow Variants And Trade-offs of each for your project
Pre-Quiz Results... YES SORT OF NO Basic Terms 58% (21) 42% (15) 0 (yeah!) Basic Commands 50% (18) 17% (6) 33% (12) Branching 17% (6) 22% (8) 61% (22) Cloning a repository On your local machine, use the git clone command copies the repository (as a directory) onto your machine can locally version changes Using GitHub: git clone https://github.com/username/repository clones to a folder named REPOSITORY
Checking on the status of your workspace On your local machine, use the git status command status of files in repository (modified, etc) files that are not being tracked How to run: git status Adding new files to your workspace After adding file(s), use the git add command stages the file to be added (adds to the index) not yet committed to the workspace How to run: git add FILE For example: git add shawn.txt git add *.py git add dir/file1.txt
Committing Your Changes (* nice feature of git) Use git commit to commit changes to your workspace either after adding or modifying a file file becomes versioned in your workspace How to run: git commit -m MSG FILE For example: git commit -m my new file shawn.txt git commit -m useful msg *.py git commit -m useful msg dir/file1.txt Push Your Changes (to the mothership) Use git push to commit changes to original repository good practice: update first (pull) changes to workspace (master) merged with origin/master How to run: git push
Update your workspace Use git pull to merge changes to original repository changes to origin/master merged with workspace (master) note this is different than a pull request How to run: git pull Recovering files from your workspace Use git checkout to recover files in workspace e.g., if you accidentally delete a file or modify a file How to run: git checkout FILE
Removing files from your workspace Use git rm to remove files from workspace e.g., to get rid of unneeded files when you push to origin/master, removes file there as well How to run: git rm FILE Creating a branch You create a branch using git branch BNAME will want to branch from an up-to-date branch e.g., after pulling origin/master You switch to the branch using git checkout BNAME this sets your current workspace to the branch can switch back and forth between branches How to run: git branch BNAME git checkout BNAME Alternatively: git checkout -b BNAME
Exercise: Create a branch 1. In your project repo, create a new branch 2. create, add, and commit a file to the branch 3. switch to the master branch 4. what changed in your working directory (e.g., run ls)? Merging branches When you are in a branch, you can merge in another branch e.g., to update your branch, merge master into it or, switch to master, merge in your branch adds new files, merges changes to existing files Use the git merge BNAME to merge in changes How to run (e.g., from within your new branch): git merge master -m message git merge origin/master -m message
Exercise: merge a branch 1. switch to master (git checkout master) 2. create, add, and commit a file 3. switch to your branch 4. merge in master (git merge master -m... ) 5. what changed in your branch? 6. switch back to master and push your changes... Pushing your new branch So far, you only have your branch in your workspace Now we want to push it to the mothership e.g., so that others can work on it and so it is versioned in the central repository To push it (from within the branch), run: git push --set-upstream origin BNAME - or - git push -u origin BNAME
Exercise: push your branch 1. switch to your branch 2. push your branch 3. see if you can find your branch on GitHub Note: See remote branches: git branch -r Checkout remote branch: git checkout -b BNAME origin/bname To remove a branch Once you are done with a branch you can delete it either locally or from the repository To remove a branch locally run (from master): git branch -d BNAME To remove a branch from repository run (from master): git push origin --delete BNAME
Creating Tags Git supports 2 kinds of tags: lightweight vs annotated an annotated tag has additional information including a message and info on who created the tag To see the existing tags: git tag To create an annotated tag: git tag -a TAGNAME -m tag message To see information about a tag: git show TAGNAME Exercise: tag your branch 1. switch to your branch 2. create a tag with tag name v0.1 (or whatever you want) 3. verify that the tag was created and show the tag info
Pushing Tags to the Shared Server By default, git push doesn t push tag information instead, have to tell git to push the tag To push a tag: git push origin TAGNAME To branch from a tag: git checkout -b BRANCHNAME TAGNAME This only creates a branch, tagged configurations don t change Exercise: push your tag 1. push your tag to origin 2. go onto GitHub 3. select branch & look at releases (should see your branch)
Merge Conflicts Usually git can auto-merge just fine But sometimes there is a problem when it can t merge a conflict, it pauses the merge process and then you have to fix the conflict yourself You can run a mergetool to help fix the merge: git mergetool Once the merge is resolved, start the process again git status will tell you what to do Merge Conflicts Text-based conflicts are expressed as a diff File 1: 1 The quick brown fox jumps over the lazy dog File 2: 1 The lazy dog jumps over the quick brown fox 2 3 Hello World! What is different? (running diff file1 file2) 1c1 < The quick brown fox jumps over the lazy dog --- > The lazy dog jumps over the quick brown fox 2a3 > Hello World!
Merge Conflicts What is different? (running diff file1 file2) Diff output: 1c1 < The quick brown fox jumps over the lazy dog --- > The lazy dog jumps over the quick brown fox 2a3 > Hello World! xcy = line(s) x in file 1 changed to line(s) y in file 2 xay = line(s) y in file 2 added after line x in file 1 xdy = line(s) x in file 1 deleted in file 2 (at line y) Exercise: resolve a conflict 1. switch to your branch 2. modify your file 3. commit the file 4. switch to master 5. modify the file to create a conflict 6. commit the file 7. switch to your branch and merge in master 8. fix the merge and commit 9. what happens to master?
Pull Requests A feature of GitHub... request for a branch to be pulled into master UI for carrying out this process Try it out: 1. make sure your branch is pushed 2. log on to GitHub, select your branch 3. click on the pull request button 4. walk through the steps of performing a pull request