CPSC 491. Today: Source code control. Source Code (Version) Control. Exercise: g., no git, subversion, cvs, etc.)

Transcription

1 Today: Source code control CPSC 491 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 3. What might be some problems with this?

2 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, 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.)

3 The plan 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 So, more general than just source code

4 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 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)

5 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 Version 1 At the item level Version 3 Version 5 Version 2 Version 4 merge changes Version 6

6 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) 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

7 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 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

8 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) 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!)

9 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 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

10 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) Centralized Workflow Workflows [Atlassian] essentially the subversion model only one master branch developers clone master make changes pull changes from master then push changes to master

11 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)

12 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

13 Workflows [Atlassian] Git-Flow Workflow (cont) Next Time We ll look at using some actual git commands and meet in the lab!