Programming 6 : Version Control Sam Meehan University of Washington 14 March 2017 Introduction ● Who/why/what version control? - Good Intro Here ○ Renaming files - ewwwwwwww ○ Emailing source code - ewwwwwwwww ○ Deleting my work - oh $h*%! ● New Concepts ○ Only the basics ● GitHub ○ open source with nice tutorial ● GitLab : CERN users only ○ We will set up a project together 2 Why version control? - 1 ● You will rarely NEVER do things once : RE-search ● But what about keeping track of work in the past ○ In case you screw up and want to go back to a save point (like a video game) [1] Start your program 3 Why version control? - 1 ● You will rarely NEVER do things once : RE-search ● But what about keeping track of work in the past ○ In case you screw up and want to go back to a save point (like a video game) [1] Start your program [2] You made some changes you think are big and wanted to save a copy at that point 4 Why version control? - 1 ● You will rarely NEVER do things once : RE-search ● But what about keeping track of work in the past ○ In case you screw up and want to go back to a save point (like a video game) [1] Start your program [2] You made some changes you think are big and wanted to save a copy at that point [3] Karen wanted a version (“acgh, Karen!”) but she told you that there was a bug so you fixed it and gave it back to her (Karen is annoying but helpful) 5 Why version control? - 1 ● You will rarely NEVER do things once : RE-search ● But what about keeping track of work in the past ○ In case you screw up and want to go back to a save point (like a video game) [1] Start your program [2] You made some changes you think are big and wanted to save a copy at that point [3] Karen wanted a version (“acgh, Karen!”) but she told you that there was a bug so you fixed it and gave it back to her (Karen is annoying but helpful) [4] You made another big change and are close to final (but woops, you forgot to label v4, that’s awkward) 6 Why version control? - 1 ● You will rarely NEVER do things once : RE-search ● But what about keeping track of work in the past ○ In case you screw up and want to go back to a save point (like a video game) [1] Start your program [5] This is the version you turn in for the final grade ... but you actually had a bug and fixed it [2] You made some changes you think are big and wanted to save a copy at that point [3] Karen wanted a version (“acgh, Karen!”) but she told you that there was a bug so you fixed it and gave it back to her (Karen is annoying but helpful) [4] You made another big change and are close to final (but woops, you forgot to label v4, that’s awkward) 7 Why version control? - 2 ● Emailing code is not “sustainable” ○ What if the recipient or you lose that email? - luckily GMail archives pretty well ○ “But which email did you get that from?” - communicating/teamwork is difficult ○ The amount of data traffic becomes large! - if you send this to a list (with potentially 100’s of people) ● Better solution : Put code on publicly accessiblehttp://meehan.web.cern.ch/meehan/ATLASSharing/MyProject/ place on the web ○ e.g. DropBox, iCloud, CERN webserver 8 Why version control? - 3 ● In the terminal : “rm” is not “moving it to the trash” ○ Cannot retrieve it once it is removed ○ rm -rf ~/* : will remove everything below your home directory (oh $*#&!!!!!!) ● Most terminal-based working environments do not have automatic backup ○ Exception : group servers (e.g. lxplus backs up your home directory each week) 9 New Concepts : Tracking Changes ● An “auxiliary” program will keep track of only the changes ○ Applies to (1) files and (2) directory structure ○ This does this for all contents in a given repository ● Advantages ○ Saves the amount of space that your (evolving) project takes up ○ Can easily review these changes alone instead of manually comparing files Version 1 Version 1 + newCode 10 New Concepts : Committing ● All changes are local until you are happy enough to commit them ● An imprint is made on the repository and the changes are saved ○ This is like a “Save Point” in a video game ○ You leave a commit message to describe your changes Committing : Imprints your *changes* Repo Repo on the official record with a timestamp and description v02k3846 No changes to repository v02k3846 Version 1 + newCode Version 1 + newCode Repo v02ue027 Editting code “locally” Revision ID Unique identifier to refer to this set of changes “v02ue027” 11 New Concepts : Extras ● As usual : There is much much more to version control ○ You will have to actively explore based on what you need/want to do ● Getting updates : git pull ○ Collaborative projects are great? (ATLAS is 3000 people) ○ Ease of the incorporating work of others into your local code ● Resolving Conflicts ○ If two people edit the same thing in a repository simultaneously ○ “Overlapping edits” are highlighted and ask for modification ● Diffing Revisions ○ Displaying only the changes between two revision ID numbers ● Branching/Merging ○ How to collaborate with many people on a single project so as to not conflict ● Tags : A “Super Commit” ○ Take a snapshot of a stable version of the code that is no longer modifiable 12 Version Control Programs ● Many specific types of version control exist ○ Free : Concurrent Version System (CVS), Subversion (SVN), Vesta, Git - free ○ Not Free : Not going to list them ● We will be focusing on Git : https://git-scm.com/ Remote Server (computer farm you don’t see) GitHub - https://github.com/ BitBucket - https://bitbucket.org/ Mercurial - https://www.mercurial-scm.org/ GitLab - https://gitlab.cern.ch/ ... Local Computer You can share/change/commit code to each of these computers Your computer from any other computer 13 Version Control Programs ● Many specific types of version control exist ○ Free : Concurrent Version System (CVS), Subversion (SVN), Vesta, Git - free ○ Not Free : Not going to list them ● We will be focusing on Git : https://git-scm.com/ Remote Server (computer farm you don’t see) GitHub - https://github.com/ BitBucket - https://bitbucket.org/ Mercurial - https://www.mercurial-scm.org/ GitLab - https://gitlab.cern.ch/ ... Local Computer You can share/change/commit code to each of these computers Your computer from any other computer 14 Version Control Programs ● Many specific types of version control exist ○ Free : Concurrent Version System (CVS), Subversion (SVN), Vesta, Git - free ○ Not Free : Not going to list them ● We will be focusing on Git : https://git-scm.com/ Remote Server (computer farm you don’t see) GitHub - https://github.com/ BitBucket - https://bitbucket.org/ Mercurial - https://www.mercurial-scm.org/ GitLab - https://gitlab.cern.ch/ ... Local Computer You can share/change/commit code to each of these computers Your computer from any other computer 15 Version Control Programs ● Many specific types of version control exist ○ Free : Concurrent Version System (CVS), Subversion (SVN), Vesta, Git - free ○ Not Free : Not going to list them ● We will be focusing on Git : https://git-scm.com/ You will probably be focusing on using the remote computer as a “throughout” until very advanced stages 16 Version Control Programs ● Many specific types of version control exist ○ Free : Concurrent Version System (CVS), Subversion (SVN), Vesta, Git - free ○ Not Free : Not going to list them ● We will be focusing on Git : https://git-scm.com/ You will probably be focusing on using the remote computer as a Retrieve (“pull”) “throughout” until very advanced the changes stages Commit (“push”) the changes 17 Let’s Try it in Real Time ● Go to this link : https://try.github.io ○ I swear I’m not being lazy - this is literally the best resource for learning Git ● What you need to know is subjective ○ Levels 1-17 : The essentials of a repo ■ Creating ■ Committing to ■ Pulling from ○ Levels 18-24 : Advanced ■ Developing effectively via a branch 18 GitLab - “The CERN GitHub” ● All individuals with a CERN computing account are granted a GitLab account ○ Access with your cern username/password ○ Follow this link : https://gitlab.cern.ch ● GitLab functions very similar to GitHub but is CERN-focused/supported Create a new project with a push of a button All of the projects you are collaborating on are shown here 19 GitLab - “The CERN GitHub” ● Give some thought when you create a project about how others may be viewing it later on Title of project : [1] No spaces [2] Letters, numbers, “_”, and “-” Ex1 : ThisTitleIsAGoodIdea Ex2 : this-title-is-a-good-idea Description : Write something so that people don’t have to guess from the name alone Permissions : “Internal” is the best choice 20 GitLab - “The CERN GitHub” ● Give some thought when you create a project about how others may be viewing it later on Create It 21 GitLab - “The CERN GitHub” ● Nothing is yet in the project : just like the “git init” in the tutorial ● Directs you on how to add things to the project ○ Starts with a README.md (markdown) file You may need to try a different The URL is accessible URL depending on permissions in a few ways 22 GitLab - “The CERN GitHub” ● Adding the README.md file to the repository is just like adding the “octocats.txt” ○ It’s just a text file!!!! ● [1] Clone the repo → [2] Add/commit the file → [3] push to the remote server Cloning the remote repo to our local machine Adding/committing the README file (like any other file) to our local repo Pushing this change to the remote repo 23 GitLab - “The CERN GitHub” ● Now we will add our work to the project ○ Example using the 3rd homework assignment question1.cpp and question2.cpp