1 of 52

Git training course

Git concepts with examples

chapter 01

chapter 01�chapter 02�chapter 03�chapter 04

Stefano Cilloni

Software Engineer

www,nyxgear.com

2 of 52

Agenda

What is git
Git concepts
Git vs CVS

�

Let's make it interactive!��Any questions is more than welcome during the presentation and…��remember that there are no dumb questions!

�“There are naive questions, tedious questions, ill-phrased questions, questions put after inadequate self-criticism. But every question is a cry to understand the world. There is no such thing as a dumb question.” ― Carl Sagan

3 of 52

What is git

4 of 52

What is git?

Git is a distributed version control system (or DVCS)
Started in 2005
Created by Linus Torvald to aid in Linux kernel development
Git goals

Speed
Simple design
Strong support for non-linear development (thousands of parallel branches)
Fully distributed
Able to handle large projects efficiently

Git concepts with examples

Stefano Cilloni

5 of 52

What is version control?

A system that keeps records of your changes
Allows for collaborative development
Allows you to know who made what changes and when
Each state of project is always recorded and never lost
Allows you to revert any changes and go back to a previous state

Git concepts with examples

Stefano Cilloni

6 of 52

So... what is git?

A tool which is

powerful
flexible
complete
complex (not complicated! …features-rich!!)�

A “time machine”�
An everyday tool

keep track of your work
saves you from bad situations
to also, sometime, mess-up your project

Git concepts with examples

Stefano Cilloni

7 of 52

What is git for

What git is NOT for

Track source code changes
Versioning of textual files
Handle software versions

Publish releases
Handle parallel versions

Manage modular projects

modules inclusion

Store large binary files

executables, images, PDFs, .docx, .xlsx, etc.

Automatically sync folders
General purpose backups

Git concepts with examples

Stefano Cilloni

8 of 52

CLI vs GUI

We will see and use Git mainly from CLI
Why? �CLIs have many advantages

They are standard! �GUIs differ in functioning and visualization and have the tendency to change over time..
Work the same over SSH �very easy to work on remote machines with git (seen later)
Much better control and feel of what is going on
No “magical” yet hidden commands run under the hood on your behalf�

but... GUIs are good for:

Merges and Diffs

We will see Meld Merge tool.��Also, VS Code version control feature is very good!

Git concepts with examples

Stefano Cilloni

9 of 52

Git from CLI

Does not change over time → learn it once
Execute any git command. GUIs are far from complete.
Very effective and fast interaction
Fine-grained control on performed actions

Git concepts with examples

Stefano Cilloni

10 of 52

Git concepts

11 of 52

Why concepts?

To properly use a tool → understand how it works
Theory is boring… but also important for good understanding

And.. then expand the skills with experience
Commands are just syntax to express what you want to do…

Very first thing: know the what and how it works.�

We won’t see just theory! → This course is full of practical examples!

Git concepts with examples

Stefano Cilloni

12 of 52

Git concepts

Git Repository
The Three States
Snapshots, Not Differences
Git Generally Only Adds Data
Git Has Integrity

Nearly Every Operation Is Local
Git Is Distributed
The Commits Graph
Git References

Git concepts with examples

Stefano Cilloni

Git terms in following slides are orange

13 of 52

Git repository or “repo”

It is the project directory

Collection of all project files + git database
Git database → a single folder, named “.git”, in the root of the repository
It’s local → lives on your computer (but copies can be on remote servers)
The cloning operation is the action of copying a repository from a remote server
Cloning is the first action you usually do to work on an existing project

Git concepts with examples

Stefano Cilloni

$ tree -a git_repository

git_repository� ├─ .git� ├─ README� └─ src� └─ main.c�

14 of 52

Practice Lab — init and clone

# initialize a new git repository

mkdir /tmp/alice-repo

cd /tmp/alice-repo

git init

# -------------- or ------------------�# clone an existing remote repository

�git clone <git-remote-address> /tmp/alice-repo��cd /tmp/alice-repo

cd /tmp/alice-repo�

# git needs your name and email for commits metadata��git config --global user.name "My Name"�git config --global user.email "email@example.com"��

# ask git about the repository status

git status

Git concepts with examples

Stefano Cilloni

practice lab #1

Here is the final result of “alice repo”:�https://gitlab.com/nyxgear/alice-repo

15 of 52

The Three States

Git concepts

This is the main concept to remember about git
In a git project, files have always on of 3 states

Git concepts with examples

Stefano Cilloni

modified

staged

committed

You have modified the file.�

(Not marked for commit, yet)

(Not committed into the git database)

A modified file is marked to go into your next commit / save.

Committed means that the data is safely stored in your local git database.

16 of 52

That leads to… 3 “sections” of a Git repository

Git concepts

Git concepts with examples

Stefano Cilloni

The working tree or working directory is one version of the project and it is made by all the files you work on.��Git gets these files from its database (the .git folder) and places them on disk for you to use.

The staging area is a “zone”/”state” that stores information about what will go into your next commit.

Called “staging area” or “index”.

The .git directory is the database Git uses to store history and all information about the project.�It is copied when you clone the repository from another computer or it gets created on the initialization of a repository.

17 of 52

A basic git workflow

You modify files in your working tree.
You selectively stage just those files you want to be part of your next commit. �This adds the files you select to the staging area and prepare them to be committed.
You do a commit.�This takes the files in the staging area and stores a snapshot permanently in the .git directory.

Git concepts with examples

Stefano Cilloni

modify

selectively stage

commit

18 of 52

Practice Lab — committing

# NOTE. Setup is from practice lab #1�cd /tmp/alice-repo��# create a new file�echo 'Hello git!' > hello.txt��# git, is there something new?�git status

# add the file to the staging area�git add hello.txt

# commit�git commit -m 'My first commit in git'�

�# check status again�git status

# check log to see commits history�git log

Git concepts with examples

Stefano Cilloni

http://hilite.me/

practice lab #2

19 of 52

Recap: The Three States

A particular version of a file stored in the .git directory.

File that was modified and added to the staging area.

File that was changed since the last time it was checked out but has not been staged.

Git concepts with examples

Stefano Cilloni

modified file

staged file

committed file

20 of 52

Snapshots, not differences

Git concepts

One of the major differences with respect to other VCSs (e.g. CVS)
Other VCS store information as a set of files and changes made to each file over time (called: delta-based version control).

Git concepts with examples

Stefano Cilloni

Differences of File A (from v2) included in version 4

Delta differences that makes �version 5

21 of 52

Snapshots, not differences

git data management → series of snapshots called commits
Each commit save the entire state of your project

Like if it takes a picture of what all your files look like at some moment

Files not changed → are not copies, but links to previous-snapshots files
git data model → stream of snapshots

Git concepts with examples

Stefano Cilloni

Link to file A: version 2

Snapshot of file A

(because changed in version 4)

Snapshot that makes version 5

snapshots commits

are

22 of 52

Snapshots, not differences: comparison

Git concepts with examples

Stefano Cilloni

Link to file A: version 2

Snapshot of file A

(because changed in version 4)

Snapshot that makes version 5

Delta differences that makes version 5

Differences of File A (from v2) included in version 4

Other VCSs

git

23 of 52

Snapshots, not differences: summary

This is an important distinction between Git and all other VCSs.�
By this approach Git is more like a mini filesystem �with very powerful features, �rather than simply a VCS.

Git concepts with examples

Stefano Cilloni

24 of 52

Git Only Adds Data

Git concepts

Nearly each action you do in Git add data to its database

Information removal → “sum to zero” of negative changes
Very bad idea → store big files and then delete them: the git database will only increase!!

It is hard to force git to

Perform undoable actions (you almost always can revert)
Actually erase data

You can lose changes you have not committed yet
Once committed → freedom of experiment

Git concepts with examples

Stefano Cilloni

25 of 52

Git Has Integrity

Git concepts

Every commit is

Checksummed
Atomic

Hashes / checksums useful

To store information preserving its integrity
As unambiguous reference

You cannot lose information in transit or get file corruption

Checksums allow git to detect and recover bad situations

You will see these hash values often

Git concepts with examples

Stefano Cilloni

26 of 52

Practice Lab — inspect content of commit

# NOTE. Setup is from practice lab #2��cd /tmp/alice-repo��# check project history�git log

�# copy the checksum for commit with title�'My first commit in git'

�# inspect changes within that commit�git show <your-checksum>��

# Now, let’s add new changes and then let’s see how git stores them��echo 'This change deletes previous content' > hello.txt

echo 'Here is another file' > foo.txt��# add all modified files to staging area�git add --all # or: git add .

# commit�git commit -m 'My second commit'

# check log showing modified files�git log --stat��# check log showing single changes in commits �git log --patch

Git concepts with examples

Stefano Cilloni

practice lab #3

27 of 52

Every Operation Is Local

Git concepts

Git only need local resources to work

generally, no other information from network is needed

This means...

no network latency
Or... no network at all! Work offline as online → upload changes when back online
entire history of the project stored on local disk
most operations → instantaneous

(to check project history → it checks local index. Same for changes of 1 month ago)

Only fetch and send changes require the be connected

No workaround to work offline: it’s by design

Git concepts with examples

Stefano Cilloni

28 of 52

Git is distributed

Git concepts

Centralized vs Distributed
No repository is “main” or “central”
Each copy

Is equivalent to the others
Stores all project history
Can work independently

Git refers to repository copies as remotes

Git concepts with examples

Stefano Cilloni

29 of 52

Practice Lab — remotes

# NOTE. Setup is from practice lab #3

# create another local repository�mkdir /tmp/bob-repo

cd /tmp/bob-repo

# initialize it�git init��# --- required setup ----�git config receive.denyCurrentBranch updateInstead�# -----------------------

# link the two repositories to synchronize them

cd /tmp/alice-repo

# add reference to the other repository copy �git remote add remote-bob-copy ../bob-repo��# see remotes �git remote -v

�# send/push stored commits of master to remote�git push remote-bob-copy master��cd /tmp/bob-repo && ls�

# check project history in bob’s repository copy�git log

Git concepts with examples

Stefano Cilloni

practice lab #4

For this lab, you can work offline!

30 of 52

The Commits Graph

Git concepts

Git organizes commits in a graph

Git concepts with examples

Stefano Cilloni

branch operation

merge operation

Examples of some project graphs!

31 of 52

Each commit is made of

Metadata

Author and commiter
Date and time
A description: the commit message �

Information about how the files changed from previously�
The parent commit checksum

Reference(s) to previous commit
“Pointer” to ancestor commit(s)

Git concepts with examples

Stefano Cilloni

32 of 52

Do you remember the working directory?

Commits graph

Is the entire history of changes occurred in the project�

Working directory

think to it as a “window” through which you see one specific state in time � of your project ��Indeed, Git is a “time machine”! ��The git checkout command “moves this window”/your working directory through the project history, visualizing the state of the project you pick

Git concepts with examples

Stefano Cilloni

33 of 52

Git References

Git concepts

Git Reference: concept equivalent to pointers (programming)�
Handy and useful
Easy to remember
4 kinds
They have different objectives

HEAD

branches

34 of 52

Git References — HEAD

It always exists and there is always only one HEAD for each repository�(better: one for each remote! )�
It is a pointer to the commit/branch you currently see “checked out” in the working directory

Working directory is the “window to see a specific state in time”�

Goal → remind you, in the git log, of where you are in project history�
You can move the HEAD with git checkout/switch commands

Git concepts with examples

Stefano Cilloni

35 of 52

HEAD in the commit graph

Git concepts with examples

Stefano Cilloni

HEAD

$ tree -a git_repository

git_repository� ├─ .git� ├─ README� ├─ src� │ ├─ function_X.c� │ ├─ function_Y.c� │ ├─ function_Z.c� │ └─ main.c� └─ VERSION

HEAD

$ tree -a git_repository

git_repository� ├─ .git� ├─ README� └─ src� ├─ function_X.c� ├─ feature_RED� │ ├─ module_A.c� │ ├─ module_B.c� │ ├─ module_C.c� │ └─ feature_red.c� └─ main.c�

HEAD

$ tree -a git_repository

git_repository� ├─ .git� └─ README

HEAD

$ tree -a git_repository

git_repository� ├─ .git� ├─ README� └─ src� ├─ function_X.c� ├─ feature_RED� │ ├─ module_A.c� │ └─ feature_red.c� └─ main.c�

36 of 52

Git References — branches

Branches mark with a name a sequence of commits in the commit graph
Multiple branches are allowed, and encouraged to use!
Objectives

Be a human friendly reference (instead of checksums) to move around in the commit graph
Have their name stating the objective of their commit sequence

They automatically move ahead when new commits are created

always point to latest commit of the branch

By convention, a git project has one principal branch → main / master

Technically, a git branch as any other

Git concepts with examples

Stefano Cilloni

37 of 52

Branches in the commit graph

Git concepts with examples

Stefano Cilloni

feature-export-to-pdf

HEAD should always �point to a branch or tag��If not, so pointing directly to a commit, �git warns you:� “You are in 'detached HEAD' state.”

HEAD

main

new-release-0.3.1

refactor-library-inclusion

38 of 52

Practice Lab — intro to branches

# NOTE. Setup is from practice lab #4

cd /tmp/alice-repo

# check where the HEAD is currently pointing at�git log

#------------------------�# create a new branch�git checkout -b another-branch

# check where the HEAD is currently pointing at�git log

# make changes and make a new commit�echo "coffee" > bar.txt�git add .�git commit -m "commit on other branch"��git log # see HEAD position��# see branches�git branch -v�

#------------------------�# switch back to master / main branch�git checkout master

ls # the file bar.txt should not be present

git log # see HEAD position��#------------------------�# make changes and make a new commit�echo "with more changes" >> foo.txt�git add .�git commit -m "3rd commit on master"

# notice the graph, branches and HEAD�git log --all --graph��# copy commit hash for “My first git commit”

git checkout <copied-hash>

# git should warn you��# go back to the branch another-branch�git checkout another-branch

Git concepts with examples

Stefano Cilloni

practice lab #5

39 of 52

Git References — tags

They mark a specific commit that is considered relevant for the project (e.g. a project version, a particular point in time)
Multiple tags are allowed and usually used
Objectives

Highlight with a human friendly name (the tagname) a commit
Simplify the checkout of a specific project state

Unlike branches, tags are not meant to move!

Neither manually, nor automatically

There exist 2 types of tags → lightweight and annotated

Git concepts with examples

Stefano Cilloni

40 of 52

Tags in the commit graph

Git concepts with examples

Stefano Cilloni

feature-export-to-pdf

main

new-release-0.3.1

refactor-library-inclusion

v0.2.0

v0.1.0

v0.3.1

preview-export-pdf

HEAD

HEAD should always �point to a branch or tag

41 of 52

Practice Lab — tags

# NOTE. Setup is from practice lab #5

cd /tmp/alice-repo��# see current tags�git tag -n

git log --all

# copy commit hash for “My second commit”

git checkout <copied-hash>

# mark the current project state with a tag�git tag v0.1.0

# see current tags�git tag -n

#------------------------�# create another tag

# move back to see master�git checkout master

# mark the current checked out commit with a tag�git tag v0.2.0

# see current tags�git tag -n

�#------------------------�# move HEAD to desired tag�git checkout <tag-name>

Git concepts with examples

Stefano Cilloni

practice lab #6

42 of 52

Git References — remotes

Remotes are pointers to other repositories

Other repositories are usually on remote computers, but not necessarily they have to

Remotes goal → be a reference to the other project copies

so as to ease manual synchronization with them

Multiple remotes are possible (also towards different projects)

They can be added and removed as desired without affecting local repository

Send/“push” changes to a remote repository → git push origin master
Receive/“pull” changes from a remote repository → git pull origin master

Git concepts with examples

Stefano Cilloni

remote name

43 of 52

Distributed but… also “centralized”

Git concepts

By convention one of the remotes is considered “the main one”. �Its name, by convention, is “origin”�

Git concepts with examples

Stefano Cilloni

44 of 52

Practice Lab — push to remote repository

Create a new project on GitLab https://gitlab.com/projects/new and name it “alice-repo”
Once create, read the section “Push an existing folder”
But.. we already have a repository!

# NOTE. Setup is from practice lab #6

cd /tmp/alice-repo��# see current remotes �git remote -v

# add the GitLab remote -- you can get this link from the “clone” button in the project page�git remote add origin git@gitlab.com:<your-username>/alice-repo.git

# check remotes again�git remote -v

# push current project history to GitLab copy of the repository�git push origin master

Git concepts with examples

Stefano Cilloni

http://hilite.me/

practice lab #7

45 of 52

Git vs CVS

46 of 52

Git

CVS

Distributed

More flexible workflow (work on copies)
No overhead switching branches

Atomic operations

All operations are atomic�(commit, branching, push, pull, merge, etc..)
Either they succeed as whole or fail with no changes��

Storage method: entire project snapshot

Easy to revert to previous project state

Centralized

Client-server architecture
Switch branches → need to connect to server

No atomic operations

Commit and other operations, if interrupted in the middle → repository can be left in inconsistent state
You always work on the whole repository, not a copy�

Storage method: changes per file

Revert changes can be problematic in complicated situations

Git concepts with examples

Stefano Cilloni

Git vs. CVS

47 of 52

Git

CVS

Commit hashes

Each version of the project as a whole (each commit) has its unique name given by SHA-1 hash.��

Merge tracking: commit-before-merge

If while you were preparing to create a new commit (new revision) somebody created a new commit on the same branch and pushed to the central repository:�You first commit, so save your state in version control, then you merge the other developer’s changes. You can also ask the other developer to do the merge and resolve any conflicts themselves.

Revision IDs

In CVS changes are per files. The revision ID is depicted by version numbers (e.g. 1.4) and it reflects how many times a given file has been changed�

Merge tracking: merge-before-commit

If while you were preparing to create a new commit (new revision) somebody created a new commit on the same branch and pushed to the central repository:�CVS forces you to first update your working directory and resolve conflicts before allowing you to commit.

Git concepts with examples

Stefano Cilloni

Git vs. CVS

48 of 52

Git

CVS

Branching is easy

Git remembers by itself all required info for branching and merging. Merging branch is easy as to “git merge <branch-name>”... and it have to be since distributed development naturally leads to multiple branches or versions of the same branch!�

Amending commits: easy

In Git the act of “publishing” is separated from creating a commit. One can change (edit, rewrite) unpublished part of history without inconveniencing other users. (E.g. correct a typo in commit message or fix a bug in changes you commited.)�As simple as “ git commit --amend”

Branching is complex

You have to tag branches to have a name for a whole repository branch. �By yourself you have to manually track or tag merges and branching points, supply correct information for “cvs update -j” to merge branches, and it makes unnecessary hard to use branches.�

Amending commits: not possible

This is not possible in CVS (at least not without heavy hackery).

Git concepts with examples

Stefano Cilloni

Git vs. CVS

49 of 52

Why Migrate

Popularity and liveness of the project

CVS is old with no new release since 2008 (still maintained!?)
Git is actively maintained, continuously improving and adopted as an industry standard

Feature richness

Git provides more tools to work with (git bisect for one) which makes for a more productive workflow

Shorter learning curve

Around Git: big community and tons of good quality tutorials to get you started

Integration with modern tools

Git and GitLab enable the adoption of modern software development practices such as issue tracking, code reviews, CI/CD and more, to simplify and speed up development even though large projects with many developers