Introduction to fundamental GIT architecture and basic/main commands

1. Introduction for developers

2. Agenda
Brief History
Fundamentals
Usual Situations & Actions
Branchs
Merging
Working with a remote repository
Pull Request
Handy commands, tips
Documentation

3. About me
Abderrazak BOUADMA
Software Engineer at SFEIR
Google Cloud Expert
Technical Lead At Accor since November 2015
JUG Leader, VoxxedDays/Devoxx4Kids Organizer

4. Brief History

5. Brief History
• GNU RCS (Revision Control System) ~1982
• SCCS Source Code Control System 1986-89
• CVS Concurrent Versions System 1990 (Client/Server, CLI, GUI)
• SVN (Apache Subversion) 2000
1. Atomic Commits
2. renaming & moving files doesn’t destroy history
3. folders & meta-data are also processed
4. A unique revision ID for all the repository

6. Brief History
• Created by Linus Torvalds to handle the integration workflow of the Linux kernel
integrations (more than 20 million lines of code)million de lignes de code)
• Replaces BitKeeper
• Must be efficient
• Simplified & distributed architecture
• helps to have a parallel development process
• handles large projects
• has no dependency to any sub-system (DB, Bus, etc.)
• You’ll be happy at the end of the day … almost :)

7. Fundamentals

8. Fundamentals
To install the latest and greatest version)
https://git-scm.com/download
for a windows installation
https://git-for-windows.github.io
Graphical UIs
How to install p4merge
Installation

9. First steps :
working with a local repository

10. Fundamentals
$ git init #creates a local repository at the root folder
$ git status #affiche l’état du working copy et la staging area
$ git add #ajout de fichiers à l’index (staging area)
$ git rm —cached #unstage un nouveau fichier
$ git commit #commit le fichier dans le repository
Main Git Commands

11. Working
dir
index
(staging)
HEAD
add commit

12. Fundamentals
• Commit : ensemble cohérent de modifications
• Working Copy : contient les modifications en cours
• Staging area (index) : liste des modifications effectuées dans le working copy qu’on
veut inclure dans le prochain commit
• Repository : ensemble des commits du projet (branchs, tags, etc.)
Core definitions

13. Fundamentals
WORKSPACE (t)
Here where you
create/modify/delete/
move your
documents.
Here where HEAD
points to
INDEX
(STAGING
AREA)
Here where
you stage
your files
for next
commit
UPSTREAM
REPOSITORY
STASH LOCAL
REPOSITORY
Here where all
commits are stored
git add git commit git push

14. Fundamentals
WORKSPACE (t)
Here where you
create/modify/delete/
move your
documents.
Here where HEAD
points to
INDEX
(STAGING
AREA)
Here where
you stage
your files
for next
commit
UPSTREAM
REPOSITORY
STASH LOCAL
REPOSITORY
Here where all
commits are stored
HEAD points on
this area which is
a view of your
work at time t
Also contains
your .git folder

15. Fundamentals
Contains your working documents,
it’s the representation of
your actual & effective work
Working Copy

16. Fundamentals
INDEX
(STAGING
AREA)
Here where
you stage
your files
for next
commit
Here where you
prepare your work
(staging) to be
committed
Shared between
all branches
WORKSPACE (t)
Here where you
create/modify/delete/
move your
documents.
Here where HEAD
points to
HEAD points on
this area which is
a view of your
work at time t
Also contains
your .git folder

17. Fundamentals
The staging area is a file, generally contained in your Git directory,
that stores information about what will go into your next commit.
It’s sometimes referred to as the “index”, but it’s also common to refer to it
as the staging area.
index (staging area)

18. Fundamentals
LOCAL
REPOSITORY
Here where all
commits are stored
All commits are
stored here
The only way to
share/retrieve
external work
The only way to
share/retrieve
external work
INDEX
(STAGING
AREA)
Here where
you stage
your files
for next
commit
Here where you
prepare your work
(staging) to be
committed
Shared between
all branches

19. Fundamentals
$ git init #creates a local repository at the root folder
$ git clone URL # get a copy of an existing repository (distant)
Repository

20. Fundamentals
UPSTREAM
REPOSITORY
STASH LOCAL
REPOSITORY
Here where all
commits are stored
All commits are
stored here
The only way to
share/retrieve
external work
The only way to
share/retrieve
external work
This is your
REMOTE
repository (On
premises, github,
etc)
Here where you
can (stack)
temporary work
for later

21. Fundamentals
Stash : a stack where you can save temporary staged worked for later processing
$ git stash # store your data
$ git stash apply # restore your saved work
Remote Repository : your team(s) shared repository where all the work meet.
$ git push # share your work others
$ git pull # retrieve the work of others
Stash & remote

22. Fundamentals
un commit doit :
• Dans les faits, c’est un pointeur
• Connait son ou ses parents
• possède un identifiant unique SHA1
il doit :
• compiler
• fonctionner
• signifier quelque chose (feature, bug fix, etc.)
Commit

23. Fundamentals
Commit
COMMIT TREE
BLOB
(zlib)
33d4e1c6716628fcab2fd4e1c67a2d28fced
124e1c2886628fccc
124e1c2886628fccc
acb15c2886628fccc
334e1c2886628fc45
COMMI
T
COMMI
T
TIME
MASTE
R
HEA
D

24. Usual Situations & Actions
$ git commit -m “YOUR MESSAGE” # normal commit
$ git commit -a -m “YOUR MESSAGE” # only modified files
$ git commit —amend # fix previous commit (updates message)
Commit

25. Usual Situations & Actions
$ git log [-n] [-p] [—oneline]
# affiche les IDs des commits, les messages et les modifications
# -n : limit à n commits
# -p : affiche le diff avec le commit précédent
# —oneline : affiche uniquement le début de l’ID du commit et le comment
sur une seule ligne
$ git diff
# git diff id_commit : diff entre working copy et commit
# git diff id_commit1 id_commit2 : diff entre deux commits
Commit

26. Usual Situations & Actions
# id_commit^ : parent du commit
# id_commit^^ : grand-parent du commit
# id_commit~n : n-ième parent du commit
# id_commit^2 : deuxième parent du commit (merge)
# id_commit1..id_commit2 : variations entre commit 1 et commit 2
git log
Ancêtres et références

27. TP
• Créer un nouveau repository
• Ajouter un fichier et commiter
• Modifier le fichier et commiter
• Observer l’historique (on doit voir les deux commits)
• comparer des commits
TP #1

28. Branches

29. Branches
Déviation par rapport à la route principale
• Permet le développement de différentes versions en parallèle (en cours, feature, fix,
etc)
• On parle de “merge” lorsque tout ou partie des modifications d’une branche sont
rapatriées dans une autre.
• On parle de “feature branch” pour une branche dédiée au développement d’un
fonctionnalité nouvelle.
Branches

30. Branches
• branch : pointeur sur le dernier commit (sommet) de la branche
• les branches sont de références
• master : branche principale (trunk)
• HEAD : pointeur sur la position actuelle de la working copy
Branches

31. Branches
$ git branch <mybranch> (création)
$ git checkout <mybranch> (s’y positioner)
or
$ git checkout -b <mybranch>
$ git branch
Branches (opérations)

32. Branches
Les branches sont des références vers les commit du sommet de la
branche, on peut donc utiliser les notations ^ou ~ sur la branche
branch1^^ : le grand-père du commit au sommet de la branche 1
on peut aussi le faire sur un tag
Branches (Ancêtres et
Références)

33. Branches
La commande checkout permet de déplacer HEAD sur une autre référence :
(branche, tag, commit …)
$ git checkout <ref> : checkout une référence
$ git checkout -b <branch> : crée une branche et la checkout
Checkout

34. Branches
Permet de déplacer le sommet d’une branche sur un commit particulier,
en “resettant” éventuellement l’index et la working copy
utilisations principales :
● annuler les modifications en cours sur la working copy
● faire “reculer” une branche
● annuler un ou plusieurs derniers commits
Reset

35. Branches
$ git reset [MODE] [COMMIT ID]
$ git reset --soft [COMMIT ID]
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.
$ git reset --hard [COMMIT ID]
Resets the index but not the working tree (i.e., the changed files are preserved but not marked for commit) and reports
what has not been updated. This is the default action.
$ git reset --mixed [COMMIT ID]
Resets the index and working tree. Any changes to tracked files in the working tree since <commit> are discarded.
Reset

36. Branches
Littéralement “étiquette” → permet de marquer / retrouver une version précise du
code source
● git tag -a nom_du_tag -m “message” : crée un tag
● git tag -l : liste les tags
C'est une référence vers un commit
On peut faire un checkout sur un tag (comme une branche ou un commit) → detached
HEAD
Les tags sont des références vers un commit on peut donc utiliser les notations ^ ou ~ pour
un checkout :
$ git checkout mon_tag^^ : on checkout le grand-père du commit du tag (detached
head)
Tag

37. TP
● Créer un nouveau repository Git
● Ajouter un fichier et le commiter
● Ajouter un deuxième fichier et le commiter
● Vérifier l’historique (on doit avoir 2 commits)
● Faire des modifications sur le deuxième fichier et le commiter
● Annuler les modifications du dernier commit
● Vérifier l’historique (on doit avoir 2 commits)
● Créer une branche à partir du 1er commit
● Faire un commit sur la branche
● Vérifier l’historique de la branche (on doit avoir 2 commits)
● Lister les branches (on doit avoir 1 branche)
● Tagger la version
● Revenir au sommet de la branche master
● Lister les tags (on doit avoir un tag)
● Supprimer la branche
● Lister les branches (on doit avoir une seule branche : master)
TP #2

38. Branches (Merge)
Join two or more development histories together
Merge

39. Branches (Merge)
Merge
$ git merge <branch> <branch> [options]

40. Branches (Merge)
Merge with conflict
$ git merge <branch> <branch> [options]

41. Branches (Rebase)
Rebase
$ git rebase <branch> [options]

42. Branches (TP)
TP #3
Merge
● Créer un nouveau repository git
● Ajouter un fichier et le commiter (C1)
● Créer une feature branch B1 à partir de C1
● Faire une modification du fichier et commiter (C2)
● Merger B1 dans master de manière à avoir un commit de merge dans master
Rebase
● Créer un nouveau repository Git
● Ajouter un fichier et le commiter (C1), le modifier et le commiter (C2)
● Créer une branche B1 à partir de C1
● Faire une modification du fichier et commiter C3
● Merger B1 dans master de manière à avoir un historique linéaire

43. Branches (TP)
TP #4
● Créer un nouveau repository Git
● Ajouter un fichier et le commiter (C1)
● Modifier la première ligne du fichier et commiter (C2)
● Créer une feature branch B1 à partir de C1
● Faire une modification de la première ligne du fichier et commiter (C3)
● Merger B1 dans master en résolvant les conflits

44. Working with remote
repository

45. Fundamentals
This is your
REMOTE
repository (On
premises, github,
etc)
UPSTREAM
REPOSITORY

46. Working with remote repository
Remote
Utilisations d’un repository distant :
● Pour partager son travail via un repository central (ex svn / cvs ...)
● Repository read only qu’on peut forker (ex : github)
● Pour déployer son code (ex: heroku)
● Dans Git chaque repository peut être “cloné” (copié) Le repository cloné devient
de fait le repository distant du clone

47. Working with remote repository
Clone
Clone complet du repository distant
branches, tags → tout est cloné
le repository distant peut être exposé via ssh, http, file ...
$ git clone url_du_repository

48. Working with remote repository
Remote (origin)
● C'est la définition d'un repository distant
● Nom + url du repository
● git remote add url_du_repo : ajoute une remote
● Créée par défaut avec clone
● Remote par défaut == origin

49. Working with remote repository
Fetch
$ git fetch [<remote>]
● Met à jour les informations d'une remote
● récupère les commits accessibles par les branches distantes référencées
● met à jour les références des branches distantes
● ne touche pas aux références des branches locales

50. Working with remote repository
Pull
$ git pull
● Equivalent de fetch + merge remote/branch
● Update la branche locale à partir de la branche remote
● Se comporte comme un merge d’une branche locale dans une autre

51. Working with remote repository
Fetch + rebase
$ git fetch
$ git rebase <-i>
● Permet de récupérer les modifications de la remote et de placer les nôtres “au
dessus”
● Plus “propre” que pull → pas de commit de merge
● Se comporte comme un rebase d’une branche locale sur une autre
● Équivalent à $ git pull --rebase (configurable par défaut)

52. Working with remote repository
Push
$ git push
● Publie les commits locaux sur le repository distant
● git status → donne le nombre de commit d'avance / de retard sur la remote
● Refuse de pusher si retard → faire un git fetch puis git rebase -p et
recommencer

53. Working with remote repository
Push
● Par défaut publie tous les commits de la branche courante non présents sur la remote
● On peut publier jusqu'à un commit via :
$ git push nom_remote id_commit:nom_branche_remote

54. Working with remote repository
Push
$ git push -f : force
execute le push même en cas d’historique divergent : notre historique “remplace” celui du
repository distant !!!
Utile pour corriger une erreur de push avant que les autres users n’aient récupéré les
changements
Attention nécessite des interventions de la part des autres utilisateurs s’ils ont updaté
leur repository avant le push -f (ils risquent de merger l’ancien et le nouvel historique)
On préfère généralement faire un revert

55. Working with remote repository
TP #5
Travail en équipe autour d’un projet

56. Pull request

57. Pull/Merge request
Pull request
Generate a request asking your upstream project to pull changes into their tree. The
request, printed to the standard output, begins with the branch description, summarizes the
changes and indicates from where they can be pulled.

58. Pull request
Pull request
$ git request-pull [-p] <start> <url> [<end>]

59. Handy Commands

60. Handy commands
Revert
$ git revert id_du_commit
génère un antécommit == annulation des modifications du commit

61. Handy commands
Blame
$ git blame <file>
Indique l’auteur de chaque ligne d’un fichier

62. Handy commands
Stash
Sauvegarder sa working copy sans commiter (ex : pour un changement de branche
rapide)
$ git stash
Déplace le contenu de la working copy et de l’ index dans une stash
$ git stash list
list des stash
$ git stash pop [stash@{n}]
pop la dernière stash (ou la n-ième)

63. Handy commands
Cherry-pick
$ git cherry-pick id_du_commit
● Prend uniquement les modifications d'un commit (sans historique) et l'applique à la
branche
● A utiliser avec parcimonie (branches sans liens)

64. Scenarios

65. Scenarios
BugFix
● Je suis sur master (sinon git checkout master)
● Je fais mon commit : ajout des fichiers dans l'index via git add puis git commit -m
“mon commit”
● Je récupère les modifications des autres en rebasant master : git fetch && git
rebase :
● Je résous les éventuels conflits puis git rebase -- continue (ou git rebase --abort)
● Mes modifications se retrouvent au sommet de master
● Je publie mon (ou mes) commit(s) : git push

66. Scenarios
Nouvelles fonctionalités
● Exemple : nouvel écran, nouveau batch → plusieurs commits
● Je mets à jour master : git fetch && git rebase
● Je crée et je me place sur ma feature branch : git checkout -b nouvel_ecran
● Je fais mon développement et plusieurs commits sur ma branche
● Je me place sur master et je fais git fetch && git rebase
● Je merge ma branche dans master (sans fast forward) : git merge - no-ff
nouvel_ecran
● Je publie : git push
● Cas particulier : quelqu'un a pushé entre mon merge et mon push → je dois refaire
un git fetch && git rebase -p sinon le rebase va linéariser mon merge
● Je supprime ma feature branch : git branch -d nouvel_ecran

67. Scenarios
Fix en Prod
● Je me place sur la branche de prod : git checkout prod-1.10
● Je mets à jour ma branche locale de prod : git fetch && git rebase
● Je fais ma correction et je commite
● Je mets à jour ma branche local de prod : git fetch && git rebase (conflits
éventuels)
● Je publie mon commit : git push
● Je me place sur master pour reporter ma modification :
● Je mets à jour master : git fetch && git rebase
● Je merge ma branche de prod dans master : git merge prod-1.10
● Dans des cas TRES particuliers (on ne veut qu'un seul commit sans les
précédents) on peut faire un cherry-pick plutôt qu'un merge
● Je publie mon report de commit : git push

68. Scenarios
Création branch de prod
Je me place sur le tip (sommet de la branche) de master (ou sur le commit qui
m'intéresse)
$ git checkout master
Je crée ma branche locale et je l'emprunte :
$ git checkout -b prod-1.10
Je push ma branche :
$ git push -u origin prod- 1.10

69. Scenarios
Références
La cheatsheet http://ndpsoftware.com/git-cheatsheet.html
La documentation https://www.kernel.org/pub/software/scm/git/docs/
Le livre Pro Git http://git-scm.com/book/
Le site Git Magic http://www-cs-students.stanford.edu/~blynn/gitmagic/intl/fr/
Les tutoriels Atlassian https://www.atlassian.com/fr/git/tutorial/
Les articles GitHub https://help.github.com
Simulation graphique des commandes http://pcottle.github.io/learnGitBranching
Code Academy GTI course https://www.codecademy.com