Version control systems

Lecture 25. Part 1. Version control systems Programming BSc programme: Business Informatics Autumn 2019 Sergey Efremov, 2019 BIPROG: Lecture 25. Part 1 1 / 21 General requirements for the team project 2 or 3 members in each team GUI application (WPF / WinForms / Universal Win / Web site / Mobile app / Game) Version control system Principles of loose coupling - interfaces, inheritance, delegates Final presentation Sergey Efremov, 2019 BIPROG: Lecture 25. Part 1 2 / 21 Examples of topics for the Team project Examples include (but are not limited to): Information system with a database (any subject area) Mashup application integrating several web services Game (local or network) Testing system Learning assistant Photo viewer / editor Sergey Efremov, 2019 BIPROG: Lecture 25. Part 1 3 / 21 What is VCS? A version control system (or revision control system) allows to record the software development process as a sequence of versions Sergey Efremov, 2019 BIPROG: Lecture 25. Part 1 4 / 21 Why use Version Control Systems? Software development is an iterative process Large programs are built and maintained by a group of developers Often certain features need to be tested separately without affecting the main development branch Sergey Efremov, 2019 BIPROG: Lecture 25. Part 1 5 / 21 A bit of VCS history First generation (70-80s) - SCCS, RCS. Each file is versioned independently (similar to modern cloud file storages) No network support Second generation (90s - first half of 00s) - VCS, VSS, SVN. Multiple files as a group Centralized approach Third generation (from 2005) - Git, Mercurial (Hg) Changeset mechanism Distributed approach Sergey Efremov, 2019 BIPROG: Lecture 25. Part 1 6 / 21 Version Control Systems A modern Version Control System (VCS): Stores the whole history of changes in source files Manages multiple branches inside a single project Supports tagging Provides tools for automatic and manual merging VCS enables a much easier collaborative project development Sergey Efremov, 2019 BIPROG: Lecture 25. Part 1 7 / 21 Concurrent development with centralized VCS Sergey Efremov, 2019 BIPROG: Lecture 25. Part 1 8 / 21 Concurrent development with distributed VCS Each developer has a local repository, which stores the entire history of the project Sergey Efremov, 2019 BIPROG: Lecture 25. Part 1 9 / 21 VCS clients Command line based GUI based Integrated into IDEs. Visual Studio starting from version 2013 has an integrated Git client. Sergey Efremov, 2019 BIPROG: Lecture 25. Part 1 10 / 21 Main Git operations Sergey Efremov, 2019 BIPROG: Lecture 25. Part 1 11 / 21 Creating a Git based team project in Visual Studio I 1 Create a new application (any type) with source control enabled Sergey Efremov, 2019 BIPROG: Lecture 25. Part 1 12 / 21 Creating a Git based team project in Visual Studio II 2 Make the first commit (Team Explorer panel) 3 Create a central repository 4 In Visual Studio specify the address of the central repository and push changes to it Sergey Efremov, 2019 BIPROG: Lecture 25. Part 1 13 / 21 Working on a team project After the remote repository has been created: 1 Pull latest changes made by other developers (or clone if no local repository exists) 2 Develop the project in the working directory 3 Debug the project. Make sure the code compiles and no unexpected errors occur 4 Make a local commit 5 Repeat steps 1-4 until changes are ready to be published to the central repository 6 Push local changes to the remote repository Sergey Efremov, 2019 BIPROG: Lecture 25. Part 1 14 / 21 Choosing a host server for the central repository Options: Private server Public server with private repositories (bitbucket, gitlab and others) Public server with public repositories only (github, google code and others) Features that are often integrated with the central repository: Wiki Issue tracker Project management Sergey Efremov, 2019 BIPROG: Lecture 25. Part 1 15 / 21 2-step commit process in Git In Visual Studio stage and commit is a single process Sergey Efremov, 2019 BIPROG: Lecture 25. Part 1 16 / 21 Conflicts When two or more developers make changes to the same file, one of them might need to resolve conflicts when synchronizing with the central repository A VCS client usually contains a set of tools for merging multiple changes into the file After conflict resolving the final version of the file is generated, a merge commit is normally made Rule of thumb ‘git pull’ a day keeps the conflicts away Sergey Efremov, 2019 BIPROG: Lecture 25. Part 1 17 / 21 Branching Branching means diverging from the main development line Typical branching scenarios: Making changes that might not be used Major or disruptive changes Experimenting with new features (which might not work) Sergey Efremov, 2019 BIPROG: Lecture 25. Part 1 18 / 21 Branching in Git One of the distinctive features of Git is much easier branching and merging compared to previous VCSs Best practice with Git Branch out, merge often and always keep in sync which means When working on a different branch regularly pull changes made by developers to the main branch Sergey Efremov, 2019 BIPROG: Lecture 25. Part 1 19 / 21 Forking workflow Git enabled a much easier collaboration on large open-source projects: In the forking model each contributor to the project forks from the main repository creating a server-side copy (fork) After making changes to the fork the developer can initiate a pull request to the main repository Changes will be reviewed by interested parties and can be accepted or rejected Sergey Efremov, 2019 BIPROG: Lecture 25. Part 1 20 / 21 References Recommended reading: R. Somasundaram “Git: Version Control for Every one” (book) Comparing workflows ( article ) V. Driessen “A successful Git branching model” ( blog post ) Sergey Efremov, 2019 BIPROG: Lecture 25. Part 1 21 / 21