Introduction to Git – - Fall 2021
Lecture 1: Why use version control?
Image Not Showing
Possible Reasons
The image file may be corrupted The server hosting the image is unavailable The image path is incorrect The image format is not supported
Learn More →
Image Not Showing
Possible Reasons
The image file may be corrupted The server hosting the image is unavailable The image path is incorrect The image format is not supported
Learn More →
Image Not Showing
Possible Reasons
The image file may be corrupted The server hosting the image is unavailable The image path is incorrect The image format is not supported
Learn More →
Slides: https://hackmd.io/@hpc2n-git-2021/L1-motivation#/
In software engineering, version control (also known as revision control, source control, or source code management) is a class of systems responsible for managing changes to computer programs, documents, large web sites, or other collections of information.
– - Wikipedia
Version control systems (VCS)
… systems responsible for managing changes …
In an ideal world, things develop linearly:
Every new version is an improvement upon the previous version.
Everyone knows what everyone else is doing
In the end, things are simply finished.
digraph {
rankdir=LR
Mon[label="Monday's\n improvements"] [fixedsize=circle]
Tue[label="Tuesday's\n improvements"] [fixedsize=circle]
Wed[label="Wednesday's\n improvements"] [fixedsize=circle]
Mon -> Tue
Tue -> Wed
}
In the real world, things develop non-linearly:
A new version can be anything between
a complete catastrophe and
a major breakthrough.
People do not know what others are doing
Sometimes we are simply fixing earlier mistakes …
digraph {
rankdir=LR
Mon[label="Monday's\n improvements"] [fixedsize=circle]
Tue[label="Tuesday's\n mistakes"] [fixedsize=circle]
Wed[label="Wednesday's\n corrections"] [fixedsize=circle]
Mon -> Tue
Tue -> Wed
}
Going back to an earlier version
Sometimes, it is easier to simply backtrack to an earlier version …
digraph {
rankdir=LR
Mon[label="Monday's\n improvements"] [fixedsize=circle]
Tue[label="Tuesday's\n mistakes"] [fixedsize=circle]
Wed[label="Wednesday's\n improvements"] [fixedsize=circle]
Mon -> Tue
Mon -> Wed
}
Where is this earlier version ?
CTRL + Z
my_file.txt, my_file.txt.old, …
My project/
2020-08-12/
2020-08-13/
…
Daily home directory backup
Challenges and obstacles
Prone to mistakes
CTRL + Z has limits, overwritten/deleted files, human/hardware error
How much to save?
Individual files? Everything? How much space is required?
How to organize versions?
What is the difference between different versions?
Overall, difficult to manage!
What about the granularity?
digraph {
rankdir=LR
subgraph cluster1 {
t1a [label="Component A\n improvement"] [fixedsize=circle]
t1b [label="Component B\n mistake"] [fixedsize=circle]
t1c [label="Component C\n improvement"] [fixedsize=circle]
label="Mondays's changes"
}
subgraph cluster2 {
t2a [label="Component A\n improvement"] [fixedsize=circle]
t2b [label="Component B\n correction"] [fixedsize=circle]
t2c [label="Component C\n mistake"] [fixedsize=circle]
label="Tuesday's changes"
}
subgraph cluster3 {
t3a [label="Component A\n mistake"] [fixedsize=circle]
t3b [label="Component B\n improvement"] [fixedsize=circle]
t3c [label="Component C\n correction"] [fixedsize=circle]
label="Wednesday's changes"
}
t1a -> t2a
t1b -> t2b
t1c -> t2c
t2a -> t3a
t2b -> t3b
t2c -> t3c
}
This compounds the problems!
How does VCS solve this?
Stores the history using snapshots (commits)
Each snapshot represents the project at a given point in time
Manages snapshots and associated metadata
Naming (tags), comments, dates, authors, etc
Easy to move between different snapshots
Can handle different degrees of granularity
Can handle multiple development paths (branches)
Comparing and joining
VCS makes it easy to compare different snapshots
Named revisions, comments, time information, author information
Diff tools
Search tools
Bisection search
VCS also allows the joining (merging) of different snapshots
Easy to experiment with ideas
Collaboration
One of the primary functions of VCS is to allow collaboration
Usual setup: server (remote) + multiple clients
People work locally and send (push) the changes to the server
VCS keeps track of what has been done and by whom
Safer since mistakes can be easily remedied
The contributions of several people can be merged
Backup
VCS functions as a backup
Locally, the system maintains a copy of each file
Usually only the changes or the files that have changed are stored
Globally, lost files can be recovered from the server
Integration
VCSs such as Git have been integrated with several services
Services such as GitHub can do almost everything for you
Store history, distribute, testing / continuous integration, bug reports, milestones, website, …
Summing up
Version control systems
keeps track of your files and other output
tracks what is created and modified
tracks who made the modifications
tracks why the modifications were made (if you make good commit comments)
Practical use cases
What are the practical use cases for VCS?
Source code
Many VCSs are designed for managing source code
Manage deployment (production, development, testing, etc)
Manage published versions (v0.1 etc)
Manage (experimental) features
Bug hunting
But also for: writers, artists, composers …
Latex files
Track which version of a manuscript has been
submitted,
revised and/or
accepted
Collaboration between several authors
HPC: batch files and data
Track different version of your batch scripts
Easy to check the used configuration afterwards
Track input and output files
Limited to smallish files
Examples of VCS
SCCS: The first VCS. Created in 1972 at Bell Labs. Was available only for UNIX and worked with Source Code files only.
RCS (Revision Control System): First release July 1985. Usually superseded by other systems such as CVS, which began as a wrapper on top of RCS.
CVS (centralized version control system): First release July 1986; based on RCS. Expands on RCS by adding support for repository-level change tracking, and a client-server model.
Apache Subversion (SVN): First release in 2004 by CVS developers with the goal of replacing CVS.
BitKeeper: Initial release May 2000. Distributed version control. Was shortly used for developing the Linux kernel. Proprietary. No longer maintained.
Git : Started by Linus Torvalds in April 2005, originally for developing the Linux kernel. Distributed version control. Open source.
…
Resume presentation
Introduction to Git – - Fall 2021 Lecture 1: Why use version control? Slides: https://hackmd.io/@hpc2n-git-2021/L1-motivation#/
{"metaMigratedAt":"2023-06-16T11:40:01.380Z","metaMigratedFrom":"YAML","title":"Lecture 1: Motivation","breaks":true,"description":"Why use version control?","contributors":"[{\"id\":\"70f80b64-a87f-47db-ba95-b3b587a1530d\",\"add\":9842,\"del\":136}]"}