程序代写 COMP30023 – Computer Systems

COMP30023 – Computer Systems

Source Control – Git
Olya Ohrimenko

• Source control
– What is it
– Why is it important

• Is it relevant to Operating Systems?
– Not directly but Git was created to maintain version control of the

Linux operating system kernel (27.8 million lines of code in 2020)

• It is an important part of (software) computer systems
• You will use Git to submit your projects
• It is also good practice for all programming tasks

• Let’s imagine version control systems does not exist
• Now imagine you are working as a team to develop some

software or a website.
• Your files/code are stored in a shared directory that your

whole team has access to.
– What could go wrong?
– How would you try to prevent things going wrong?
– How would you recover if something does go wrong?

Version Control Systems

• Track and control changes over files
• Why use it?

– Collaboration
– Revision history
– Audit changes

• Sometimes thought of as standalone, but included in
everything from word processors to wiki’s

Version Control Systems: What

Version Control Systems – History

Date to 1972 with
Source Code Control
System (SCCS)

Revision Control System
(RCS): single files

Concurrent Versions
System (CVS): not-
distributed

BitKeeper – 2000
proprietary – solved
some of the problems

Git – developed in
approximately 10 days
in 2005/2006 by Linus

Supports a distributed,
BitKeeper-like

said Git is “expressly designed to make you
feel less intelligent than you thought you were.”

Git – Architecture

https://xkcd.com/1597/

Distributed version control

Git stores changes remotely
by syncing repositories

Git – Architecture

https://msdn.microsoft.com/magazine/mt809117

Directed acyclic graph (DAG)

Git Repository– Architecture

https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging

• Working directory – top level folder with single version of

• Staging area – file in .git that records files to be added to
next commit

• .git directory – configuration and repository database

Git – Steps

https://git-scm.com/book/en/v2/Getting-Started-Git-Basics

• Git does not store deltas (changes), it takes snapshots of the
file system

• Files that are the same are referenced, not duplicated
• This is a big difference compared to other VCS

• Makes branching easier and cheaper
• Git occasionally packs those snapshots into single files, and

uses delta compression to save space
• git gc –aggressive
• You don’t need to run this yourself, it is automatic
• Keeping recent files non-delta exploits locality, like caching does

Git – Storage

Deltas vs Snapshots

https://git-scm.com/book/en/v2/Getting-Started-What-is-Git

(Faster branch

• “git init” initialises a repository
• .git folder is where everything is stored
• Cloning a repository copies this directory

from the remote repository, which contains a
full history of all the files in the repository

Git – Local File Structure

• In essence just a key-value database
• Putting a value into the database returns a SHA1 hash

(40 hex-character identifier) [provides integrity]
• The value is stored as a blob in the objects folders
• The SHA1 hash is the key

• After git init the database is empty
• We can use git status to see this

Git – Database

git status
On branch master
No commits yet
nothing to commit (create/copy files and use “git add” to track)

• Create a readme.txt file with “Hello World” in it
• Staging is the process of marking the file as to be included in

the next commit
• git add is the staging command, staging readme.txt:

• Adds a key-value for the file contents
• Adds the file path to the staging index

Git – Add – Staging

git add readme.txt
On branch master
No commits yet
Changes to be committed:
(use “git rm –cached …” to unstage)
new file: readme.txt

• The commit itself is a git object
• Creates a git tree object of the changes, and

wraps them in a commit.
• The tree object contains Unix directory entries

– Permissions, path, blob key

Git – Commit

git commit –message “first commit”
[master (root-commit) 30918e1] first commit

2 files changed, 2 insertions(+)
create mode 100644 readme.txt
create mode 100644 second.txt

git ls-tree -r HEAD
100644 blob 557db03de997c86a4a028e1ebd3a1ceb225be238 readme.txt

100644 blob 20d5b672a347112783818b3fc8cc7cd66ade3008 second.txt

• Displays log of activity – note the 30 in the commit hash
• The log is always retrieved locally, since all operations are

performed on the local repository

commit 30918e151de55c702976f4a783a7b46c505820db (HEAD -> master)

Author: chrisculnane
Date: Mon Feb 12 13:13:52 2018 +1100

first commit

• Checks out – switches the working tree to a particular
commit/branch (generally the head, but can be a past commit)

Git – checkout

git checkout 30918e
Note: checking out ‘30918e’.

You are in ‘detached HEAD’ state. You can look around, make
experimental changes and commit them, and you can discard any commits
you make in this state without impacting any branches by performing
another checkout.

If you want to create a new branch to retain commits you create, you
may do so (now or later) by using -b with the checkout command again.

git checkout -b

HEAD is now at 30918e1… first commit

Unambiguous prefix of the SHA-1 – at least 4 digits

• Checks out – switches the working tree to a particular
commit/branch (generally the head, but can be a past commit)

Git – checkout

git checkout 30918e
Note: checking out ‘30918e’.

If you want to create a new branch to retain commits you create, you
may do so (now or later) by using -b with the checkout command again.

git checkout -b

HEAD is now at 30918e1… first commit

• Sets the HEAD to the current branch or commit
• All subsequent operations are performed on this branch

• git checkout master
• Returns to the most recent version
• master tells it to checkout the HEAD of the master branch
• This is because when we checked out a specific commit we created

a detached branch – i.e. we were no longer on the master branch
• “master” is not different from any other branch

Git – checkout

• File .git/HEAD contains a reference to the currently checked
out commit

• If it is a commit hash it is a detached branch
• Normally it is a branch reference

• ref: refs/heads/master
• Used to determine which branch current changes apply to

Git – HEAD

Purpose of branches

https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging

Purpose of branches

https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging

Purpose of branches

https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging

• Branches are just text files pointing to a different commit
• Specific commits can be checked out as branches, but

generally we branch from an existing branch (initially master)
• Far more efficient than having to duplicate workspace (SVN)

• Smaller storage space and quicker to create and merge
• Recommended workflow is to branch and merge
• git checkout -b devbranch master

• Checks out master and creates a new branch: devbranch

Git – Branches

git checkout -b devbranch master
Switched to a new branch ‘devbranch’

• So far we’ve only worked locally
• This demonstrates the distributed nature of git

• Clone sets the remote references in the git config file
• This will be called “origin”
• Remote references are just URLs to your remote repository

• Pull will perform two steps fetch and merge
• Fetch retrieves any changes from the remote (origin)
• Merge combines those changes into the local repo

• Push transfers your local commits to the remote repo

Git – Clone, Push, & Pull

• Tags can be used to add more informative names to
commits, i.e. releases 1.0

• A release is also often stored on a branch, this allows bug
fixing to continue without impact on future development

• Git doesn’t solve inherent conflicts, two people editing the
same file can still create a problem. General workflow is to
commit/push often, with small changes.
• Master → Dev → Feature

• Not uncommon for developers to be unable to merge onto
Dev: maybe restricted, or require code review prior to
senior staff merging branches

Git – Real-world Use

• Binary files can be inefficient to store in git
• Git automatically packs file changes using delta compression
• Binary files typically exhibit large changes (JPEG recompression)
• Increases the size of the clone operation

• Forks – complete separate copy of repository
• Link remains to parent
• Useful for large changes, keep development work out of main

repository
• Remains even if original repository is removed

Git – Real-world Use

• Snippets of code running after push (e.g., test cases)
• Important part of software development
• Continuously build, test, and deploy iterative code changes
• Reduce the chance of maintaining test-failing code

Git(Hub) – Continuous Integration

• Build processes that depend on
external repositories are fragile
• A user deletes the repository -> build

process breaks
• Risk of unknown code changes in

• Better to fork the repository

• Higher support costs – need to pull

• Security
• Be careful what you store in public

repositories
• Never store credentials/aws keys

And finally…

• Why use version control
• What and how it helps in software development
• Experiment with Git in the practical class in week 2
• Get GitLab access in week 2
• You will use Git to submit projects
• Check out use case on Canvas about Heartbleed bug

程序代写 CS代考加微信: powcoder QQ: 1823890830 Email: powcoder@163.com

Related Posts