“i’m an egotistical bastard, and i name all my projects...

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

Upload: vanhanh

Post on 18-Jun-2018

215 views

Category:

Documents


0 download

TRANSCRIPT

“I’m an egotistical bastard, and I name all my projects after myself. FirstLinux, 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

Any and all software needs to be built from its source codeAs such we will use version control through out the course practicals

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 controlAny and all software needs to be built from its source code

As such we will use version control through out the course practicals

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 controlAny and all software needs to be built from its source code

As such we will use version control through out the course practicals

Course Schedule

Week-Date Thursday lecture Lab sessions

26-18/1/16 Introdution to Git and Make Worksheet 1: Getting to grips with GitSignoff for worksheet 1

27-25/1/16 Introduction to Operating SystemsText: chapter(s): 1 and 12 Worksheet 2: Bare-bones OS

28-01/2/16 Computer Hardware ReviewText: chapter(s): 1

Worksheet 2: Bare-bones OSSignoff for worksheet 2

29-08/2/16 Processes and threadsText: chapter(s): 2 (2.1 and 2.2) Worksheet 3: Building Pintos OS

30-15/2/16 Interprocess communicationText: chapters(s): 2 (2.3)

Worksheet 3: Extending Pintos OS to display exit message for user processesSignoff for worksheet 3

31-22/2/16 SchedulingText: chapters(s): 2 (2.4) Assignment: Implementing system calls in Pintos OS

32-29/2/16 Memory managementText: chapter(s) 3 Assignment: Implementing system calls in Pintos OS

33-07/3/16 Memory management continuedText: chapter(s) 3 Assignment: Implementing system calls in Pintos OS

34-14/3/16 File SystemsText: 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 OUTPUTText: chapter(s) 5 Assignment: Implementing system calls in Pintos OS

38-11/4/16 VirtualizationText: chapter(s) 7

Assignment: Implementing system calls in Pintos OSAssignment 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 beon 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 capabilitiesSave things, e.g. source filesEdit things, e.g. e.g. fix bugs or add new featuresSave the same thing again, source files

Everyday tasks of software development

Save the thing again and againThis is the over all goal

It is where version control can helpProviding a history of changesWhen you made the changeWhy you made the changeWhat the contents of the change wereCan be reviewed, or even undone, anytime in the future

History Tracking

History Tracking

For a single individual this might not seem to hard

For a single file this again might not seem to hard

History Tracking

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

But “real projects”

Large and complicated

Many developers, testers, and other people working on a given projectMany design documents, source files, tests, and other assets are usedto build the final project

But “real projects”

Large and complicatedMany developers, testers, and other people working on a given project

Many design documents, source files, tests, and other assets are usedto build the final project

But “real projects”

Large and complicatedMany developers, testers, and other people working on a given projectMany design documents, source files, tests, and other assets are usedto build the final project

Version control

A Version control is a system that records changes, overtime, to a fileor set of filesAllows recalling of specific versions laterAllows 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 anykind of file.All source code related to the course will be versioned controlled

Code samples and libraries used on the courseAll 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 canjump 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 thelatest version.Short-term undo. Monkeying with a file and messed it up? (That’sjust 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 achange 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 messagesexplaining 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 theperson who made it. Helpful for giving credit.Sandboxing, or insurance against yourself. Making a big change? Youcan make temporary changes in an isolated area, test and work outthe kinks before “checking in” your changes.Branching and merging. A larger sandbox. You can branch a copy ofyour code into a separate area and modify it in isolation (trackingchanges separately). Later, you can merge your work back into thecommon area.

We are going to use Git

Git

All code samples and libraries used on the course will be deliveredusing GitAll 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 labsRecommended you look at the excellent onlinebook [Chacon and Straub, 2014]:

https://git-scm.com/book/en/v2

Git

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

Don’t worry if you have not done it before or are rustyWe will cover Git basics in class and in the first few labs

Recommended you look at the excellent onlinebook [Chacon and Straub, 2014]:

https://git-scm.com/book/en/v2

Git

All code samples and libraries used on the course will be deliveredusing GitAll course work code will be delivered using GitHow 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

Recommended you look at the excellent onlinebook [Chacon and Straub, 2014]:

https://git-scm.com/book/en/v2

Git

All code samples and libraries used on the course will be deliveredusing GitAll course work code will be delivered using GitHow 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 labsRecommended you look at the excellent onlinebook [Chacon and Straub, 2014]:

https://git-scm.com/book/en/v2

Git Setup

Git is probably already installed on OS X and Linux, if not:Download for OS XDownload for Linux

Download for WindowsRemember 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 firstone is your Working Directory which holds the actual files. the secondone is the Index which acts as a staging area and finally the HEAD whichpoints 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 remoterepository yet.

Pushing changes

Your changes are now in the HEAD of your local working copy. To sendthose 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 yourrepository 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. Themaster branch is the ”default” branch when you create a repository. Use

other branches for development and merge them back to the masterbranch 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 yourremote 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 mergeanother branch into your active branch (e.g. master), use

in both cases git tries to auto-merge changes. Unfortunately, this is notalways 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 ProfessionalTechnical Reference, 2nd edition.