I m an egotistical bastard, and I name all my projects after myself. First Linux, now git. Linus Torvalds, creator of Linux and Git

Git Benedict R. Gaster University of West of England November 23, 2015

But I thought this was a course on Operating Systems It is but... We are going to be doing lots of software development Any and all software development needs some sort of version control

But I thought this was a course on Operating Systems It is but... We are going to be doing lots of software development Any and all software development needs some sort of version control Any and all software needs to be built from its source code

Course Schedule Week-Date Thursday lecture Lab sessions 26-18/1/16 Introdution to Git and Make Worksheet 1: Getting to grips with Git Signoff for worksheet 1 27-25/1/16 Introduction to Operating Systems Text: chapter(s): 1 and 12 Worksheet 2: Bare-bones OS 28-01/2/16 Computer Hardware Review Worksheet 2: Bare-bones OS Text: chapter(s): 1 Signoff for worksheet 2 29-08/2/16 Processes and threads Text: chapter(s): 2 (2.1 and 2.2) Worksheet 3: Building Pintos OS 30-15/2/16 Interprocess communication Worksheet 3: Extending Pintos OS to display exit message for user processes Text: chapters(s): 2 (2.3) Signoff for worksheet 3 31-22/2/16 Scheduling Text: chapters(s): 2 (2.4) Assignment: Implementing system calls in Pintos OS 32-29/2/16 Memory management Text: chapter(s) 3 Assignment: Implementing system calls in Pintos OS 33-07/3/16 Memory management continued Text: chapter(s) 3 Assignment: Implementing system calls in Pintos OS 34-14/3/16 File Systems Text: chapter(s) 4 Assignment: Implementing system calls in Pintos OS 35-21/3/16 Vacation (no lecture) Vacation (no labs) 36-28/3/16 Vacation (no lecture) Vacation (no labs) 37-4/4/16 INPUT and OUTPUT Text: chapter(s) 5 Assignment: Implementing system calls in Pintos OS 38-11/4/16 Virtualization Assignment: Implementing system calls in Pintos OS Text: chapter(s) 7 Assignment hand in is due 14th April @ 2pm 39-18/4/16 Exam review and revision No lab

Course Website All course material, lectures, schedule, worksheets, and assignments will be on the course website: http://www.cems.uwe.ac.uk/ br-gaster/courses/2015-2016/cnos/

Everyday tasks of software development Create things, e.g. source code with new capabilities Save things, e.g. source files Edit things, e.g. e.g. fix bugs or add new features Save the same thing again, source files

Everyday tasks of software development Save the thing again and again This is the over all goal It is where version control can help Providing a history of changes When you made the change Why you made the change What the contents of the change were Can be reviewed, or even undone, anytime in the future

History Tracking

History Tracking For a single individual this might not seem to hard

History Tracking For a single individual this might not seem to hard For a single file this again might not seem to hard

But real projects Large and complicated

But real projects Large and complicated Many developers, testers, and other people working on a given project

But real projects Large and complicated Many developers, testers, and other people working on a given project Many design documents, source files, tests, and other assets are used to build the final project

Version control A Version control is a system that records changes, overtime, to a file or set of files Allows recalling of specific versions later Allows coloration between multiple teams of people (e.g. developers) On this course we will care mostly about versioning of source files, however, in practice version control can be used to version almost any kind of file. All source code related to the course will be versioned controlled Code samples and libraries used on the course All code YOU submit as part of any course work

Version control key features Backup and Restore. Files are saved as they are edited, and you can jump to any moment in time. Need that file as it was on Feb 1st, 2015? No problem. Synchronization. Lets people share files and stay up-to-date with the latest version. Short-term undo. Monkeying with a file and messed it up? (That s just like you, isn t it?). Throw away your changes and go back to the last known good version in the database. Long-term undo. Sometimes we mess up bad. Suppose you made a change a year ago, and it had a bug. Jump back to the old version, and see what change was made that day. Track Changes. As files are updated, you can leave messages explaining why the change happened (stored in the VCS, not the file). This makes it easy to see how a file is evolving over time, and why.

Version control key features Track Ownership. A VCS tags every change with the name of the person who made it. Helpful for giving credit. Sandboxing, or insurance against yourself. Making a big change? You can make temporary changes in an isolated area, test and work out the kinks before checking in your changes. Branching and merging. A larger sandbox. You can branch a copy of your code into a separate area and modify it in isolation (tracking changes separately). Later, you can merge your work back into the common area.

We are going to use Git

Git All code samples and libraries used on the course will be delivered using Git All course work code will be delivered using Git

Git All code samples and libraries used on the course will be delivered using Git All course work code will be delivered using Git How many of you have used Git before?

Git All code samples and libraries used on the course will be delivered using Git All course work code will be delivered using Git How many of you have used Git before? Don t worry if you have not done it before or are rusty We will cover Git basics in class and in the first few labs

Git Setup Git is probably already installed on OS X and Linux, if not: Download for OS X Download for Linux Download for Windows Remember we will be using Linux exclusively for all practicals

Create a new repository create a new directory, open it and perform a to create a new git repository

Checkout a repository create a working copy of a local repository by running the command when using a remote server, your command will be

Your Git workflow your local repository consists of three trees maintained by Git. The first one is your Working Directory which holds the actual files. the second one is the Index which acts as a staging area and finally the HEAD which points to the last commit you ve made

Add and commit You can propose changes (add it to the Index) using This is the first step in the basic git workflow. To actually commit these changes use Now the file is committed to the HEAD, but not in your remote repository yet.

Pushing changes Your changes are now in the HEAD of your local working copy. To send those changes to your remote repository, execute Change master to whatever branch you want to push your changes to If you have not cloned an existing repository and want to connect your repository to a remote server, you need to add it with Now you are able to push your changes to the selected remote server

Branching Branches are used to develop features isolated from each other. The master branch is the default branch when you create a repository. Use other branches for development and merge them back to the master branch upon completion create a new branch named feature x and switch to it using

Branching create a new branch named feature x and switch to it using switch back to master and delete the branch again a branch is not available to others unless you push the branch to your remote repository

Update and merge to update your local repository to the newest commit, execute in your working directory to fetch and merge remote changes. to merge another branch into your active branch (e.g. master), use in both cases git tries to auto-merge changes. Unfortunately, this is not always possible and results in conflicts. You are responsible to merge those conflicts manually by editing the files shown by Git

UWE s Gitlab

References I Chacon, S. and Straub, B. (2014). Git Pro. Apress, 2 edition. Kernighan, B. W. (1988). The C Programming Language. Prentice Hall Professional Technical Reference, 2nd edition.