Version Control
Systems
29/09/2016
DLR-IDL
2023-2024
Work under Creative Commons BY-SA1 license 2/1
You are free:
§ to use, to copy, to distribute and to transmit this creation to the public;
§ to adapt this work.
Under the following terms:
§ Attribution (BY): you must attribute the work in the manner specified by
the author or licensor (but not in any way that suggests that they endorse
you or your use of the work).
§ ShareAlike (SA): if you modify, transform, alter, adapt or build upon this
work, you may distribute the resulting work only under the same, similar or
a compatible license.
1
[Link]
Important notes 3/1
§ if you do not understand something, please ask your
questions. We cannot answer the questions you do not ask. . .
§ if you disagree with us, please say it (we follow Crocker’s
rules2 )
§ people don’t learn computer science by only reading few
academic slides: practicing is fundamental
2
[Link]
Sentences one would have preferred not to hear 4/1
§ Aaaaah! Three months of work lost!
§ Oops. . . Was this file really important?
§ Great, everyone has finished! Who integrates all the parts?
§ Why did I wrote this piece of code?
§ Great functionality, but I think the last week version was better.
Uh. . . which one?
§ I cannot find the version we have made 6 years ago for
BigCustomer Inc., I need it immediately for a new contract!
§ I have already done this bugfix. . . on my laptop I left at home.
§ It doesn’t work anymore! Who messed up my code?
Motivations 5/1
§ Software traceability: tracking and documenting changes,
retrieving former versions
§ Flexibility: feature trials, quick rollbacks
§ Parallelism and team work: multi-sites, multi-computers,
multi-developers and multi-activities
§ Safety: “backup”3 with history
ñ One needs tools to solve these problems
3
VCS are not (space) efficient backup systems
Version Control Systems (VCS) 6/1
§ Used for
§ storing files
§ keeping track of changes on those tracked files
§ sharing
§ Each collaborator works on a local copy
§ Synchronization with one (or several) remote server(s)
§ 2 families of VCS
§ centralised (Subversion, CVS, . . . )
§ distributed (Git, Mercurial, Darcs, . . . )
Architecture of a centralised VCS 7/1
WORKING
COPY
synchro
workspace #1
synchro
WORKING CENTRAL
COPY REPOSITORY
workspace #2
synchro
WORKING
COPY
workspace #3
Architecture of a distributed VCS 8/1
REPOSITORY synchro
synchro REPOSITORY
WORKING
COPY synchro synchro
workspace #1
REPOSITORY REPOSITORY
synchro synchro
WORKING WORKING
COPY COPY
workspace #2 workspace #3
Focus on a specific VCS: Git 9/1
Why Git?
§ very popular
§ many platforms provide services built on Git (Bitbucket, Gitlab,
GitHub)
§ a bit less intuitive than other VCS for beginners, therefore if
you are able to use Git, you will be able to use other VCS
§ . . . and because we had to choose a tool
Git architecture and vocabulary 10 / 1
REMOTE
REPOSITORY
Workspace
Gitspace
WORKING STAGING CURRENT LOCAL
DIRECTORY AREA VERSION REPOSITORY
§ working directory = files where changes are made
§ staging area = current selected changes
§ current version = current reference version
§ (remote/local) repository = a database of changes
Diving into Git core 11 / 1
Repository
Repository
Diving into Git core 11 / 1
Repository
CV = current version
CV
Repository
Diving into Git core 11 / 1
Repository
WD = working directory
WD CV
Repository
.tex
.pdf
.java
.ml
Diving into Git core 11 / 1
Repository
WD CV
Repository
.tex
.pdf
‰
.java
.txt
.ml
Diving into Git core 11 / 1
Repository
SA = staging area SA
add
rm
WD CV
Repository
.tex
.pdf
‰
.java
.txt
.ml
Diving into Git core 11 / 1
Repository
SA
add
rm
WD CV
Repository
.tex
.pdf
.java
.txt
Diving into Git core 11 / 1
Repository
index
SA
.git
File system HEAD
WD CV
Repository
objects/, refs/
.tex
.pdf
config
.java
config
.txt
Diving into Git core 11 / 1
Repository
index
SA
commit .git
add/rm
push
File system HEAD
WD CV fetch/
Repository clone/
objects/, refs/ pull
.tex
.pdf
config
.java
config
.txt
checkout/merge
Structure of a versioned project with Git 12 / 1
jcbach@minitel2>dlr-idl$ls -la
drwxr-xr-x 17 jcbach jcbach 4096 Sep 18 09:07 .
drwxr-xr-x 212 jcbach jcbach 12288 Aug 31 17:11 ..
drwxr-xr-x 7 jcbach jcbach 4096 Sep 18 10:43 .git
-rw-r--r-- 1 jcbach jcbach 132 Jun 3 2020 .gitignore
-rw-r--r-- 1 jcbach jcbach 200 Jan 16 2019 .project
-rw-r--r-- 1 jcbach jcbach 308 Mar 11 2019 [Link]
-rw-r--r-- 1 jcbach jcbach 832 Mar 11 2019 [Link]
-rw-r--r-- 1 jcbach jcbach 3936 Sep 9 2020 README
drwxr-xr-x 4 jcbach jcbach 4096 Sep 18 10:48 adm
drwxr-xr-x 2 jcbach jcbach 4096 Oct 14 2019 agile
drwxr-xr-x 6 jcbach jcbach 4096 Nov 14 2022 build
drwxr-xr-x 3 jcbach jcbach 4096 Oct 18 2022 ci
-rw-r--r-- 1 jcbach jcbach 1496 Jan 23 2019 [Link]
-rw-r--r-- 1 jcbach users 17 Aug 23 15:52 [Link]
drwxr-xr-x 12 jcbach jcbach 4096 Sep 30 2022 devenv
drwxr-xr-x 3 jcbach jcbach 4096 Aug 11 2020 exam
drwxr-xr-x 3 jcbach jcbach 4096 Sep 18 10:31 introduction
drwxr-xr-x 2 jcbach jcbach 4096 Sep 5 15:30 licence
drwxr-xr-x 2 jcbach jcbach 4096 Sep 26 2019 notes
drwxr-xr-x 2 jcbach jcbach 4096 Oct 24 2018 poly
drwxr-xr-x 2 jcbach jcbach 4096 Sep 10 2020 presentation
drwxr-xr-x 4 jcbach jcbach 4096 Sep 18 10:46 projet
-rw-r--r-- 1 jcbach jcbach 618 Nov 7 2018 [Link]
drwxr-xr-x 5 jcbach jcbach 4096 Oct 18 2022 test
.git structure 13 / 1
jcbach@minitel2>.git$ls -la
drwxr-xr-x 7 jcbach jcbach 4096 Sep 18 10:43 .
drwxr-xr-x 17 jcbach jcbach 4096 Sep 18 09:07 ..
-rw-r--r-- 1 jcbach jcbach 20 Sep 18 10:43 COMMIT_EDITMSG
-rw-r--r-- 1 jcbach jcbach 109 Jan 18 2023 FETCH_HEAD
-rw-r--r-- 1 jcbach jcbach 23 Aug 9 2019 HEAD
-rw-r--r-- 1 jcbach users 41 Jan 18 2023 ORIG_HEAD
-rw-r--r-- 1 jcbach jcbach 370 Aug 9 2019 config
-rw-r--r-- 1 jcbach jcbach 73 Oct 23 2018 description
-rw-r--r-- 1 jcbach jcbach 17989 Nov 29 2019 [Link]
drwxr-xr-x 2 jcbach jcbach 4096 Oct 23 2018 hooks
-rw-r--r-- 1 jcbach users 35901 Sep 18 10:43 index
drwxr-xr-x 2 jcbach jcbach 4096 Oct 23 2018 info
drwxr-xr-x 3 jcbach jcbach 4096 Oct 24 2018 logs
drwxr-xr-x 260 jcbach jcbach 4096 Sep 18 10:43 objects
drwxr-xr-x 5 jcbach jcbach 4096 Mar 12 2019 refs
jcbach@minitel2#[Link]>.git$
Git by the example 14 / 1
§ Practical use cases in order to learn few commands
§ setting up a new repository (init, remote url)
§ retrieving a repository (clone)
§ making changes in the working repository (status)
§ updating the remote environment (add, commit, push)
§ checking differences after changes (diff)
§ updating dev environment (fetch, pull)
§ diverging/branching (branch, merge, checkout)
§ ...
§ Non-exhaustive use cases
§ Workflows
Retrieving a repository 15 / 1
git clone <url>
git checkout <ref> git clone -n <url>
change change
WORKING STAGING CURRENT LOCAL REMOTE
DIRECTORY AREA VERSION REPOSITORY REPOSITORY
$> git clone -n <url>
only creates the .git directory
$> git checkout <ref>
retrieves files from local repository into the working directory
$> git clone <url>
creates the .git directory and retrieves files into the working
directory; clone = clone -n + checkout
Making changes in the working directory 16 / 1
tracked
WORKING STAGING CURRENT LOCAL
DIRECTORY AREA VERSION REPOSITORY
untracked
Checking the current state
$> git status
On branch main
Your branch is up to date with 'origin/main'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: file1
...
Untracked files:
(use "git add <file>..." to include in what will be committed)
file4
...
no changes added to commit (use "git add" and/or "git commit -a")
Updating the remote environment 17 / 1
git add git commit git push
change
WORKING STAGING CURRENT LOCAL REMOTE
DIRECTORY AREA VERSION REPOSITORY REPOSITORY
Example
$> git add file1 file2 file3 ...
add in the index of the staging area
$> git commit -m “add my super new feature”
...
$> git push
push into the remote repository
Checking differences after changes 18 / 1
WORKING STAGING CURRENT LOCAL
DIRECTORY AREA VERSION REPOSITORY
modified staged commited
Diff commands
$> git diff
$> git diff --staged
$> man git-diff will help you
Updating dev environment (fetch) 19 / 1
git fetch
WORKING STAGING CURRENT LOCAL REMOTE
DIRECTORY AREA VERSION REPOSITORY REPOSITORY
$> git fetch
§ retrieves updates from the remote repository
§ is safe
§ does not affect working directory ñ cannot lose uncommited
changes,
§ no automated merge
Updating dev environment (pull) 20 / 1
git pull
2. merge 1. fetch
WORKING STAGING CURRENT LOCAL REMOTE
DIRECTORY AREA VERSION REPOSITORY REPOSITORY
$> git pull
retrieves updates from the remote repository and merge them
with the working directory
§ git merge: to be seen few slides later
Diverging: vocabulary 21 / 1
§ a branch = a reference to a version
§ can be seen as a “local checkpoint” (another says like a bookmark)
§ branching
§ creating a named reference to a version
§ the common way to work without messing with the main line
Diverging (branch) 22 / 1
git branch [-a]
git branch <ref>
git branch -d
WORKING STAGING CURRENT LOCAL
DIRECTORY AREA VERSION REPOSITORY
$> git branch
list local branches
$> git branch -a
list all (local and remote) branches
$> git branch <ref>
creates a named branch from the current branch
$> git branch -d <ref>
deletes a named branch
Diverging (checkout) 23 / 1
git checkout [-b] <ref>
change
WORKING STAGING CURRENT LOCAL
DIRECTORY AREA VERSION REPOSITORY
$> git checkout <ref>
changes the current branch
$> git checkout -b <ref>
creates a branch from the current branch and changes to it
(“ git branch ` git checkout)
Diverging (merge) 24 / 1
§ starting point: 2 branches (main + newawesomefeature), HEAD
points to main
$> git merge newawesomefeature
integrate changes from newawesomefeature branch into main
§ two situations
§ no conflict: changes from newawesomefeature are integrated in
the main (local) line, time to push. . .
§ conflicts: resolution needed in order to be able to push
§ conflict resolution:
1. fix the conflicts (edit the files, keep/remove stuff)
2. add the changes
3. commit
Diverging by the example 25 / 1
HEAD
v0.1 main
A B C
Initial situation
Diverging by the example 25 / 1
HEAD
v0.1 main
A B C
testing
$> git branch testing
Diverging by the example 25 / 1
v0.1 main
A B C
testing
HEAD
$> git checkout testing
Diverging by the example 25 / 1
HEAD
v0.1 main testing
A B C D
One commit later
Diverging by the example 25 / 1
HEAD
v0.1 main testing
A B C D
$> git checkout main
Diverging by the example 25 / 1
v0.1 main testing
A B C D
hotfix
HEAD
$> git checkout -b hotfix
Diverging by the example 25 / 1
v0.1 main testing
A B C D
hotfix
HEAD
One commit later
Diverging by the example 25 / 1
HEAD
v0.1 main testing
A B C D
hotfix
$> git checkout main
Diverging by the example 25 / 1
v0.1 testing
A B C D
hotfix
main
$> git merge hotfix HEAD
Diverging by the example 25 / 1
v0.1 testing
A B C D
main
HEAD
$> git branch -d hotfix
Diverging by the example 25 / 1
HEAD
v0.1 testing
A B C D
main
$> git checkout testing
Diverging by the example 25 / 1
HEAD
v0.1 testing
A B C D F
main
One commit later
Diverging by the example 25 / 1
v0.1 testing
A B C D F
main
HEAD
$> git checkout main
Diverging by the example 25 / 1
HEAD
v0.1 testing main
A B C D F G
$> git merge testing
Summary of a typical Git workflow 26 / 1
WORKING REMOTE
DIRECTORY REPOSITORY
STAGING LOCAL
git clone
AREA REPOSITORY
git add/rm
git commit
git fetch/pull˚
git checkout/branch/merge
git push
Adopting a workflow 27 / 1
§ one tool, many usages
§ tools alone do not solve development problems
§ need of a process that fits the team
§ many possible Git workflows (examples later)
§ centralised workflow
§ feature branch workflow
§ gitflow workflow
§ forking workflow
§ ...
Centralised workflow 28 / 1
§ one central repository, one branch (main)
§ common when coming from centralised systems like
Subversion
§ common for small size teams
§ easy to understand for a newcomer
Source: Atlassian
Feature branch workflow 29 / 1
§ central repository + main branch = official project history
§ one branch per feature: no direct commit on the main branch
§ feature branches are pushed to the central repository
§ branches are then merged (after pull requests, feedbacks,
conflict resolutions)
HEAD
v1 v1.1 main
A B E F I
C D G H
feature1 feature2
Gitflow workflow4 30 / 1
§ strict branching model designed around the project release
§ well-suited for large projects with deadlines (releases)
§ one branch one role, workflow defines their interactions
§ can be combined with feature branch workflow
§ project history = main (the releases) + development branch
Source: Atlassian
4
A famous example:
[Link]
Forking workflow 31 / 1
§ one serverside repository per developer
§ each developer manages her repository and make pull
requests to the reference repository
§ typical model when contributing to a FLOSS5 project hosted on
GitHub: “Fork us on GitHub”
Source: Atlassian
5
[Link]
Workflows: summary 32 / 1
§ chosen workflow depends on the team’s concerns and
organisation
§ no one-size-fits-all Git workflow
§ feature workflow: business domain oriented
§ forking and gitflow workflows: repository oriented
§ what is a good workflow?
§ enhance or limit team efficiency?
§ scale with team size?
§ easy to undo mistakes and errors?
§ impose any new unnecessary cognitive overhead to the team?
§ does it limit conflicts?
VCS pratices 33 / 1
§ Git
§ useful and powerful tool
§ . . . but a tool alone does not solve all problems. It can also create
ones
ñ developers do not only need tools, but also working processes
§ Good practices
§ formalizing the process/workflow
§ coordinating with co-workers
§ testing before sending changes
§ updating before sending a change
§ commiting meaningful changes
§ commiting often
§ adding meaningful messages for commits
§ not commiting generated files
§ short-lived branches
VCS in practice: how to start? 34 / 1
§ By practicing
§ during the next lab session: there are a lot of small exercises to
discover most important Git commands
§ during every lab sessions, even in non-CS context
§ at home
§ One usually needs a server to host repositories6
§ Some questions to ask before chosing
§ do you want to make your project public?
§ is there any security, privacy or IP problems with the project?
§ is your project a cornerstone of your business?
§ Your answers should drive your choices of VCS hosting
§ simple and free non-professional account on an open platform
§ paid service on a platform
§ installation of your own VCS server
6
. . . but it is not mandatory: you can use Git in serverless mode! See later
VCS in practice: which platform to start with? 35 / 1
§ IMTA infrastructure for academic projects and for learning:
§ Gitlab: [Link] 8
§ Redmine: [Link]
(+Subversion)
§ Many platforms can be used without any fee:
§ Gitlab: [Link]
§ GitHub: [Link]
§ Gitea: [Link]
§ Bitbucket: [Link]
§ Assembla: [Link] (+Subversion)
§ Sourcehut: [Link]
§ . . . and probably many other
§ . . . but you can also install your own server!
7
prefer it rather than redmine-df which will probably die in a near future
8
VPN is required to access the service from outside, cf. https:
//[Link]/catalogue-disi/eduvpn-etudiant-3/
Serverless mode: a simple way to start with Git 36 / 1
§ Git can also be used without any other host
1. $> mkdir mycode
2. $> cd mycode
3. $> git init
initialize a new Git repository
§ that type of Git repository can be shared
§ as every folder (copy/paste on an USB key, . . . )
§ or using a Git command to add a remote repository (it has to exist)
$> git remote add <name> <url>
Git integration 37 / 1
§ If you use a mainstream IDE, Git is probably already integrated
§ Eclipse: Window > Perspective > Open Perspective > Other > Git
§ vscode
§ Ctrl+Shift+G
§ nice and useful plugins: Git graph and GitLens
§ IntelliJ: Alt+‘
§ well-configured Vim or Emacs: you don’t need any help
§ maybe a TUI: tig, lazygit
Conclusion 38 / 1
§ basic principles of VCS
§ basic principles
§ two main families: centralised vs decentralised
§ tools diversity
§ some good practices for VCS usage
§ importance of a workflow
§ should be simple
§ should enhance the team productivity
§ should be oriented by business requirements
§ VCS usage should be an habit, not a constraint
§ basics for a specific (but probably the most common) VCS: Git
§ discover Git in the practical work!
Resources 39 / 1
§ VCS
§ [Link]
§ [Link]
§ [Link]
intro-to-distributed-version-control-illustrated/
§ Git
§ [Link]
§ [Link] (Pro Git book)
§ [Link]
§ [Link]
§ [Link]
§ Subversion: [Link]
§ Mercurial: [Link]
Gentle reminder 40 / 1
N Important notes
§ if you do not understand something, please ask your
questions. We cannot answer the questions you do not ask. . .
§ if you disagree with us, please say it (we follow Crocker’s
rules9 )
§ people don’t learn computer science by only reading few
academic slides: practicing is fundamental
9
[Link]
