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
Add these files to the list of files under revision control
Check what their status is
24 GitLab - “The CERN GitHub” ● Creating a new project can be done via the online interface ○ Also from command line but I do it this way typically
Commit to local repo
Push to remote server
25 GitLab - “The CERN GitHub” ● Returning to the web interface : TADA! ○ If you go to the “Files” tab you can view the files that we just committed
When you last made a push to this file on the *remote* repo
The files and directories in your project The commit message you made for that file
26 GitLab - “The CERN GitHub” ● Creating an effective/useful README is important ● The README.md is just a text file in your repo so you can edit it like any other file ○ I typically use the web interface for this
You can indeed edit files directly in the web interface. Be prepared to then “git pull” these changes to your local repository
27 GitLab - “The CERN GitHub” ● Uses the markdown language to format things to look nice ○ Counterpart to HTML if you are familiar with that
# : Header
- : Bullet List
## : Sub-Header
``` : Formats it to look like copy/paste code
28 GitLab - “The CERN GitHub” ● When you are finished editing in web-interface, you can commit changes directly to the remote repo ○ WARNING : Be prepared to “git pull” these to your local repository
Don’t forget a useful commit message if its something that is non-trivial
Commit/push your changes in one go 29 GitLab - “The CERN GitHub” MAKE IT GOOD ENOUGH THAT A DOG CAN USE YOUR PROJECT
[1] Description : Supplements the short description of the project in GitLab
[2] Author and
30 Conclusions ● Version control is a new way to think (like programming in general) ○ It can be difficult → I did not use it heavily until the end of graduate school ● Version control is a standard tool in this field ○ All ATLAS publications are required to have their code published/documented in GitLab such that anyone can reproduce the results ○ All CMS software is publicly accessible : https://github.com/cms-sw/cmssw
31