Information systems and programming
Lecture 1 – Introduction to Git and GitLab
Gianluca Quercini
[email protected]
Cursus Ingénieur 1A
CentraleSupélec, 2024
Introduction to Git Background and motivation
Context
You work on a software development project. Several needs must be
addressed.
You want to keep the history of all changes in the project.
You want to revert to a previous version at any time.
You want to collaborate with other developers.
You want your collaborators to be able to add/remove features at
any time.
Gianluca Quercini SIP Cursus Ingénieur 1A 1 / 30
Introduction to Git Background and motivation
First scenario: working alone
If you work alone on your project, you can create a directory on your
computer containing all the project files.
my-project
Gianluca Quercini SIP Cursus Ingénieur 1A 2 / 30
Introduction to Git Background and motivation
First scenario: working alone
When you modify some files, you cannot return to a previous
version...
my-project
Gianluca Quercini SIP Cursus Ingénieur 1A 3 / 30
Introduction to Git Background and motivation
First scenario: working alone
...unless you save a copy of the project before applying any
modification.
my-project-05-10-21
my-project-04-10-21
Gianluca Quercini SIP Cursus Ingénieur 1A 4 / 30
Introduction to Git Background and motivation
First scenario: working alone
At some point, you end up with several copies (a.k.a., versions, or
snapshots) of your project.
my-project-04-10-21 my-project-05-10-21 my-project-05-10-21-14:00 my-project-05-10-21-23:55
my-project-06-10-21 my-project-06-10-21-12:00 my-project-07-10-21-11:00 my-project-08-10-21
my-project-09-10-21
Gianluca Quercini SIP Cursus Ingénieur 1A 5 / 30
Introduction to Git Background and motivation
First scenario: working alone
Manually keeping several snapshots presents several limitations:
Impossible to track changes across versions.
“when exactly did you introduce a bug in your project?”
Impossible to track the progress of the project across versions.
“in which version did you implement a specific function?”
Messy naming conventions.
Difficult to name the different versions consistently.
Gianluca Quercini SIP Cursus Ingénieur 1A 6 / 30
Introduction to Git Background and motivation
First scenario: working alone
Even in a simplified scenario, where you are the only actor of a project, you
need a tool to manage the different versions of your project.
What about using storage services in the cloud?
Gianluca Quercini SIP Cursus Ingénieur 1A 7 / 30
Introduction to Git Background and motivation
Storage solutions in the cloud
Different versions of a file are kept (good).
Versions may be automatically merged to save space (bad).
You don’t have the historical versions of the files on your computer
(bad).
my-project
version history
Gianluca Quercini SIP Cursus Ingénieur 1A 8 / 30
Introduction to Git Background and motivation
Second scenario: working in team
You want to collaborate with other people: other needs must be addressed.
Share a common repository for all the project files.
Share the whole version history.
Track the author of every change to the project files.
Manage multiple lines of development of the project.
Merge different lines of development of the project.
Gianluca Quercini SIP Cursus Ingénieur 1A 9 / 30
Introduction to Git Background and motivation
The answer to all these problems is tools that are known as
version control systems. Git is one of them!
VCS
Gianluca Quercini SIP Cursus Ingénieur 1A 10 / 30
Introduction to Git Version control systems: overview
Version control systems: a bit of history
There are three types of version control systems (VCS):
Local VCS.
Centralized VCS.
Distributed VCS.
Gianluca Quercini SIP Cursus Ingénieur 1A 11 / 30
Introduction to Git Version control systems: overview
Local version control systems
Local version control systems store the changes to files in a single database
that is hosted in a local computer.
1970s: Source Code Control System (SCCS), developed by Bell
Labs, free but closed source.
1982: Revision Control System (RCS), free and open source.
☞ Local version control systems can only work on a file at a time.
Collaboration is not possible.
Gianluca Quercini SIP Cursus Ingénieur 1A 12 / 30
Introduction to Git Version control systems: overview
Centralized version control systems
Centralized version control systems store the changes to files on a single
(central) server that the collaborators can connect to.
Easy setup, these systems are still in use today.
Multiple people can collaborate to the same project.
If the server is unavailable, people cannot work on the project.
Two people cannot work on the same file at the same time.
☞ These limitations were addressed by Concurrent Version Sys-
tem (CVS).
Gianluca Quercini SIP Cursus Ingénieur 1A 13 / 30
Introduction to Git Version control systems: overview
Concurrent Version System (CVS)
Open source, could track multiple files.
All the history is stored in a remote database (repository).
Collaborators can copy the content of the remote repository to their
local computers.
☞ Only the content of the repository (not the change history) is
copied to the local computers.
Gianluca Quercini SIP Cursus Ingénieur 1A 14 / 30
Introduction to Git Version control systems: overview
Apache Subversion (SVN)
Evolution of CVS, developed in 2000, open source.
SVN can track non-text files.
SVN can track entire directories: operations like renaming, adding
and removing can also be tracked.
☞ It is still in use today.
Gianluca Quercini SIP Cursus Ingénieur 1A 15 / 30
Introduction to Git Version control systems: overview
Distributed version control systems
Distributed version control systems are similar to centralized ones, but
there is no main server. Each collaborator has an entire copy of the
repository, including the change history.
BitKeeper SCM (2000) was one of the first distributed version
control systems.
It was closed source and provided a community version that was free.
Bitkeeper was used by Linus Torvalds to maintain the source code of
the Linux kernel (2002 - 2005).
Linus Torvalds created Git to have an open-source version control to
maintain his code.
☞ Git and Mercurial are today’s most popular distributed control
version systems.
Gianluca Quercini SIP Cursus Ingénieur 1A 16 / 30
Introduction to Git Brief overview of Git
Git: installation and configuration
Git is a software that can be installed on the major operating systems
(Windows, macOS, Linux).
We need to configure Git before using it.
Basic configurations: set up your name and email address, specify
the text editor used by Git.
Gianluca Quercini SIP Cursus Ingénieur 1A 17 / 30
Introduction to Git Brief overview of Git
How to work with Git?
There are two ways to use Git: command-line interface (CLI) and
graphical user interface (GUI).
Default way to work with Git: CLI.
Several GUI tools exist: GitHub Desktop, SourceTree, TortoiseGit and
many more (https://git-scm.com/downloads/guis).
☞ Visual Studio Code provides GIT support out-of-the-box.
Gianluca Quercini SIP Cursus Ingénieur 1A 18 / 30
Introduction to Git Brief overview of Git
Git repositories
A Git repository is a folder that contains the history of all versions and
modifications of a project.
There are two types of repositories:
A local repository is one stored on a user computer.
A remote repository is one stored by a hosting service.
Several Git hosting services exist, such as GitHub, GitLab or
Bitbucket.
☞ In this course, we use GitLab.
Gianluca Quercini SIP Cursus Ingénieur 1A 19 / 30
Introduction to Git Brief overview of Git
Local repository: all starts with a working directory
When working on a software development project:
We create a working directory on our computer.
The working directory contains all the project files and directories.
The working directory is not a Git repository.
working directory
Gianluca Quercini SIP Cursus Ingénieur 1A 20 / 30
Introduction to Git Brief overview of Git
Local repository: initialization
We need to explicitly tell Git (via an initialization command) that all files
and directories must be tracked.
local repository
working directory
.git
☞ The initialization command creates a hidden directory named .git
that contains the local repository.
Gianluca Quercini SIP Cursus Ingénieur 1A 21 / 30
Introduction to Git Brief overview of Git
Local repository: tracking the modifications
When working on a project, we modify the content of the working
directory.
Modifications: add/remove files/directories, modify files/directories.
Git will automatically track all modifications in the working
directory (and subdirectories).
☞ We never modify the files in the local repository directly.
Gianluca Quercini SIP Cursus Ingénieur 1A 22 / 30
Introduction to Git Brief overview of Git
Local repository: snapshots
When we modify some files in the working directory...
... Git knows that we made some modifications...
...but cannot tell why these modifications have been made.
Modifications have always a purpose: correcting a bug, defining new
functions, changing a data structure...
It is important that related modifications be considered as part of the same
snapshot or version of the project, with a description that explains them.
This helps keeping a clear history of all changes.
Gianluca Quercini SIP Cursus Ingénieur 1A 23 / 30
Introduction to Git Brief overview of Git
Local repository: commit
We explicitly need to tell Git (via a commit command) to create a new
snapshot of the project with the specified modifications.
local repository
working directory
.git
snapshot1
commit
modified files
☞ In Git parlance, a snapshot is known as a commit.
Gianluca Quercini SIP Cursus Ingénieur 1A 24 / 30
Introduction to Git Brief overview of Git
Remote repository
All commits to the local repository are stored on our computer.
Why it is important to use a remote repository:
Backup the project to another device.
Access the project from multiple computers.
Collaborate on the project with other people.
☞ The first two reasons are important even if you work alone on a
project.
Gianluca Quercini SIP Cursus Ingénieur 1A 25 / 30
Introduction to Git Brief overview of Git
Pushing to a remote repository
We first create a remote repository on GitLab through a Web
interface.
We then link our local repository to the remote repository (via a
command on our local repository).
Finally, we push (i.e., upload) our local repository to the remote
repository.
working directory remote repository
.git
snapshot1
snapshot1
git push
Gianluca Quercini SIP Cursus Ingénieur 1A 26 / 30
Introduction to Git Brief overview of Git
Cloning a remote repository
Another way to create a local repository is to clone a remote repository.
remote repository
working directory
local repository
git push
git clone
working directory
local repository
Gianluca Quercini SIP Cursus Ingénieur 1A 27 / 30
Introduction to Git Brief overview of Git
Collaborating on a remote repository
Multiple users can push changes to the same repository. Conflicts may
arise and need to be taken care of manually.
remote repository
working directory
local repository
git push
working directory
local repository
git push
Gianluca Quercini SIP Cursus Ingénieur 1A 28 / 30
Introduction to Git Git: conclusions
Git: recap
Git is a distributed control version system.
The best way to use Git is through a command-line interface.
Each collaborator keeps a local repository that contains a project
files, including all the change history.
With appropriate commands, a group of related modifications can
be registered as a project snapshot (a.k.a., version or commit).
A remote repository is usually kept on a hosting platform (e.g.,
GitLab).
Multiple people can push their local commits to the same remote
repository.
Conflicts may arise and need to be taken care of manually.
Gianluca Quercini SIP Cursus Ingénieur 1A 29 / 30
Introduction to Git Git: conclusions
Git: recap
Git is not only used for software development projects. It can be used to
track any type of files, including binary files (Microsoft Word or Excel
documents).
Git is not meant as a substitute of human communication! People still
need to talk to each other to avoid creating problems and conflicts in the
shared repository.
Gianluca Quercini SIP Cursus Ingénieur 1A 30 / 30
