Software Version Control

CSCI 4140: Open-Source Software

Project Development
Prof. Wei Meng

https://course.cse.cuhk.edu.hk/~csci4140/

Based on slides by Jonathan Aldrich, Charlie Garrod and Ruth Anderson

 Why Version Control?
• Scenario 1 (individual):

- You had a working implementation for Homework #1

yesterday

- You made a lot of improvements to optimize its

performance, UI, etc.

- You haven’t gotten them to work yet

- You need to submit your homework in 5 minutes

2
 Why Version Control? (Cont.)
• Scenario 2 (individual):

- You had a working implementation

- You changed one little thing and your program broke

- You change your program back

- It still breaks

- What’s wrong?

3
 Why Version Control? (Cont.)
• Scenario 3 (individual):

- You accidentally deleted one file with 1K LoC

- Your hard drive failed one day before the deadline

4
 Why Version Control? (Cont.)
• Scenario 4 (team):

- How do you share code with your teammates?

- Email

- Shared network directory

- rsync

- FTP Server / Dropbox / Google Drive

- Google Docs / Microsoft Office 365

5
 Why Version Control? (Cont.)
• Scenario 5 (team):

- You changed one file of the program

- Your teammate makes different changes to the same

file

- How do you merge the changes?

• Scenario 6 (team):

- You changed one file of the program and uploaded it

- Your teammate makes different changes to the same

file and overwrite the one you wrote
6
 The diff utility
• A tool that

- Helps you spot the differences (changes) between

two files

- Generates a “patch” to apply the differences to one

file

• Requires the older version of the file

7
 Solution: Version Control
• You use version control in many softwares

- The undo button in text/photo/spreadsheet editors, etc.

• A Version Control System (VCS) is a software that

- Tracks multiple versions (history) of files (code, resource,

etc.) in a project

- Manages and displays the differences between versions

- Attaches comments with each change

- Allows undo of a change / rollback to an earlier version

- Supports parallel development

8
 Repository
• A central location that storing and managing the history of all files

• Common operations include

- Check in: adding a new file to the repository

- Check out: fetching a copy of a file from the repository to your local
.
workspace Download

- You don’t edit files directly in the repository

- All modifications are local until they are committed

記錄 changesof 2 f les ( New
: ,
Oid ) |+ Comment
- Commit: checking in a modified version of files that were checked out

- Revert: undoing changes to files that were checked out

- Update: fetching copies of the latest version of all files that have
been committed by other users
9
心
 Repository Location
• A repository can be created on your local machine or on
a remote server

- A local repository is suitable for temporarily managing

a personal and small-scale project

• A robust repository is preferred in most situations

- On a machine that allows 24/7 access

- Authorized user can access it anytime from anywhere

- On a machine that provides storage redundancy

- Accidental hard drive failure is no more a worry

10
 History of Files
CommitsHistory

• Record changes or snapshots of the project

- Supports undo

- Implies backups

• Record who performed what changes

• Label cohesive development steps llomment )

- Explains rationale

- Helps understand the changes

- Allows tracing in history and to other development

artifacts (bug trackers, CVEs)
11
一
 Rationale and Traceability

[ 和 nashcid

中 12
 Which Files to Manage?
• All source code and resource files (plain-text files are
preferred)

- C/C++/Java/HTML code

- Build/Configuration files

- Images, styles, binaries

- Documentation

• Excluding intermediary / generated files

- Object files, class files, etc.

• Most VCS have a mechanism to exclude certain files

13
 Concurrent Modifications
同時發 的

• Allowing concurrent modification is challenging

- Conflicts may occur

- Accidental overwriting

• Common strategies A

- Uses locks to prevent concurrent modification

②
- Detects and resolves conflicts

14
生
 !!

Change Conflicts
Problem that may happen

Repository
Repository

F
F

F’ F’’
F F Alice Bob
Alice Bob
Two users read the same file They edit their own copies

Repository Repository

F’ F’’

F’ F’’ F’ F’’
Alice Bob Alice Bob
Alice publishes her copy first Bob publishes his copy later
15
 Applying locktosolvethe poblem
Locking Files
Repository Repository

F F

F F
Alice Bob Alice Bob
Alice locks and reads file F Bob fails to acquire the lock, while Alice edits

Repository Repository

F’ F’

F’ F’ F’
Alice Bob Alice Bob
Alice publishes her copy and releases the lock Bob can lock and edit the latest version
16
 Problems Regarding Locking
• How to lock?

- Announcement vs. central system

• When to unlock?

- Automatically release after each commit

- Manual release

• Blocks parallel development on the same file

17
 Detecting Conflicts
Repository
Repository

F
F

F’ F’’
F F Alice Bob
Alice Bob
Two users read the same file They edit their own copies

Repository Repository

F’ F’

F’ F’’ F’ F’’
Alice Bob Alice Bob
Alice publishes her copy first Bob gets a conflict error
18
 Resolving Conflicts
Repository
Repository

F’
F’

F’ F*
F’ F’’ F’ Alice Bob
Alice Bob
Bob compares the latest version to his own Bob creates a new merged version

Repository Repository

F* F*

F’ F* F* F*
Alice Bob Alice Bob
Bob publishes the merged version Alice also gets Bob’s change now
19
 Resolving Conflicts - Merging
• Merging is required if there are conflicts on changes of the same file

• Conflicts can be resolved automatically if the changes are non-overlapping

• User intervention is required if the changes on the same file are overlapping

- The VCS shows the difference between two changes and asks the user
to manually repair the conflict

-① Combining the changes in some way

-②Selecting one change in favor of the other
-③Reverting both changes
• Resolving conflicts on binary files can be difficult

- The user usually has to discard one version

20
 Branches
Checkout

• Branch: A new copy of the files in a repository

• Branches can be

- Developed independently

- Given their own version number in the VCS

- Merged later

• Branches are often used to explore experimental development

or isolate development activities

- Main branch for development or maintenance

- New branches for experimental features or nontrivial

maintenance work
21
 Variants and Revisions
•
a

Revision replaces prior revision lF

@

• Variant coexists with other variants

• Both revision and variant are described by version

• Release: Published and named version

22
 Branches (Cont.)
• Branches per Release
_ Coumit
↓

Changesbetween
Commit了

• Branches per Task

https://blog.codinghorror.com/software-branching-and-parallel-universes/
23
 Branches (Cont.)
• Branches per Component 構成要素 ,
零件

• Branches per Technology

https://blog.codinghorror.com/software-branching-and-parallel-universes/
24
Semantic Versioning for Releases lapublish & renameaversion

• Given a version number MAJOR.MINOR.PATCH,

increment: Appcation
programming
In
rfae
不可和諧共存的

- MAJOR version when you make incompatible API

changes; eg ) Dakwad compatible
)

H
boolean Arelase
→ number IOS / 3 14 (
_

- MINOR version when you add functionality in a

backwards-compatible manner; egiversion 1 . 0, 1
.

迥
1 2
. .

candowngrade

- PATCH version when you make backwards-

compatible bug fixes eg ) 1
version 1. .
o
⑧

1 . 00 有 bug

25
 Classes of Version Control Systems
• Local version control @

- Local history of files: SCCS (1970s), RCS (1982)

• Central version control @ server

- Examples: CVS (1990), SVN (2004), Perforce, Visual

SourceSafe

• Distributed version control @ tJerver

- Examples: Git (2005), Mercurial, Bitkeeper, ClearCase

26
自
自
己
己
 Centralized VCS
• A central master server maintains the “official copy”
of the files

- All past versions are stored on the central master server

C → ω mmit → S

-
S → Commit → C

Clients synchronize with the central server (update, commit)

• Clients can make “checkouts” of the central repository to own

抄書櫃
local copy Download
lloca ( repository )

- You can make local modifications

- Your changes are not versioned

• Clients make “checkins” to write changes back to the server

增加
- Your checkin increments the repo’s version
27
二
二
Centralized VCS (Con.)
Central Repository

V 1.0 V 1.1 V 1.2

Checkout Checkout Checkout

Commit Commit Commit

V1.1 V1.1 V1.2

Client 1 Client 2 Client 3

28
 Distributed VCS
local & cantral

• Clients and the server maintain multiple repositories

- The central server is optional

- The local repository on a client machine is a complete

copy of the repository on the remote server
複製
• Clients “clone” and “pull” changes from the server repository

• Clients can work on their local copies independently

- Checkin and checkout from/to local repo.

- Commit changes to local repo.

• Clients can “push” (publish) changes back to server

29
 Distributed VCS (Con.)
Repository on Server

V 1.0 V 1.1 V 1.2

Repository on M1 clone, push, pull Repository on M2

V 1.0 V 1.1 V 1.2 V 1.0 V 1.1 V 1.2

checkout / update checkout / update
commit commit

30
 Distributed Versions of Git
• Each modification to the central repository increments the version number
of the overall repository in Subversion

• Versions are not globally coordinated/sorted in Git

- Each user has a copy of the repository

- Changes are committed locally to their local copy of the repository

before being pushed to the remote repository

- Changes are managed with unique IDs through hashes

的 hashalgo .

- Each commit is associated with a unique SHA-1 hash

与
commit 1235a8afaf3939b77bc6f596ea03f2be249c4145
Author: Wei Meng <[email protected]>
Date: Thu Oct 26 17:07:29 2017 +0800

Update template to change chapter page style

commit 42f9f85437e7805886cac3ee260bd7eab9836237
Author: Wei Meng <[email protected]>
Date: Thu Oct 19 19:37:42 2017 +0800

Initial commit of template31

What Are In A Git Commit?
物件

~
hashed filenames
ㄈㄧ

A commit tree

© Scott Chacon and32

Ben Straub “Pro Git”
Relationships Among Commits
• Relationships among changes are tracked in a successor graph

- Possible to merge select changes

- Possible to rewrite the history as long as not shared remotely

Commits and their parents

© Scott Chacon and33

Ben Straub “Pro Git”
 Git Snapshots
Subversion
• Some centralized VCS,
e.g., SVN, tracks version
data (differences) on each
individual file.

• Git keeps “snapshots” of

the entire project

- Each version of the Git

project includes a copy

of every file in the
project

-
l

Faster but requires more

storage
品
camgetime
34 © Scott Chacon and Ben Straub “Pro Git”
 Local Git Areas
• In your local copy, files can be

- In your local .git repository (committed)

- Checked out and modified, but not yet committed (working copy)

- In a “staging area”

- Staged files are ready to be committed.

- A commit saves a snapshot of all stages files.

BDD .git directory

Working Directory Staging Area
了 Stages (Repository)

Checkout the project

Stage changes Aad

Commit
35
 Basic Git Workflow
• Add new files to be tracked

• Modify files in your working directory

files
∞opyotdiffversion
• Stage files, adding snapshots of them to the staging area

• Commit changes, which stores the snapshot permanently to

your .git repository

Untracked Unmodified Modified Staged

Add the file

Edit the file

Stage the file
Remove the file
Commit
36
 Working with Remotes
• Adding a remote repository

• Cloning a complete copy of a remote repository

- Normal checkout and commit operations are local

• Fetching and pulling from your remotes to get missing

versions

- Fetch only downloads the data without merging it with

your local copy

- Pull downloads and merges the remote branch into your

current branch

• Pushing your local changes to your remote repository

37
 Branching and Merging in Git
• Git uses branching heavily to switch between multiple
tasks

• When you merge two branches, the conflicting files will

contain <<< and >>> sections to indicate locations
where Git cannot resolve the conflicts automatically
<<<<<<< HEAD:index.html Filename
<div id="footer">todo: message here</div> Branch 1’s version
======= sepurater
<div id="footer">
thanks for visiting our site
Branch 2’s version
</div>
>>>>>>> SpecialBranch:index.html

38
 Git Branches - HEAD Pointer

od auw

© Scott Chacon and Ben Straub “Pro Git”

39
Use Branches for Different Tasks
Masw HEAD =
C2

timeline
>

© Scott Chacon and Ben Straub “Pro Git”

40
Fast-Forwarding Merge in Git
⑦ Moving masr to tayet bmnn

maser HEAD = C4

© Scott Chacon and Ben Straub “Pro Git”

41
Diverging Development With Git
Branches

:
2 branches

© Scott Chacon and Ben Straub “Pro Git”

42
Three-Way Merge in Git

A merge commit

© Scott Chacon and Ben Straub “Pro Git”

43
 Git Rebasing

Rebasing the change introduced in C4 onto C3

Fast-forwarding the master branch

© Scott Chacon and Ben Straub “Pro Git”

44
 Git Rebasing --onto

C 3 對 clint branch
冇廷們作
延伸fomservrbraum ( c 3 )
mastw brmdh
( Xchange C 3 )

A history with a topic branch off another topic branch

© Scott Chacon and Ben Straub “Pro Git”

45
山二
用
Git Rebasing --onto (Cont.)

Rebasing a topic branch off another topic branch

© Scott Chacon and Ben Straub “Pro Git”

46
 GitHub
• GitHub.com is a website for hosting remote Git repositories

- Many open-source projects use it, e.g., Linux kernel

- Open-source projects can be hosted for free

- Private repositories are free and unlimited since Jan 7, 2019

- Educational plan: https://education.github.com/

• Question: Do you have to use GitHub to use Git?

- Answer: No. Git can be used locally.

- There are alternatives to GitHub, e.g., BitBucket, GitLab,

SourceForge, etc.

- You can set up your own server that speaks the Git protocol to host
repositories
47
 Learn More About Git
• 1st Tutorial Session

- Next Mo 5:30PM - 6:15PM, Y.C. Liang Hall 103

• The Pro Git book, written by Scott Chacon and Ben

Straub

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

48