GIT training - basic for software projects

lundi 13 mars 2023
GIT TRAINING - Beginner
Thierry GAYET

❑ The purpose of this training will be to:
❑ better understand the differences of a GIT repo compared to those that
existed historically
❑ Basic GIT commands
❑ Understand their work philosophy
❑ To be able to be functional to work efficiently
Have a good training ☺
GOAL
2
scan me

PLAN ❑Introduction & history
❑Basic commands
❑ Git config
❑ Files & directories
❑ Commits
❑ Check the changes
❑ Remotes
❑ Branches
❑ Tags
❑ Merge of branches
❑ Fix merge conflicts
❑ Debugging
❑Several tips
❑Several graphical tools

What exactly is version control software ?
❑ As its name suggests, it is software that allows you to create and manage
the different versions of files. Version control software is mostly used in
software development to keep source code history and work more easily in a
team.
❑ A Version Control Software (aka VCS) is a software which makes it possible
to store a set of files by preserving the chronology of all the modifications
which have been made on it.
❑ To make a telling analogy, imagine that version control software is a tool
that takes photos of your source code at desired times, then it indicates on
the back of your photo the version number of the source code.
❑ Finally, he carefully stores this photo in a chronological binder in order to
easily find the source code of your project as it was at the requested version.
GIT / INTRO
5

❑ Before the arrival of version management tools, to make backups of the different versions of
its files, we had to copy and paste the complete folder (tarball) of the project and rename it
to add the mention of the version.
❑ The advantage is that it did not require the use of tools. On the other hand, it was very heavy
in terms of memory space and time (duplicate files).
❑ The other disadvantage is that it was very difficult to share these files with other people and
even more so to work in a team on the same files.
❑ Finally, with this method, there was no information (metadata) on the evolution of the files
between two versions. For example:
o The modification date
o The name of the person who made these changes
o Why did you make these changes?
o And more
❑ But all this information is very important, especially in the world of software development!
GIT / INTRO / BEFORE
6

❑ To remedy these problems, we started using databases to save the different
versions of the files.
❑ Thus, we could have a logic between the different versions of our files and we
could add, to our modifications, additional information via the database (date,
author, …)
GIT / INTRO / BEFORE
7
Without version management :
Projet’s folder Projet’s folder 2
copy ❑ Only in local
❑ No backup (remote)
❑ No metadata for the tracability (who, when)
❑ No history
❑ Not easy to use

Centralized version management :
❑ Nowadays there are two big family of version manager.
❑ The first to see the light of day: the so-called centralized management. We can cite for
example in free:
o CVS
o SVN
❑ Or as owner:
o Perforce
o synergy
❑ These tools are said to be centralized because the complete history is hosted on a
server.
❑ Developers who wish to work on the project can then retrieve a given version locally on
their PC or save a new version on the server.
GIT / INTRO / CENTRALIZED
8

❑ This centralized system further improves version management, by making it very easy to create or
retrieve a version in the history, by facilitating teamwork on the same project and by following the
project history more simply.
❑ But there is still a downside to the centralized system.
❑ Developers must necessarily have access to the server to make version registrations or to roll
back to an old version of the project.
❑ In addition, if the server loses the data, all the project history also disappears.
GIT / INTRO / CENTRALIZED
9
Centralized version management (cvs, svn, p4v, … ) :
PC #1
SERVER
PC #2
Version 3
Version 2
Version 1
❑ When the network is down,
there is no access to the server !
❑ If the server crash, the history is
lost !
Version 2
Version 1

❑ To remedy this last problem, decentralized or distributed management
was created.
❑ As you can imagine, this time, the history is no longer centralized on a
single machine.
GIT / INTRO/ DECENTRALIZED
10
PC #1
SERVER
PC #2
Version 3
Version 2
Version 1
Version 3
Version 2
Version 1
Version 3
Version 2
Version 1
❑ Each time a copy of the whole projet is done !
File.txt File.txt

❑ There can always be a reference server, but this time, each developer will duplicate the entire
history present on the server.
❑ Thus, if he needs to revert to an earlier version of the source code, he does not need to have
access to the remote server.
❑ Moreover, if he wishes to save new versions in his history, he can do it locally on his machine.
❑ Later, he can synchronize with the reference server to add his modifications and retrieve those
of the other members of his team.
❑ In these decentralized version management tools, we can mention Mercurial, Bazaar or the
most popular Git
❑ Nowadays, it is clearly essential to know how to use version management when working in the
software field. As we have seen, there are many. But if you had to choose just one, I'd
recommend Git instead.
❑ Git is one of the most popular decentralized version control software with 12,000,000 users
worldwide. It is free software created by Linus Torvalds, author of the Linux kernel. Git is
completely free.
GIT / INTRO/ DECENTRALIZED
11

VCS / HISTORY
12
And for once, the shoemaker is well shod...
Why and when ?
❑ Starting in 2002, the Linux community started using BitKeeper, a proprietary
source management system.
❑ In 2005, following a dispute, BitKeeper withdrew the possibility of using its product
free of charge.
❑ Linus Torvalds initiates development of Git. After a few months, Git hosts Linux
kernel development.

GIT / INTRO
13
What is Git based on?
❑ Speed
❑ Simplicity
❑ Be able to manage thousands of branches
❑ Implementation of non-linear development
❑ Be able to manage “big” projects
❑ Thousands of developers, recovery speed, data size
❑ Expandable with new commands
❑ More commands to enrich an already rich panel
❑ Allows for example to interface with other systems e.g. subversion

GIT / INTRO
15
What is a Git server ?
❑A Git server hosts an organized set of Git repositories :
/
net lib sys
apache.git tcp-
socket.git
libwww.git libconf.git kernel.git filesys.git
git://git.company.com/srv
ftp.git

GIT / INTRO
16
What is a Git repository ?
❑ A Git repository contains a set of files, structured directories that allows you to
save different versions.
/
net lib sys
apache.git tcp-
socket.git
libwww.git libconf.git kernel.git filesys.git
git://git.company.com/srv
ftp.git

GIT / INTRO
17
❑ By default, a local repository contains :
o All Changes
o All History
o All Branches
o All Tags
Remote repository
(dépôt distant)
Local repository
(dépôt local)
Local repository
(dépôt local)
Local repository
(dépôt local)
pull
push
push
push
Mickaël Kevin
git://git.company.com/srv/net/tcp-socket.git
Anna
pull
pull

GIT / INTRO
18
❑ We can work with other repositories
❑ Frederic and Kevin are working on a function where it is important to share between them
❑ Anna is working on the same repository but does not need this function
Remote repository
(dépôt distant)
Local repository
(dépôt local)
Local repository
(dépôt local)
Local repository
(dépôt local)
pull
push
pull
push
Mickaël Kevin
Anna
push
pull
pull
push

GIT / INTRO
19
❑ Benefits :
o Almost everything locally
o No server needed
o Saving…
o Quick recovery
❑ Disadvantages :
o Larger size
Remote repository
(dépôt distant)
Kevin
Other remote repository
(sauvegarde)

❑ WINDOWS :
❑ https://gitforwindows.org/
❑ WSL / Ubuntu 22.04 LTS (then see above GNU/Linux)
https://linuxconfig.org/ubuntu-22-04-on-wsl-windows-subsystem-for-linux
❑ MAC OS X :
❑ https://sourceforge.net/projects/git-osx-installer/files/git-2.23.0-intel-
universal-mavericks.dmg/download?use_mirror=autoselect
❑ (homebrew) brew install git + brew install git-gui
❑ (MacPort) sudo port install git
❑ Dmg : https://sourceforge.net/projects/git-osx-installer/
❑ GNU/LINUX :
❑ sudo apt-get install git-all gitg gitk git-man git-doc git-lfs git-gui git-flow git-svn
❑ dnf install git-all
GIT / INSTALL
21

❑ Install GIT on your system
❑ Check the version of git :
$ git --version
GIT / INSTALL
22

GIT / CONFIG
24
The config command :
❑ Alters how Git works
❑ Local / global configuration
❑ Global configuration saves in ~/.gitconfig of the user environment
❑ Local configuration saves in .git/config of the GIT repo
$ git config --global <key>
<value>
$ git config --local <key>
<value>
There are many keys to alter commands
.gitconfig
file .git/config
file

❑ Many Git commands will launch a text editor to prompt for further
input. One of the most common use cases for git config is configuring
which editor Git should use.
❑ Listed below is a table of popular editors and matching git config
commands:
GIT / CONFIG
25

❑ In the event of a merge conflict, Git will launch a "merge tool." By
default, Git uses an internal implementation of the common Unix diff
program.
❑ The internal Git diff is a minimal merge conflict viewer. There are
many external third party merge conflict resolutions that can be
used instead.
$ git config --global merge.tool kdiff3
GIT / CONFIG
26

GIT / CONFIG
27
Git is based on name/email :
$ git config --global user.name "John Doe"
$ git config --global user.email john.doe@enensys.com
$ git config --global color.ui auto
$ git config --global core.editor "nano"
On Linux systems, Git looks for the .gitconfig file in the
●
${HOME}/.gitconfig
${HOME}/.config/git/config
●
On Windows systems, Git looks for the .gitconfig file in the
●
$HOME directory (C:Users$USER for most people).
It also still looks for /etc/gitconfig, although it’s relative to the MSys
root, which is wherever you decide to install Git on your Windows
system when you run the installer.
If you are using version 2.x or later of Git for Windows, there is also a
system-level config file at C:Documents and SettingsAll Users
Application DataGitconfig on Windows XP, and in C:ProgramData
Gitconfig on Windows Vista and newer.
●
●
.gitconfig
file
[user]
email = john.doe@enensys.com
name = John Doe
[push]
default = simple
[core]
editor = nano
[color]
ui = auto

GIT / CONFIG
28
Possibilité de mettre en place des alias
– Des commandes maison adapté à votre travail
$ git config --global alias.co checkout
$ git config --global alias.ci commit
$ git config --global alias.br branch
$ git config --global alias.st status
$ git config --global alias.ls ‘log --oneline --decorate'
$ git config --global alias.lsa ‘log --oneline --decorate –-all’
$ git config --global alias.lsg ‘log --oneline --decorate --all –-graph’
$ git config --global alias.cached diff --cached
$ git config --global alias.viewer ‘!gitk’
...

❑This is possible to dump the user or global config :
$ git config --list
$ git config -l
filter.lfs.required=true
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
diff.renamelimit=15345
diff.tool=kdiff3
difftool.prompt=false
difftool.keepbackup=false
difftool.trustexitcode=false
difftool.kdiff3.path=/usr/bin/kdiff3
difftool.kdiff3.trustexitcode=false
merge.tool=kdiff3
mergetool.prompt=false
mergetool.keepbackup=false
mergetool.keeptemporaries=false
mergetool.kdiff3.path=/usr/bin/kdiff3
GIT / CONFIG
29
$ git config --global –list
diff.renamelimit=15345
diff.tool=kdiff3
difftool.prompt=false
difftool.keepbackup=false
difftool.trustexitcode=false
difftool.kdiff3.path=/usr/bin/kdiff3
difftool.kdiff3.trustexitcode=false
merge.tool=kdiff3
mergetool.prompt=false
mergetool.keepbackup=false
mergetool.keeptemporaries=false
mergetool.kdiff3.path=/usr/bin/kdiff3
mergetool.kdiff3.trustexitcode=false
user.name=John Doe
user.email=John.Doe@enensys.com
$ git config --list --show-origin
file:/etc/gitconfig filter.lfs.required=true
file:/etc/gitconfig filter.lfs.clean=git-lfs clean -- %f
file:/etc/gitconfig filter.lfs.smudge=git-lfs smudge -- %f
file:/etc/gitconfig filter.lfs.process=git-lfs filter-process
file:/home/ubuntu/.gitconfig diff.renamelimit=15345
file:/home/ubuntu/.gitconfig diff.tool=kdiff3
file:/home/ubuntu/.gitconfig difftool.prompt=false
file:/home/ubuntu/.gitconfig difftool.keepbackup=false
file:/home/ubuntu/.gitconfig difftool.trustexitcode=false
file:/home/ubuntu/.gitconfig difftool.kdiff3.path=/usr/bin/kdiff3
file:/home/ubuntu/.gitconfig difftool.kdiff3.trustexitcode=false
file:/home/ubuntu/.gitconfig merge.tool=kdiff3
file:/home/ubuntu/.gitconfig mergetool.prompt=false
file:/home/ubuntu/.gitconfig mergetool.keepbackup=false
file:/home/ubuntu/.gitconfig mergetool.keeptemporaries=false
file:/home/ubuntu/.gitconfig mergetool.kdiff3.path=/usr/bin/kdiff3

❑ System level (applied to every user on the system and all their
repositories)
o to view, git config --list --system (may need sudo)
o to set, git config --system color.ui true
o to edit system config file, git config --edit –system
❑ Global level (values specific personally to you, the user)
o to view, git config --list --global
o to set, git config --global user.name xyz
o to edit global config file, git config --edit --global
GIT / CONFIG
30

❑ Repository level (specific to that single repository)
o to view, git config --list --local
o to set, git config --local core.ignorecase true (--local optional)
o to edit repository config file, git config --edit --local (--local optional)
❑ How do I view all settings?
o Run git config --list, showing system, global, and (if inside a repository)
local configs
o Run git config --list --show-origin, also shows the origin file of each config
item
o Run git config --list –show-scope, show the scope of each config item
❑ How do I read one particular configuration?
o Run git config user.name to get user.name, for example.
o You may also specify options --system, --global, --local to read that value
at a particular level.
GIT / CONFIG
31

[diff]
renamelimit = 15345
tool = kdiff3
[difftool]
prompt = false
keepBackup = false
trustExitCode = false
[difftool "kdiff3"]
path = /usr/bin/kdiff3
[merge]
tool = kdiff3
[mergetool]
prompt = false
keepBackup = false
keepTemporaries = false
GIT / CONFIG
32
[mergetool "kdiff3"]
path = /usr/bin/kdiff3
[user]
name = John Doe
email = john.doe@enensys.com
[filter "lfs"]
smudge = git-lfs smudge -- %f
process = git-lfs filter-process
required = true
clean = git-lfs clean -- %f
❑ Example of useful config :
1/2 2/2

❑ Git alias used to extend the command line :
o To better understand the value of Git aliases we must first discuss what an alias is.
o The term alias is synonymous with a shortcut.
$ git config --global alias.ci commit (instead of “git commit”, we will use “git ci”)
$ git config --global alias.unstage 'reset HEAD --’
o It will create a new config (the git’s config file can be shared between teams) :
[alias]
co = checkout
br = branch
ci = commit
st = status
o Example of use :
$ git unstage fileA (will do : git reset HEAD – fileA)
GIT / CONFIG
33

GIT / CONFIG
34
In summary :
Configuring your environment :
$ git config --global user.name "John Doe"
$ git config --global user.email John.doe@company.com
$ git config --global <key> <value>
$ git config --local <key> <value>
Create new commands :
$ git alias alias_name=command

❑ Check your initial configuation
❑ Declare your user with git config
❑ Configure your environment using git
config
❑ Create a set of usual alias
❑ View the obtained configuration
GIT / CONFIG
35

Basic commands
Initialisation d’un repo git
36

GIT / INIT
37
Deux types de dépôts existent
– Le dépôt nu (bare
repository)
●
Il ne contient pas de répertoire de travail
Par convention, il sont suffixés par <name>.git
●
– Le dépôt de travail (local repository)
●
Il contient les fichiers de travail et un répertoire .git
Pour un répertoire de travail, généralement pas de suffixe .git
Le répertoire .git se trouve toujours à la racine du répertoire
●
●
Quel que soit le type de dépôt, les structures .git sont identiques
project project.git
.git

GIT / INIT
38
Initialiser un nouveau dépôt
Création d’un dépôt de travail :
$ git init (.git dans le répertoire courant)
$ git init <directory> (.git dans <directory>)
Structure du
dépôt git
$ git init --bare
$ git init --bare <directory>
Création d’un dépôt nu :

GIT / INIT
39
Récupérer un projet existant depuis une source
$ git clone <url> (nom du répertoire à partir de <url>)
$ git clone <url> <directory> (.git dans le répertoire <directory>)

GIT / INIT
40
In summary :
Initializing/Reinitializing an empty working repository :
$ git init (.git in current directory)
$ git init <directory> (.git in directory <directory>)
Initialization/Reinitialization of an empty bare repository :
$ git init --bare (git structure in current directory)
$ git init <directory> (git structure in <directory> directory)

GIT / INIT
41
In summary :
Recover an existing project :
With non-bare, you will get all of the tags copied, a local branch master (HEAD) tracking a remote branch origin/master, and remote branches
origin/next, origin/pu, and origin/maint. The tracking branches are set up so that if you do something like git fetch origin, they'll be fetched as
you expect. Any remote branches (in the cloned remote) and other refs are completely ignored :
$ git clone <origin-url> (directory name from <url>)
$ git clone <origin-url> <directory> (.git in <directory> directory)
You will get all of the tags copied, local branches master (HEAD), next, pu, and maint, no remote tracking branches. That is, all branches are
copied as is, and it's set up completely independent, with no expectation of fetching again. Any remote branches (in the cloned remote) and
other refs are completely ignored :
$ git clone --bare <origin-url> <directory>
Every last one of those refs will be copied as-is. You'll get all the tags, local branches master (HEAD), next, pu, and maint, remote branches
devA/master and devB/master, other refs refs/foo/bar and refs/foo/baz. Everything is exactly as it was in the cloned remote. Remote tracking is
set up so that if you run git remote update all refs will be overwritten from origin, as if you'd just deleted the mirror and recloned it. As the docs
originally said, it's a mirror. It's supposed to be a functionally identical copy, interchangeable with the original :
$ git clone --mirror <origin-url> <directory> (prefered to git clone --bare)
Nb : by default, git uses a protocol with TCP and port = 9418. It can also run over ssh, http(s):// or even local (file:///...)

❑ Create a directory and initialize a GIT
repo inside ; this can be useful for local
configuration management
❑ Create a server-like GIT repository
without a local working repository
❑ Clone your GIT repo as local file
GIT / INIT
42

GIT / NOTATIONS
44
Les références sont :
– Absolues – Elle correspondent au SHA-1
Également, les branches, tags, etc.
dae86e1950b1277e545cee180551750029cfe735, dae86e
– Relative – Référence relative à une autre référence
• Références « premier parent de » avec l’opérateur ~
• Références « parent de merge commit » avec l’opérateur ^
https://git-scm.com/docs/gitrevisions?ref=blog.git-init.com

GIT / NOTATIONS
45
L’opérateur de références relative ~
❑ L’opérateur ~ signifie « premier parent de »
❑ Par cumul, ~~ signifie « premier grand-parent de »
❑ Pour éviter le cumul des ~, on peut utiliser ~<n>
n correspond a nombre de tilde. ~~~ équivaut à ~3
C0 C1 C2 C19 C20 C22 C24
*testing
master
C31
C21 C23 C25 C26
C32 C33
Mais <REF>^n <> <REF>~n C31~3 = C20
La référence C32~
C31~
C32~~
C31~2
= C31
= C24
= C22
= C22
A noter que <REF>^ ==
<REF>~
<REF>^^ == <REF>~~

GIT / NOTATIONS
46
L’opérateur de références relative ^
–
–
– ^ signifie « premier parent d’un merge commit »
^^ signifie « premier grand-parent d’un merge commit»
^n signifie « n-iéme parent d’un merge commit»
C0 C1 C2 C19 C20 C22 C24
*testing
master
C31
C21 C23 C25 C26
C32 C33

GIT / NOTATIONS
47
Les intervalles de commit sont un autre type
d’opérateur
–
– L’opérateur .. filtre une branche par rapport à une
autre L’opérateur ... est une forme de XOR de
branche
Généralement utilisé avec les commandes de log /
diff
C0 C1 C2 C19 C20 C22 C24
testing
master
C31
C21 C22 C24 C26
experiment

GIT / NOTATIONS
48
L’opérateur de filtrage
<branch1>..<branch2>
–
– Indique les commits qui sont dans la branche branch2
Mais qui ne sont pas dans la branche branch1
C0 C1 C2 C19 C20 C22 C24
testing
master
C21 C22 C24 C26
experiment

GIT / NOTATIONS
49
L’opérateur de filtrage
<branch1>...<branch2>
–
– Indique les commits qui sont dans l’une ou
l’autre Mais qui ne sont pas dans les deux
C0 C1 C2 C19 C20 C22 C24
testing
master
C21 C22 C24 C26
experiment

Basic commands
Files and directories
54

GIT / FILES
55
Snapshots, not differences
Unlike other systems, it does not work by delta

GIT / FILES
56
A stream of snapshots
Finally, the versions are a series of snapshots

GIT / FILES
57
❑ Git is able to :
o Manage all file of files, directories, special files, links, binaries or text
o It handles files almost automatically – file type detection
o Manage the notion of user rights (UNIX) Not suitable for managing binary files
(rwx-rwx-rwx)
o Automatic comparison does not work. Solutions for certain files exist, but remain
marginal. Overwrite system.
o For large files, a Large File Storage (aka LFS) extension exists!

GIT / FILES
58
A file is associated with different states :
The file is not tracked by Git
The file is tracked by Git(a
(was previously added to the repository)
The file has been modified
The file has been selected for a commit
The file was written in a commit
The Three States
of Git
Untracked
Tracked
Modified
Staged
Commit

GIT / FILES
59
Examine the changes of the different zones :
$ git status
Staging area
Modified area
Untracked area
By default, we are
associated with a
master or main
branch

GIT / FILES
60
❑ Different areas:
o Staging area contains the changes that
will be written in the next commit
o Modified area contains changes that
are not written into the next commit
o Tracked area contains files known to
the repository
o Untracked area represents files
present locally but not present in the
repository
Untracked
idea.c
Modified
README.md
6
README.md
README.md
main.c
main.c → demo1.c
config.c
bad-idea.c
Staging
config.c
bad-idea.c
Tracked
Commit

GIT / FILES
61
The added / modified file is
directly placed in the
staging area
The renamed file is
directly placed in the
staging area
The deleted file is
directly placed in
the staging area
Tracked
Staging
Modified
tracked.c
Untracked
untracked.c
untracked.c tracked.c
git add
Untracked
Tracked
Mo
dified
Staging
old-name.c → new-name.c
old-name.c
old-name.c
new-name.c
git mv git rm
Untracked
Staging
removed.c
Tracked
removed.c
Modified
removed.c

GIT / FILES
62
$ git add <modified-file>...
$ git add <untracked-file>...
$ git stage <file>...
$ git mv <old> <new>
$ mv <old> <new> ; git add <old> ; git add <new>
$ cp <old> <new> ; git rm <old> ; git add <new>
$ git rm <removed>
$ rm <removed> ; git add <removed>
❑ Add / Rename / Delete

GIT / FILES
63
The file is put
back in the
modified area
The file is put
back in the
tracked area
We therefore
return to an
initial state
Untracked
Tracked
Modified
Staging
demo.c
git reset git checkout
Untracked
Tracked
Modified
Staging
demo.c
demo.c
demo.c
demo.c
Les modifications sont
perdues définitivement !

GIT / FILES
64
$ git reset (tous les changements mis en transit)
$ git reset [<file>...] (changements spécifiques)
❑Discard intended changes for a commit :
git-reset - Reset current HEAD to the specified state
This is useful to undo a git add

GIT / FILES
65
$ git reset [HEAD] [<file>]
$ git reset -p [HEAD] [<file>]
❑As a reminder, the reset command allows you to pass files from INDEX
area (staging) → HEAD (modified)
C0 C1 C2 C19 C20 C22 C24
master
*testing HEAD
C31
origin/master
INDEX
C30
C29
git-reset - Reset current HEAD to the specified state
This is useful to undo a git add

GIT / FILES
66
❑The reset --soft command allows to move HEAD on a given reference
Keeps the modifications of the deleted commits
$ git reset –-soft HEAD~2
$ git reset –-soft C24
C0 C1 C2 C19 C20 C22 C24
*testing HEAD
C31 INDEX
C30
C29
C0 C1 C2 C19 C20 C22 C24
*testing HEAD
master
origin/master
INDEX
C30
C31 C29
--soft
Does not touch the index file or the working tree at all (but resets the head to <commit>, just like all modes do). This
leaves all your changed files "Changes to be committed", as git status would put it.
This is usefull to undo a commit.

GIT / FILES
67
The reset --hard command allows
❑ To move HEAD on a given reference
❑ Deletes all modifications (including INDEX)
$ git reset –-hard HEAD~2
$ git reset –-hard C24
C0 C1 C2 C19 C20 C22 C24
*testing HEAD
C31
master
origin/master
INDEX
C30
C29
C0 C1 C2 C19 C20 C22 C24
*testing HEAD
master
origin/master
INDEX
--hard
Resets the index and working tree. Any changes to tracked files in the working tree since <commit> are discarded.
Any untracked files or directories in the way of writing any tracked files are simply deleted.

GIT / FILES
68
$ git checkout [--] <file>...
Changes are permanently lost !
❑Revert to previous state (no changes) :
Utilisez la commande ci-dessous pour annuler les modifications apportées
à un fichier !

GIT / FILES
69
QUIZ :
❑ How to add idea.c?
❑ What happens if git checkout README.md?
❑ How to undelete bad-idea.c?
❑ What if git add config.c ?
❑ What happens if git checkout bad-idea.c?
❑ What happens if git reset config.c?
❑ How to revert to the initial state for main.c?
Untracked
idea.c
Modified
README.md
README.md
README.md
main.c
main.c → demo1.c
config.c
bad-idea.c
Staging
config.c
bad-idea.c
Tracked

GIT / COMMIT
71
C’est le moment d’effectuer un commit !
–
–
– Enregistrer dans le dépôt local des
changements
(tous les fichiers qui se situent dans la staging area)
Associer un message pour le commit
Un message ne peut être vide (git refuse explicitement)
Un commit génère une référence SHA-1
README.md
Staging
hello.c
Makefile
Commit

GIT / COMMIT
72
Les SHA-1 représente une référence absolue unique
– Forme complète – Suite hexadécimale de 40 caractères
Exemple : 24b9da6552252987aa493b52f8696cd6d3b00373
– Forme simplifié – Forme courte
Exemple : 24b9da6552252987aa493b52f8696cd6d3b00373
– Pour un commit, clé de hashage qui tient compte
● Nom de l’auteur
Mail de l’auteur
Horodatage
Du contenu du commit
●
●
●
Github
« Deux objets qui se heurtent accidentellement sont
extrêmement improbables. Si vous aviez cinq
millions de programmeurs générant chacun un
commit par seconde, vos chances de générer une
seule collision accidentelle, avant que le Soleil ne
devienne un géant rouge et n’englobe la Terre, sont
d’environ 50%. Soit une probabilité plutôt faible. »

GIT / COMMIT
73
Effectuer un commit
$ git commit (ouvre l’éditeur)
$ git commit -m ‘message’ (sans editeur)
$ git config --global core.editor ‘nano’

GIT / COMMIT
74
Quelques conseils sur les commits
Première ligne - Commentaire synthétique assez court
(suivi d’un saut de ligne)
Autres lignes - Commentaires détaillés

GIT / COMMIT
75
Révision d’un commit
– On peut revenir sur le dernier commit
– Refaire le message ou ajouter de nouvelles modifications
Toujours une bonne idée de pouvoir modifier son dernier commit pour corriger une faute de frappe,
supprimer une trace de debug ou simplement décider de reformuler correctement et de façon plus
détaillée.

❑ To keep the meaning of a commit
o Reuse the same message
o Prefix !fixup the same message
o Prefixing !squash to the same message
GIT / COMMIT
76
$ git commit -c <commit>
--reedit-message=<commit>
Like -C, but with -c the editor is invoked, so that the user can further edit the commit message.
$ git commit -C <commit>
--reuse-message=<commit>
Take an existing commit object, and reuse the log message and the authorship information (including the timestamp) when
creating the commit.
$ git commit --fixup=<commit>
$ git commit --squash=<commit>

GIT / COMMIT
77
Après un commit, un retour en arrière est possible
– Commande git revert qui inverse la différence
$ git revert <reference>...

GIT / COMMIT
78
Possibilité d’ignorer des fichiers avec .gitignore
Un seul fichier installé à la racine du dépôt – doit être dans un commit comme tout fichier
Il possède des règles permettant d’ignorer facilement des fichiers
Modèle Exemple Explication
*.log debug.log, foo.log, .log Identique à un système de fichier (* = tout)
debug.log debug.log, logs/debug.log Tous les fichiers (dans tous les répertoires)
/debug.log debug.log Fichier à la racine
**/logs logs/debug.logs, logs/monday/foo.bar Tous les répertoires partout dans le dépôt
*.log
!important.log
debug.log, trace.log, mais pas important.log, logs/important.log Préfixe pour invalider un fichier
debug[01].log debug0.log, debug1.log mais pas debug2.log Utilisation d’un caractère unique
debug[0-9].log debug0.log … debug9.log mais pas debug10.log Spécification d’un ensemble
debug[!01].log debug2.log … debug9.log mais pas debug0.log,
debug1.log, debug01.log
N’importe quel caractère sauf...
logs/ logs/debug.log, logs/latest/foo.test / indique un répertoire. Tous les fichiers/sous-
répertoires sont ignorés.
logs/**/debug.log logs/debug.log, logs/monday/debug.log, logs/tuesday/debug.log Ignore zéro répertoires ou plus
# Commentaires # pour traiter un caractère #
• https://git-scm.com/docs/gitignore
• https://www.toptal.com/developers/gitignore

GIT / COMMIT
79
En résumé
Effectuer des changements pour le prochain
commit (staging area)
$ git add <file>
$ git mv <old-file> <new-file>
$ git rm <removed>
Revenir en arrière (staging area → modified area
/ untracked area)
$ git reset <file>
$ git reset
Revenir à l’état initial (modified area →
untracked / tracked area)
$ git checkout [–-] <file>
Effectuer un commit (staging area → commit)
$ git commit
$ git commit -m ‘message’
Revenir en arrière sur un commit
$ git revert <reference>
Ignorer des fichiers avec .gitignore

BASIC COMMANDS
Check the changes
80

GIT / CHANGEMENTS
81
Pour consulter les changements avant un commit
– La commande diff permet de voir les différentes zones
Pour consulter l’historique des changements
– La commande show permet de voir un commit
Sans argument, le dernier commit uniquement
– La commande log est la plus communément utilisé
Elle possède de nombreuses options
– La commande diff fait une différence entre commits

GIT / CHANGEMENTS
82
Consulter les différences de modified area
config
$ git diff

GIT / CHANGEMENTS
83
Consulter les différences de staging area
config
$ git diff --staged
$ git diff --cached (equivalent)

GIT / CHANGEMENTS
84
Consulter les logs
Référence
SHA-1
$ git log
Information du commit
●
Auteur & Date
Description
●
$ git log --stat
●
Auteur & Date
Description
Modif. fichiers
●
●

GIT / CHANGEMENTS
85
Voir le dernier
commit
config
$ git show (dernier commit)
$ git log -p -1 (eq. git show)
$ git show <commit> (commit particulier)
●
Référence SHA-1
Branches
Auteur & Date
Description
●
●
●
Contenu du commit
(patch)

GIT / CHANGEMENTS
86
Consulter les logs – Sur une seule ligne
$ git log --oneline
Référence
SHA-1
Commentaire
synthétique

GIT CHANGEMENTS
87
Consulter les différences
$ git diff <commit> (depuis la référence locale)
$ git diff <commit> <commit> (entre deux références)

GIT / CHANGEMENTS
88
En résumé
Voir les changements dans les zones
$ git diff (modified area)
$ git diff --staged (staging area)
$ git diff --cached (staging area)
Voir le dernier changement (dernier
commit)
$ git show
$ git show <commit>
Consulter les logs
$ git log
$ git log -p -<n>
$ git log --oneline
$ git log --stat
Différences entre différentes références
$ git diff <commit> [<commit>]

GIT / CHANGEMENTS
89
Faire de nombreux commits
–
–
–
– Souvent et le plus tôt possible pour un
fichier
Dès qu’il est entré, les risques de pertes deviennent moins
importants
Un bon commit est un commit atomique
Permet de mieux séparer les idées, les
fonctionnalités Il est le plus petit possible, en restant
cohérent
On peut mieux manipuler les commits
revert, cherry-pick, rebase sont plus facile à utiliser
Simplifie la recherche de bug (dichotomie)
Dans Git, possible grâce à la manipulation de
l’historique

GIT / CHANGEMENTS
90
La notion de patch (commande -p, --patch)
– De nombreuses commandes fonctionnent par patch
– On effectue une sélection (au lieu d’une sélection totale)
Opération Quoi ?
git add Ajout partiel (un/plusieurs fichiers)
git checkout Revenir partiellement à l’état initial (un/plusieurs fichiers)
git reset Abandon des changements d’un commit (un/plusieurs fichiers)
git stash Mettre en réserve partiellement (un/plusieurs fichiers)
git commit Commit partiel (un/plusieurs fichiers)
Le sens des opérations est parfois
trompeur, notamment pour checkout

GIT / CHANGEMENTS
91
Exemple d’ajout partiel :
$ git add -p
--patch
Interactively choose hunks of patch between the index and the work tree and add
them to the index.
This gives the user a chance to review the difference before adding modified
contents to the index.
Y =
Yes N
= No
Q = Quit
A = Yes,
All D =
No, All E
= Edit
S = Split

GIT / REMOTE
93
Un dépôt distant (remote repository)
– Peut être situé sur un serveur distant
●
Accessible par un serveur SSH
● Accessible par un serveur GIT
Accessible par HTTP / HTTPS
●
– Mais il peut être également...
● Sur un disque local (FILE)
Sur un disque réseau (FILE)
●
Les dépôts sont accessibles grâce à la commande remote
Remote repository
(dépôt distant)
Kevin
Remote repository
(dépôt local ou distant)
SSH
GIT
HTTP
FILE

GIT / REMOTE
94
Un dépôt distant (remote repository) possède
– Une URL vers le site distant (ou local)
Généralement, un dépôt distant possède une extension .git
git://git.enensys.com/srv/net/tcp-socket.git
– Un nom logique (nom
court)
Le nom logique est utilisé pour
référencer les branches, tags, etc.
du dépôt distant
Par défaut, on désigne origin dont
provient le dépôt local (notamment
pour la commande clone)
Remote repository
(dépôt distant)
Kevin
Remote repository
(dépôt local ou distant)
SSH
GIT
HTTP
FILE

GIT / REMOTE
95
Ajouter / Consulter / Supprimer des dépôts distants
Nom logique du dépôt URL du dépôt
$ git remote add <shortname> <url>
$ git remote remove <shortname>
$ git remote
$ git remote -v
Nom logique du dépôt

GIT / REMOTE
96
Les dépôts sont synchronisés par push / pull
– On « tire/pull/fetch » les changements provenant d’un dépôt distant
Une seule branche / toutes les branches est (sont) synchronisée(s)
– On « pousse/push » les changements vers un dépôt distant
Par défaut, une seule branche est synchronisée
Le clonage est une opération
particulière qui consiste à
récupérer toutes les
branches et les tags.
Remote repository
(dépôt distant)
Local repository
(dépôt local)
Local repository
(dépôt local)
Local repository
(dépôt local)
Anna
Mickaël Kevin
pull
push
pull
push
push
pull
pull
push

GIT / REMOTE
97
Les dépôts sont synchronisés
– Par rapport aux branches et aux tags
– Les branches distantes sont locales, non modifiables
Elles évoluent uniquement par les échanges réseaux
C0 C1 C2 C19 C20 C22 C24
v1.0
C21 C23 C25 C26
origin/master
origin/v1.0
C28 C29 C30
hotfix
master

GIT / REMOTE
98
Récupérer les commits d’un dépôt distant
$ git pull <remote> <branch>
Le plus souvent un serveur remote est nommé « origin » mais peut être nommé comme on veut !
Branche distante
Dépôt distant
choisi
(ou origin)

GIT / REMOTE
99
Après la récupération d’un dépôt distant
$ git log --oneline --all --decorate --graph

GIT / REMOTE
100
Déverser les commits vers un dépôt distant
$ git push <remote> <branch> (pull avant de faire un push)
Branche locale/distante
Dépôt distant
choisi

GIT / REMOTE
101
Cas typique de récupération distante origin/master
– La branche master n’a pas été modifiée
– La fusion est un « fast-forwarding »
C0 C1 C2 C19 C20 C22 C24
v1.0
C21 C23 C25 C26
*master
origin/master
origin/master
*v1.0
C28 C29 C30 C24
hotfix
*master
Aucun conflit
testing

GIT / REMOTE
102
Cas typique de récupération distante origin/master
– La branche master a été modifiée
– La fusion est un « three-way merge»
Le mode de récupération par défaut de la commande pull
Il est également possible de faire une reconstruction (rebase)
C0 C1 C2 C19 C20 C22
v1.0
C21 C23 C25 C26
master
origin/master
origin/master
*v1.0
C28 C29 C30 C24
hotfix
master
C24
Un conflit apparaît !
C31 Commit de fusion
(merge commit)

GIT / REMOTE
103
Une solution possible pour une récupération
– La branche master n’est pas modifié
On récupère les changements du dépôt distant origin/master
Ensuite, on fusionne sa branche de travail dans master
Mais… on synchronise avec le dépôt distant
–
–
–
v1.0
C21 C23 C25 C26
origin/master
origin/master
*v1.0
hotfix
C28 C29 C30 C24
master testing
C0 C1
C2
C19 C20 C22
master
C24

GIT / REMOTE
104
Associer une branche locale et distante
Une branche locale ne peut avoir qu’une seule branche distante
Facilite l’utilisation des commandes push / pull
Il n’est pas nécessaire de préciser le dépôt distant pour une branche suivie
Permettent d’avoir des informations
supplémentaires
Distance entre la branche locale / distantes, s’il existe une divergence
Le clonage associe
généralement la branche
master et origin/master
C0 C1 C2 C19 C20 C22 C24
v1.0
C21 C23 C25 C26
origin/master
origin/v1.0
C28 C29 C30
hotfix
master

GIT / REMOTE
105
Branches distantes et suivies
$ git branch --set-upstream-to=<remote>/<branch>
$ git checkout -b <branch> --track <remote>/<branch>
$ git branch -a (affiche toutes les branches)
$ git branch -r (affiche les branches distantes)

GIT / REMOTE
106
Gestion des branches / tags distants
$ git push <remote> :<branch> (branche distante)
$ git push <remote> <tag> (tag local nommé)
$ git push <remote> --tags (tous les tags)
$ git tag -d <tag> (tag local)
$ git push <remote>:<tag> (tag distant)

GIT / REMOTE
107
Synthèse des opérations
git clone
●
Opération de récupération (git fetch)
Branches distantes suivies
Sélection de branche initiale
●
●
git pull
●
Opération de fusion (merge)
●
git pull (rebase)
●
Opération de fusion (rebase)
●

GIT / REMOTE
108
En résumé
Gestion des remotes
$ git remote add <remote>
<url>
$ git remote remove <remote>
$ git remote [-v]
Synchronisation de dépôt (local → distant)
$ git fetch <remote> <branch>
$ git push <remote> [<branch>]
Synchronisation de dépôt (local ← distant)
$ git pull <remote> [<branch>]
Branches de suivies
$ git branch –set-upstream-to=<remote>/<branch>
$ git checkout -b <branch> --track
<remote>/<branch>
Consulter les branches locales / distantes
$ git branch -a
$ git branch -r
Gestion des tags / branches distantes
$ git push <remote> --tags

GIT / BRANCHES
110
Different presentations for the same concept :

GIT / BRANCHES
111
Certains disent que c’est la « killer feature » !
Avec Git, les branches...
–
–
– Incroyablement facile & rapide (voire instantané)
Encourage la création de branche pour fusionner
ensuite
Plusieurs fois par jour avec des fusions récurrentes
Aucun transit par un serveur distant
Toutes les commandes de branches sont locales

GIT / BRANCHES
112
Des branches et des tags...
– Les branches distantes
Ce sont les branches qui appartiennent à des dépôts distants
– Les branches locales
Ce sont les branches qui font partie de votre dépôt local
– Les tags sont locaux et/ou distants
Ce sont des étiquettes d’un dépôt local ou distant
– La branche
HEAD
Une branche spéciale
C0 C1 C2 C19 C20 C22 C24
v1.0
C21 C23 C25 C26
*testing
mickael
master HEAD

GIT / BRANCHES
113
C0 C1 C2 C19 C20 C22 C24
v1.0
C21 C23 C25 C26
*testing
mickael
master HEAD
Kevin travaille sur un client / serveur TCP
– Une version v1.0 a déjà été sortie
– Il travaille actuellement sur une version RC v1.1 avec Mickaël
Kevin a récupéré le travail de Mickaël mais n’est pas tout à fait prêt à fusionner
Le travail de Mickaël est un peu en avance par rapport au serveur central (master)

GIT / BRANCHES
114
C0 C1 C2 C19 C20 C22 C24
v1.0
C21 C23 C25 C26
testing
mickael
master
*hotfix
v1.0
HEAD
Soudain, Alan arrive pour un bug important sur v1.0
– Kevin recherche la cause. Il crée une branche « v1.0 »
C’est le premier bug sur cette version donc une branche est créée.
– Il créé également une branche « hotfix »
Kevin préfère travailler sur une branche différente au cas où un autre problème surviendrait.

GIT / BRANCHES
115
C0 C1 C2 C19 C20 C22 C24
v1.0
C21 C23 C25 C26
testing
mickael
master
*hotfix
v1.0
C28 C29 C30
HEAD
Kevin travaille sur le problème
– Il effectue quelques commits, quelques tests

GIT / BRANCHES
116
C0 C1 C2 C19 C20 C22 C24
v1.0
C21 C23 C25 C26
testing
mickael
master
hotfix
C28 C29 C30
*v1.0
HEAD
Kevin est satisfait de sa correction
– Il effectue une fusion de « hotfix » dans « v1.0 »
– Kevin a-t-il travaillé en relation avec le serveur central ?

GIT / BRANCHES
117
C0 C1 C2 C19 C20 C22 C24
v1.0
C21 C23 C25 C26
testing
mickael
master
hotfix
C28 C29 C30
*v1.0
v1.0.1
HEAD
Kevin va effectuer une synchronisation
– Il crée un tag v1.0.1
– Il synchronise la branche v1.0 et le tag v1.0.1

GIT / BRANCHES
118
Kevin retourne travailler sur la nouvelle version
– Il retourne sur sa branche « testing »
– Il efface la branche « hotfix » non nécessaire
C0 C1 C2 C19 C20 C22 C24
v1.0
C21 C23 C25 C26
*testing
mickael
master
C28 C29 C30
v1.0
v1.0.1
HEAD

GIT / BRANCHES
119
Qu’est qu’une branche locale ?
– Une branche est un pointeur évoluant à partir d’un
commit
●
Chaque commit possède une référence SHA-1
Une branche est donc un pointeur sur une référence SHA-1
Elle évolue à chaque commit effectué
●
●
C0 C1 C2 C19 C20 C22 C24
C21 C23 C25 C26
*testing
mickael
master
v1.0
HEAD

GIT / BRANCHES
120
A propos de
HEAD
–
–
– HEAD représente la branche active
Également un pointeur sur une branche / référence
Il se déplace lorsqu’un commit est effectué
En fait, les commits sont effectués sur HEAD, ce qui fait évoluer la branche sur laquelle il pointe
C0 C1 C2 C19 C20 C22 C24
C21 C23 C25 C26
*testing
mickael
master
v1.0
HEAD
C31

GIT / BRANCHES
121
La branche master (ou main désormais) :
–
–
– La branche « master » est la branche par défaut
Elle suit les mêmes règles que les autres
branches Elle est crée au moment d’un git init
Personne ne s’ennuie à la renommer, mais c’est possible et cela ne change
rien
C0 C1 C2 C19 C20 C22 C24
C21 C23 C25 C26
*testing
mickael
master
v1.0
HEAD

GIT / BRANCHES
122
Les branches distantes
–
–
– Des branches en lecture seule, non
modifiables Elles servent de point de
référence
Elles utilisent un format particulier
Elles indiquent un nom court du dépôt distant / le nom de la branche
C0 C1 C2 C19 C20 C22 C24
C21 C23 C25 C26
*testing
mickael/testing
origin/master
v1.0
HEAD

GIT / BRANCHES
123
Règle importante sur les branches
– Une référence doit être associée à un tag / une branche
– Il n’est pas possible de quitter une branche modifiée
C0 C1 C2 C19 C20 C22 C24
C21 C23 C25 C26
mickael/testing
v1.0
master
C28 C29 C30
*testing HEAD
C31

GIT / BRANCHES
124
Consulter les branches existantes
$ git branch
$ git branch -v
* signifie que la
branche est
utilisé
actuellement
(HEAD)

GIT / BRANCHES
125
Créer une branche
$ git branch <name> (sur la référence courante)
$ git branch <name> <reference|branch|tag> (référence donnée)
$ git log --oneline –decorate (montre les tags/branches)

GIT / BRANCHES
126
Supprimer une branche
$ git branch -d <name>
$ git branch –D (shortcut for –delete –force)

GIT / BRANCHES
127
Supprimer une branche avec des
modifications
$ git branch -D <name>
L’option -d ne
fonctionne pas.
Vous êtes prévenu !

GIT / BRANCHES
128
Sélectionner une branche
$ git checkout <branch>
$ git log --oneline --decorate --all

GIT / BRANCHES
129
Créer et sélectionner une branche
$ git checkout –b/-B <branch> <reference|branch|tag> (create a local branch and switch to)
eq. git branch <name> <reference> ; git checkout <name>

GIT / BRANCHES
130
Sélectionner une référence directement
Le mode détaché est
un mode sans
branche qui peut
être utile parfois...
Dans ce mode,
effectuer des
commits est
possible, mais on
peut avoir de la
difficulté à retrouver
les références par la
suite, à moins de
créer une branche.

GIT / BRANCHES
131
Explication sur le mode détaché
– Dans votre dépôt, tout est conservé
– Vous avez simplement créé une branche sans la nommer
C0 C1 C2 C19 C20 C22 C24
C21 C23 C25 C26
testing
mickael
maste
r
v1.0
HEAD
master
C28 C29 C30
C31

GIT / BRANCHES
132
●
En résumé
Consulter les
branches
$ git branch
$ git branch -v
Créer/Détruire une branche
$ git branch <name> (sur reference courante)
$ git branch <name> <reference|tag|branch> (sur référence donnée)
$ git branch -d <name>
$ git branch -D <name>
Consulter les tags
$ git tag
Créer/Détruire un tag
$ git tag <name> (sur reference courante)
$ git tag <name> <reference|tag|branch> (sur référence donnée)
$ git tag -d <name>
Sélectionner une branche
$ git checkout <name> (branche existante)
$ git checkout -b <name> <reference|tag|branch> (création de
branche)

GIT / BRANCHES
133
Sur quelle branche suis-je ?
Je décide de déplacer testing en C19. Expliquer ?
C52 appartient à Mickael. Puis-je m’y rendre ?
Quelles sont les situations anormales ?
Déplacer la branche distante master en C19 ?
C0 C1 C2 C19 C20 C21 C22
C51 C52 C53 C54
testing
mickael
maste
r
HEAD
master
C40 C41 C42
C23
v1.0
C23 est un
travail laissé en
zone staging
C61 C63 C64 C65

GIT / TAGS
135
Qu’est ce qu’un tag ?
– Un tag est une étiquette/un label/un raccourcis sur une référence
SHA-1
– C’est une étiquette fixe qui n’évolue pas
On peut créer et effacer un tag. On peut dire que c’est un alias pour une référence
C0 C1 C2 C19 C20 C22 C24
C21 C23 C25 C26
*testing
mickael
master
v1.0
HEAD

GIT / TAGS
136
Consulter les tags
$ git tag
$ git tag --list

GIT / TAGS
137
Créer un tag
$ git tag <name> (sur la référence courante)
$ git tag <name> <reference|branch|tag> (référence donnée)

GIT / TAGS
138
Supprimer un tag
$ git tag -d <name>

GIT / TAGS
139
Sélection de branche avec git checkout
Cette commande vous rappelle-t-elle quelque chose ?
Cependant, il n’est pas possible
– De sélectionner un tag
Il est donc nécessaire de créer une branche locale positionnée sur le tag voulu
– De sélectionner une branche distante
Il est donc nécessaire de créer une branche locale positionnée sur la branche souhaitée
C0 C1 C2 C19 C20 C22 C24
C21 C23 C25 C26
*testing
mickael
master
v1.0
HEAD
C31

BASIC COMMANDS
Merge of branches
140

GIT / MERGE
141
Créer de nombreuses branches implique la fusion
– Ce premier mode de fusion se nomme le « fast-forward »
C’est un mouvement d’un pointeur de branche vers un emplacement suivant
C0 C1 C2 C19 C20 C22 C24
v1.0
C21 C23 C25 C26
mickael
testing
master
hotfix
*v1.0
C28 C29 C30
HEAD
v1.0 Branche à
fusionner
Branche
qui reçoit la
fusion

GIT / MERGE
142
Fusion par algorithme de « fast-forwarding »
$ git checkout <name> (sur la branche qui reçoit la fusion)
$ git merge <name> (branche à fusionner)
$ git log --oneline --all --decorate --graph

GIT / MERGE
143
Fusion par algorithme de « fast-forwarding »

GIT / MERGE
144
Fusion basique avec un ancêtre commun
– On se positionne dans la branche qui reçoit la fusion
– On indique la branche à fusionner
v1.0
hotfix
C0 C1 C2 C19 C20 C22 C24
v1.0
C21 C23 C25 C26
mickael
*testing
master
C28 C29 C30
Ancêtre
commun
Branche à
fusionner
Branche
qui reçoit la
fusion
HEAD

GIT /MERGE
145
Fusion basique avec un ancêtre commun
– Mode de fusion « three-way merge »
– Aucune copie de référence n’est effectuée
v1.0
hotfix
C0 C1 C2 C19 C20 C22 C24
v1.0
mickael
*testing
master
C28 C29 C30
C31
HEAD
Ancêtre
commun
Branche
qui reçoit la
fusion
Branche à
fusionner
Commit de fusion
(merge commit)
C21 C23 C25 C26

GIT / MERGE
146
Fonctionnement du « three-way merge »
C0 C1 C2 C19 C20 C22 C24
v1.0
testing
master mickael
v1.0
C31
HEAD
Ancêtre
commun
(Base)
Branche qui
reçoit la fusion
(Mine)
Branche à
fusionner
(Yours)
Commit de fusion
(merge commit)
C21 C23 C25 C26

GIT / MERGE
147
Fusion à partir d’un ancêtre commun
$ git checkout <name> (branche qui reçoit la fusion)
$ git merge <name> (branche à fusionner)
$ git mergetool <name> (branche à fusionner)

GIT / MERGE
148
Fusion à partir d’un ancêtre commun

GIT / MERGE
149
Fusion sélective
–
–
– Mode de fusion «cherry-pick»
Le but est de prendre un (ou plusieurs) commits
Des copies de références sont effectuées
Branche à
C0 C1 C2 C19 C20 C22 C24
v1.0
C21 C23 C25 C26
mickael
testing
master
*v1.0
C28 C29 C30
HEAD *hotfix fusionner
C24’ Commit à
fusionner

GIT / MERGE
150
Fusion sélective
$ git cherry-pick <reference> (commit à fusionner) (le commit doit être unitaire)

GIT / MERGE
151
Fusion sélective

GIT / MERGE
152
Fusion avec reconstruction
– Mode de fusion « rebase »
– Des copies de références sont effectuées
C0 C1 C2 C19 C20 C22 C24
v1.0
C21 C23 C25 C26
mickael
testing
master
C28 C29 C30
v1.0
*hotfix
Ancêtre
commun
Branche à
fusionner
Branche
qui reçoit la
fusion
HEAD

GIT / MERGE
153
– On commence par repartir de la branche à fusionner
– On rejoue tous les changements de l’autre branche
C0 C1 C2 C19 C20 C22 C24
v1.0
C21 C23 C25 C26
mickael
testing
master
C28 C29 C30
v1.0
*hotfix
Ancêtre
commun
Branche à
fusionner
Branche
qui reçoit la
fusion
HEAD
C22
C
24

GIT / MERGE
154
– Mode de fusion « rebase »
– Des copies sont effectuées
C0 C1 C2 C19 C20 C22 C24
v1.0
C21’ C26’
mickael
testing
master
*hotfix
C28 C29 C30
v1.0
Ancêtre
commun
Branche à
fusionner
Branche
qui reçoit la
fusion
HEAD
C23’
C
25’
Rejoue les changements

GIT / MERGE
155

GIT / MERGE
156
$ git rebase <name> (branche à utiliser pour la reconstruction)
Rembobinage
Application des commits
en utilisant 3-way merge

GIT / MERGE
157
$ git rebase <name> (branche à utiliser pour la reconstruction)
$ git rebase <branch source> <branch destination> ex: git rebase main bugfix

GIT / MERGE
158
Fusion avec reconstruction interactive
$ git rebase -i <reference|branch|tag>

GIT / MERGE
159
Par défaut, le mode « pick » est utilisé
L’ordre est exactement le même
Git explique toutes les opérations
disponibles
Commit le plus ancien
Comment perdre un
commit simplement ?
Commit le plus récent

GIT / MERGE
160
Différentes opérations
possibles
Opération de sélection « pick »
C19 C20 C22
Avant
C19 C22 C20
Après
C19 C20 C22
Avant Après
Opération de reformulation «reword»
C19 C20’ C22
C19 C20 C22
Avant
C19 C20 Contient C20 +
C22
Après
Opération de réparation « fixup »
Opération d’écrasement «squash»
C19 C20 C22
Avant
C19 C26
Après
Contient C20 / C22
avec une reformulation
C19 C20 C22
Avant Après
Opération d’effacement «drop»
C19 C22
C19 C20 C22
Avant
Opération d’édition «edit»
Après
C19 C20 C22
L’édition stoppe
immédiatement après le
commit pour effectuer des
actions manuelles

GIT / MERGE
161

GIT / MERGE
162
C22 C22a C24 C24a C27 C28 C29
C22 C22a C24 C24a C27 C28 C29
C22 C24 C24a C27 C28 C29
Ordonnancement
Fixup C22a → C22
Apply C24
C22 C24 C24a C27 C28 C29 Fixup C24 → C24
C22 C24 C27 C28 C29 Apply C27
C22 C24 C27 C28 C29 Drop C28
C22 C24 C27 C29 Squash C29 → C27
C22 C24 C27 + C29 Fusion interactive terminée

GIT / MERGE
163
Rebase en profondeur :
C16 C17 C18 C19 C20
C18’ C20’ C19’ C22’ C24’
*testing HEAD
C30’
C29’
$ git rebase -i C17
C0 C1 C2 C19 C20 C22 C24
*testing HEAD
C30
C29
master
origin/master
master
origin/master
Pour votre part, on pourrait imaginer
que cela puisse bien se passer.
Mais le serveur pourrait refuser le push.
Pour les autres, l’arbre des
références sur lequel ils se basaient
est complètement détruit.
Impossible à s’y retrouver !

GIT / MERGE
164
Attention – rebaser en profondeur
– Rebaser, oui, mais pas au-delà de certaines limites
Jamais avant l’origin des temps
– Ne jamais rebaser un historique partagé
Un rebase ré-écrit les références qui ne sont dès lors plus partagées
– Possible uniquement pour un individu seul
$ git rebase -i C17
C0 C1 C2 C19 C20 C22 C24
*testing HEAD
master
origin/master
C30
C29

GIT / MERGE
165
Attention – git rebase profond implique git push --force
– Cette commande est relativement puissante et destructrice
– Possible uniquement pour un individu seul et/ou averti
Les serveurs ont généralement des
règles pour empêcher ce genre de
manipulation

GIT / MERGE
166
La fonction rerere est un peu cachée, mais...
–
–
– Signifie « REuse REcorded REsolution »
Fonction de cache des résolutions passées
Évite d’effectuer deux fois le même merge
$ git config [--global] rerere.enabled true
$ git config [--global] rerere.autoupdate true
C0 C1
master
C2
spanish
C3

GIT / MERGE
167
C0 C1
master
C2
spanish
C3
C0 C1
master
C2
spanish
C3

GIT / MERGE
168
C0 C1
master
C2
spanish
C3
C0 C1
master
C2
spanish
C3

GIT / MERGE
169
Pour rappel, il existe différents modes de
fusion
–
–
–
– Fusion « Fast-forward »
Fusion « Three-way merge »
Fusion sélective « Cherry-picking »
Fusion avec reconstruction « Rebase »
Mais aucune de ces fusions ne peut aller au-delà d’un dépôt !

GIT / MERGE
170
Deux nouvelles commandes
– Commande format-patch fabrique des patches
Les patches sont des extraits de commits
– Commande am restaure les patches
Permet la restauration des commits sous la même forme
– Commande apply restaure les patches
Permet la restauration des commits sous forme de fichiers
git format-patch
0001
0002
0003
0004
0005
git am git apply
Stable
situation
Merge
conflict(s)
Resolved
conflict(s)
Abandon
(retour à la situation précédente)
Fusion
Résolut
on
Mode de
fusion
Conflits résolus
(nouvelle situation stable)

GIT / MERGE
171
0001
0002
0003
0004
0005

GIT / MERGE
172
Merge
–
–
–
– Simple à utiliser
Conserve l’historique
Non destructif
Perte de lisibilité
Rebase
–
–
–
– Ré-écriture d’historique
Une seule branche
Perte des branches
Conflits plus complexes
Préférez-vous la traçabilités des branches ? Préférez-vous un historique propre et linéaire ?

GIT / MERGE
173
En résumé
Commande générale de fusion (merge)
$ git merge <name> (placée sur la branche recevant la fusion)
Commande de fusion sélective(cherry-pick)
$ git cherry-pick <commit>... (placée sur la branche recevant la
fusion)
Commande générale de fusion (rebase)
$ git rebase <name> (placée sur la branche recevant la fusion)
Consulter les logs avec une vue graphique (toutes branches confondues)
$ git log --all –graph --oneline

GIT / MERGE
174
❑ Qu’obtient-on une fois le rebasage effectué (sans
conflit) ?
❑ Est-ce un problème pour vous ?
❑ Quel est le problème qui se cache ?
$ git rebase -i C17
C0 C1 C2 C19 C20 C22 C24
*testing HEAD
master
origin/master
C30
C29

BASIC COMMANDS
Conflits of merge
175

GIT / FIX MERGE
176
La fusion peut impliquer des conflits
–
– Excepté pour le mode de fusion « fast-forward »
Pour rappel, ce mode de fusion est un déplacement de pointeur de branche
Tous les autres modes peuvent provoquer des
conflits
● Fusion basique (three-way merge)
Fusion sélective (cherry-pick)
Fusion avec reconstruction (rebase)
●
●

GIT / FIX MERGE
177
Les conflits font entrer dans un mode spécial
– A tout moment, on peut abandonner pour l’état initial
Notion de mode transactionnel
– Lorsque les conflits sont résolus, on effectue une action
Cette action permet de mettre fin au mode et fait revenir à une situation stable
Stable
situation
Merge
conflict(s)
Resolved
conflict(s)
Abandon
(retour à la situation précédente)
Conflits résolus
(nouvelle situation stable)
Fusion
Résolution
Mode de fusion

GIT / FIX MERGE
178
Fusion sélective provoquant un conflit
$ git cherry-pick <reference>

GIT / FIX MERGE
179
Gestion de conflits lors d’un cherry-pick
Description de l’état
●
●
●
Branche
Mode de fusion
Que faire ensuite ?
Il est important
d’effectuer add/rm pour
marquer la résolution

GIT / FIX MERGE
180
Tableau des commandes pour les
fusions
Opération Abandon Résolution
git merge git merge --abort git
git
merge --
continue
commit
git cherry-pick git cherry-pick --abort git cherry-pick –continue
git rebase git rebase --abort git
git
rebase --
continue rebase
--skip*
* Le fait de sauter un commit est possible
Dans ce cas, le commit ne sera pas intégré à la branche réceptrice
Cela peut générer des erreurs par la suite

GIT / FIX MERGE
181
Quand tout semble perdu, ...
–
– Si vous avez commité, rien n’est perdu
A moins d’avoir vraiment essayé de le perdre
Même si vous ne savez pas où est votre commit… il est là !
Tant que votre dépôt local est présent, tous les commits sont préservés
Un commit orphelin, une branche détruite est la plupart du temps
récupérable L’utilisation de la commande reflog peut être utile dans ce cas

GIT / FIX MERGE
182
Travailler avec les logs de
références
$ git reflog
L’opérateur de log de références relative
HEAD@{N}
●
N représente la N-ième dernière opération
Fait référence aux dernières actions
Attention à l’ajout de nouvelles
opérations
●
●

GIT / FIX MERGE
183
Vrai ou Faux ?
– Merge fast-forward provoque des conflits
Rebase est plus facile que merge fast-forward
Pour corriger un bug, j’utilise plutôt 3-way merge
Operation cherry-pick effectue une copie
L’ordre des commits cherry-pick’ed est
important
Fusion de testing → master, je vais dans master
Impossible de faire un commit pendant un conflit
–
–
–
–
–
–

GIT / FIX MERGE
184
En résumé
Commande générale de fusion (merge)
$ git merge <name> (placée sur la branche recevant la fusion)
$ git merge --continue, git commit
$ git merge --abort
Commande de fusion sélective (cherry-pick)
$ git cherry-pick <commit>... (placée sur la branche recevant la
fusion)
$ git cherry-pick --continue
$ git cherry-pick --abort
Commande générale de fusion (rebase)
$ git rebase <name> (placée sur la branche recevant la fusion)
$ git rebase --continue
$ git rebase --abort

GIT / DEBUG
186
Voir les annotations de
fichiers
$ git blame <file>
$ git annotate <file>

GIT / DEBUG
187
La commande grep permet de rechercher dans le dépôt
–
–
–
– Dans une branche particulière (nom de la
branche) Dans la zone INDEX (--cached)
Dans les fichiers non suivi (--untracked)
Dans les sous-module (--recurse-submodules)

GIT / DEBUG
188
La commande bisect permet de rechercher un bug
–
–
– Principe de la dichotomie sur un module
Possibilité de lancer un programme de façon
systématique Visualiser l’arbre avec gitk (git bisect
visualize)
$ git bisect start
$ git bisect good [<ref>]
$ git bisect bad [<ref>]
$ git bisect reset
$ git bisect run <program>
C0 C1 C2 C19 C20 C22 C24 C30
C29
bisect good bisect bad
First step
Status ?

GIT / DEBUG
189
$ git bisect start
$ git bisect reset
Rechercher efficacement...
C0 C1 C2 C19 C20 C22 C44 C60
C59
bisect good bisect bad
First step
Status ?

GIT / DEBUG
190
Résumé des commandes
Etudier un fichier, recherche de coupable
$ git blame [-L<start>,<stop>] <file>
Recherche ‘grep’ dans un dépôt
$ git grep -e <pattern> --cached [--] <file selection>...
$ git grep -e <pattern> --untracked [--] <file selection>...
$ git grep -e <pattern> <branch> <file selection>...
...
Rechercher une erreur par dichotomie
$ git bisect start
$ git bisect reset

GIT / TIPS
192
Utiliser la réserve (stash)
–
–
–
– Parfois, en plein travail, une autre action est
requise
Par exemple, travailler sur un bug alors qu’on est en plein dans un
développement
On ne veut pas effectuer de commit de son travail
Mais on voudrait conserver les changements
La réserve fonctionne sous la forme d’une FIFO
Il est donc possible de cumuler plusieurs changements et les défaire dans l’ordre
Mais stash n’est pas fait pour durer...

GIT / TIPS
193
Utiliser la réserve
$ git stash [push] $ git stash pop [<name>]
Observer la réserve
$ git stash list (liste des stashes)
$ git stash show (liste des fichiers modifiés)
$ git stash show -p (détail des changements)

GIT / TIPS
194
Possibilité de mettre en place des alias
– Des commandes maison adapté à votre travail
$ git config --global alias.ci commit
$ git config --global alias.ls log --oneline --decorate
$ git config --global alias.lsa log --oneline --decorate --all
$ git config --global alias.lsg log --oneline --decorate --all --graph
$ git config --global alias.cached diff --cached
$ git config --global alias.viewer ‘!gitk’
...

GIT / TIPS
195
Organiser son travail par branche
–
–
–
– Git est fait et pensé pour cela
Une branche est peu chère à créer et à utiliser
Avoir une organisation dans les noms des branches
Par exemple, des branches feat-<name>, hotfix-<name>, dev-<name>
On ne synchronise pas toutes les branches
Éviter la pollution de branches sur des dépôts distants
On fusionne dans master (ou une autre branche)
Ainsi, la branche principale reste une branche stable d’où sont issus des branches

GIT / TIPS
196
Faire des branches temporaires pour
travailler
–
–
–
–
– Pour effectuer un merge / rebase
Une opération complexe
Des branches pour travailler, pour essayer &
annuler Pour conserver un lot de traces (debug)
...

GIT / TIPS
197
Faire de nombreux commits
–
–
–
– Souvent et le plus tôt possible pour un
fichier
Dès qu’il est entré, les risques de pertes deviennent moins
importants
Un bon commit est un commit atomique
Permet de mieux séparer les idées, les
fonctionnalités Il est le plus petit possible, en restant
cohérent
On peut mieux manipuler les commits
revert, cherry-pick, rebase sont plus facile à utiliser
Simplifie la recherche de bug (dichotomie)

GIT / TIPS
198
Au moment d’un « push » vers un dépôt distant
– Fusion interactive (rebase) avant « push »
Séparer/Grouper les commits, reformuler sont des taches à faire pour permettre une
meilleure lisibilité pour les autres. Opération de nettoyage qui clarifie, facilite les
revues, etc.
– Prendre le temps de se poser !
C’est en principe définitif, donc ne pas faire un « push » à la légère
– Ne laissez pas traîner vos affaires
Le dépôt distant n’est pas un dépotoir. Supprimer les branches inutiles, les tags
inutiles pour garder cet espace propre et clair pour tous.

GIT / TIPS
199
La sauvegarde
–
–
– Créer un dépôt distant n’est pas compliqué
Avec un simple accès SSH ou même un autre disque local
Synchronisation rapide (git push backup)
Sans avoir besoin de passer par le serveur central en toute autonomie
Quand le développement est terminé, on
efface

❑ A the following lines at the end of your ~/.bashrc :
(…)
parse_git_branch() {
git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* (.*)/(1)/'
}
export PS1="u@h [e[32m]w [e[91m]$(parse_git_branch)[e[00m]$ «
❑ Thus, the prompt of your command line will be updated automatically when you
will be inside a git repo :
~/Workspace/NN6/STREAMPROBE/buildroot (2020.02.x-nn6)$
GIT / TIPS
200

GIT / TOOLS
202
Gitk
❑ Part of the Git tool suite
❑ Visualization tool only
❑ Works on Linux/Mac/Windows
❑ https://git-scm.com/docs/gitk
❑ $ sudo apt install gitk

GIT / TOOLS
203
Gitg
❑ Quite similar to gitk
❑ Visualization tool only
❑ https://github.com/GNOME/gitg
❑ $ sudo apt install gitg

GIT / TOOLS
204
❑Part of the Git tool suite
❑Works on Linux/Mac/Windows
❑ $ sudo apt install gitg
Git-gui

GIT / TOOLS
205
SmartGit
❑Easy to use
❑Integration with GitHub/GitLab/BitBucket.
❑ Very interesting merge tool
❑Free for non-commercial use Works on
Linux/Mac/Windows
❑https://www.syntevo.com/smartgit/

GIT / TOOLS
206
GitKraken
❑ Easy to use, nice graphics
❑ Undo actions (undo), drag'n drop
merge Free for non-commercial
use
❑ https://www.gitkraken.com/

GIT / TOOLS
207
Fork
❑ Easy to use, nice graphics
❑ Free for non-commercial use
❑ https://git-fork.com/

GIT / TOOLS
208
TortoiseGi
t ❑ Open-source
❑ Looks like TortoiseSVN
❑ Difficult to understand when an
error occurs Context menu
integration
❑ Works on Windows only !
❑ https://tortoisegit.org/

GIT / TOOLS
209
GitExtension
❑ Open-source
❑ Intuitive interface, easy to use
❑ http://gitextensions.github.io/

GIT / TOOLS
210
Visual Studio Code :
❑ Open-source
❑ Intuitive interface, easy to use
❑ Has lots of plugins
❑ https://vscodium.com/
❑ https://code.visualstudio.com/

❑ Other tools :
https://git-scm.com/downloads/guis
GIT / TOOLS
211

❑ LINKS :
o https://git-scm.com/doc
o https://git-scm.com/docs
o https://git-scm.com/book/en/v2
o https://git-scm.com/doc/ext
o https://git-scm.com/docs/gittutorial
o https://gitimmersion.com/
o https://github.com/sensorflo/git-draw/wiki
o http://www-cs-students.stanford.edu/~blynn/gitmagic/
o https://git-scm.com/docs/giteveryday
o https://nulab.com/learn/software-development/git-tutorial/git-basics/
o https://github.com/progit/progit2-fr/releases/download/2.1.70/progit.pdf
o https://github.com/progit/progit2/releases/download/2.1.360/progit.pdf
🡪
https://www.amazon.fr/s?k=git&i=stripbooks&__mk_fr_FR=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=424VPI44G9P5&
GIT / HELP
213
(Official printed documentation)

214
❑ Slides :
https://docs.google.com/presentation/d/1nax4czg_wKqLFoH21ApPHZ
bJ0SpF-
ML7/edit?usp=share_link&ouid=113587050683981420435&rtpof=tru
e&sd=true
❑ Documentation & ebooks :
https://drive.google.com/drive/folders/1nmhpsOWyHvOE_B19Cfn8q7
KDtDVu-wqK
❑ Videos :
https://drive.google.com/drive/folders/1pFWIMgiivpaAqwYcHUsVajQO
AKmHANPI

Next part, the NN6 official :
gitflow, versionning and svn
migration.
215

ENENSYS
4A rue des Buttes
CS 37734
35 577 Cesson-Sévigné – France
Phone (+33) 1 70 72 51 70
Email contact@test-tree.com
www.enensys.com
216

GIT training - basic for software projects

Recommandé

Recommandé

Contenu connexe

Similaire à GIT training - basic for software projects

Similaire à GIT training - basic for software projects (20)

GIT training - basic for software projects