220 likes | 232 Views
This guide covers local, centralized, and distributed version control systems, principles, and concepts using Git. Learn the advantages, acronyms, systems available, and traditional vs. modern approaches.
E N D
4 Version control(part 1) (Hodson: 1, Chacon: 1-2)
Main concepts to be covered • Local version control • Centralized version control • Distributed version control • Systems for version control • Version control principles and concepts • Version control with GIT • Distributed workflow Objektorienterade applikationer, DAT055, DAI2, 18/19, lp 3
Why version control? • Manual file handling does not scale well for large projects. • None or weak support for cooperation or distributed work. • A simple linear development thread is the only realistic workflow. Objektorienterade applikationer, DAT055, DAI2, 18/19, lp 3
Local version control • Files maintained manually in directories. • Error prone. • In the rcs system, patch sets are used to keep track of the versions of a file. Objektorienterade applikationer, DAT055, DAI2, 18/19, lp 3
Centralized version control • One single repository runs on a server. • All developers are depending on the availability of the server. • Project stops if the server crashes. Computer A Central VCS server file Version database Version 3 Version 2 Computer B Version 1 file Objektorienterade applikationer, DAT055, DAI2, 18/19, lp 3
Distributed version control • Developers work independently on own complete copies of the project files. • Lower risk for data loss due to crashes. • Efficient since most changes are performed on local copies. Objektorienterade applikationer, DAT055, DAI2, 18/19, lp 3
Distributed version control Server computer • Version database Version 3 Version 3 Version 3 Computer A Computer B file file Version 2 Version 2 Version 2 • Version database • Version database Version 1 Version 1 Version 1 Objektorienterade applikationer, DAT055, DAI2, 18/19, lp 3
Acronyms • VC = Version Control • VCS = Version Control System • CVCS = Centralized Version Control System • DVCS = Distributed Version Control System Objektorienterade applikationer, DAT055, DAI2, 18/19, lp 3
Systems for version control • CVS • A centralized VCS. The “old standard”. • Subversion (SVN), Perforce, Bazaar, … • git • A distributed VCS. • Inventor: Linus Torvalds • First intended for development of Linux. • Resource efficient. • Widespread! Objektorienterade applikationer, DAT055, DAI2, 18/19, lp 3
Traditional version control Revision history Version 1 Version 2 Version 3 Version 4 Version 5 file A Δ1 Δ2 file B Δ1 Δ2 file C Δ1 Δ2 Δ3 Changes Original files Objektorienterade applikationer, DAT055, DAI2, 18/19, lp 3
Git snapshots of a file system Revision history Version 1 Version 2 Version 3 Version 4 Version 5 A1 A2 file A A1 A2 file B B B B1 B2 file C C1 C2 C3 C2 Unchangedfilesare represented as links toearlier versions Snapshot of a directory Onlychangedfilesarestoredagain Objektorienterade applikationer, DAT055, DAI2, 18/19, lp 3
Version control concepts • Repository (“repo”) • A database of a project’s revision history. • Commit (Checkin) • Uploading a changed file to the repository. • Checkout • Downloading a version of a file from the repo. • A note on syntax: A B earlier version later version Objektorienterade applikationer, DAT055, DAI2, 18/19, lp 3
Version control concepts • Branch • A parallel line of development in a project. • Merge • Creating a common line from two branches. Conflictsmayoccur! Objektorienterade applikationer, DAT055, DAI2, 18/19, lp 3
Git concepts • Working directory • A folder containing files • Snapshot (revision) • Staging area • Intermediate storage of files in a snapshot. • Repository • A database of snapshots of a project history. Working directory Objektorienterade applikationer, DAT055, DAI2, 18/19, lp 3
Checkout, Stage and Commit Working directory Checkout Staged Snapshot Stage Commit Repository History Objektorienterade applikationer, DAT055, DAI2, 18/19, lp 3
Stage and Unstage Working directory Unstage Staged Snapshot Stage Objektorienterade applikationer, DAT055, DAI2, 18/19, lp 3
Workflow with local development branches Repo Staged Snapshot Stage Commit Working directory History Objektorienterade applikationer, DAT055, DAI2, 18/19, lp 3
Branching feature A mainbranch V 1 V 2 V 3 V 4 V 5 V x V y topicbranch feature B Objektorienterade applikationer, DAT055, DAI2, 18/19, lp 3
Merging two development branches Version 6 containsboth feature A and B V 1 V 2 V 3 V 4 V 5 V 6 V x V y Objektorienterade applikationer, DAT055, DAI2, 18/19, lp 3
Merge conflicts Snapshots V 5 and V y containconflicting data V 1 V 2 V 3 V 4 V 5 *#@! V x V y Conflictshaveto be resolved by the developer(s) Objektorienterade applikationer, DAT055, DAI2, 18/19, lp 3
Integrator-Manager Workflow • The integrator pushes to a public repo. • Each developer clones the public repo into a local copy and makes changes. • Changes are pushed to an own public repo with write access. • The integrator pulls in and merges contributions from the public repos. • The integrator pushes merged changes to the “official” public repo. Objektorienterade applikationer, DAT055, DAI2, 18/19, lp 3
Integrator-Manager Workflow Main repo Public repo 1 Public repo 3 Public repo 2 2. Clone 1. Push 5. Push 3. Push 4. Pull in contributions Integration manager Developer 1: Feature A Developer 3: Feature B Developer 2: Main A Main Local repo 1 Local repo 3 Local repo 2 Localrepo B Objektorienterade applikationer, DAT055, DAI2, 18/19, lp 3