Softilys University Support GIT

Consigne de sécurité
02/2K20 Forma+on So.ilys University 2

FoRmAtEuR : TaReK BeN MeNa
GIT
RoadMap
§  Introduction
§  Architecture
§  Tags
§  Branches
§  Fusion
–  Exercice
§  Rebase
–  Exercice
§  Stash
§  Remote
§  GitFlow
§  Atelier

Introduction
§  Logiciel de gestion de version créé en Avril 2005 par Linus Torvald :
fondateur du Kernel Linux
§  Avril 2013 : Github déclare avoir 3.5 millions d’utilisateurs
§  Mai 2013 : 36% des professionnels utilisent Git comme logiciel de
versioning
§  Mai 2018, Git est acheté par Microsoft
§  Mai 2019 : Github déclare avoir 37 millions d’utilisateurs et plus de

100 millions de dépôts (repositories)

Introduction
§  Pendant la réalisation d’un projet informatique
–  Il y aura plusieurs versions du logiciel
–  Il y a partage du code avec d’autres développeurs
–  La modification du code est fréquente (c’est évident sinon le
développement n’avance pas)
–  Une version qui tourne correctement mais, après une (petite)
modification, plus rien ne fonctionne
§  On a besoin soit de

–  récupérer la dernière version qui fonctionnait
–  savoir
•  qu’est ce qui a été modifié?
•  qui a modifié ?
•  pourquoi ?
•  quand ?
–  publier (partager) une version valide du projet et organiser son projet
par version

2 modèles de VCS : Version Control System
–  Modèle centralisé : le code du logiciel est géré par un serveur
central (Exemple : SVN, CVS)
–  Modèle distribué : tous les développeurs ont accès au code sans
passer par un serveur (Exemple : Git, Mercurial, Bazaar)

SVN vs. Git
§  Sauvegarde des différences
§  Instantanés

Git en Quelques Mots
§  Syntaxe proche de Shell Linux
§  Basée sur des commit (une version valide du code)
§  Permettant de retrouver un fichier supprimé, une ancienne version
modifiée...
§  Acceptant toute extension de fichier (JS, Java, PHP, ASP...)
§  Utilisé par des sites web de partage
–  Github : https://github.com/
–  BitBucket : https://bitbucket.org/
§  Permettant de gérer de projet de taille importante
§  Installation
–  Linux : via le pm en faisant (sudo) apt-get install git
–  MAC : via homebrew (brew install git)
–  Windows : le nouveau lien depuis l’achat par Windows https://
gitforwindows.org/

États de fichier
§  les fichiers peuvent être dans 3 états :
–  Validé : les données sont stockées en sécurité́ dans la BD locale
–  Modifié : fichier modifié mais pas encore validé en base.
–  Indexé : le fichier modifié est marqué dans sa version actuelle pour qu’il
fasse partie du prochain instantané́ du projet.
–  Le répertoire Git : stocke les méta-données et la BD. C’est la partie la plus

importante de Git, c’est ce qui est copié lorsque vous clonez un dépôt
–  Le répertoire de travail est une extraction unique d’une version du projet
placée sur le disque pour pouvoir être modifiés.
–  La zone d’index stocke les informations qui feront partie du prochain
instantané.
États de fichier
–  Un fichier de la copie de travail peut avoir deux états : sous suivi de

version ou non suivi.
•  Les suivis sont ceux qui appartenaient déjà au dernier instantané (ils
peuvent être inchangés, modifiés ou indexés)
•  Tous les autres sont non suivis.
–  Un fichier cloné est sous suivi de version et inchangés, Une fois édité
Git le considère comme modifiés, il faut l'indexer et enregistrer toutes
les modifications indexées
Dépôt
§  C’est un répertoire de travail
–  géré par Git
–  contenant les éléments à partager ou à « commiter »
§  Comment créer un dépôt?

–  créer un répertoire
–  se positionner dedans
–  déclarer ce répertoire comme un dépôt
•  git init

Configuration GIT
§  Configurer un compte Git
§  Pour désactiver la coloration dans la console (par défaut activée)

–  git config --global color.ui false
§  Pour consulter la liste de configurations (et vérifier les

modifications)
–  git config --list
§  Pour vérifier la valeur d’une propriété de configuration

–  git config user.name

1er commit
§  Deux étapes
–  Indexation : ajouter le fichier au Staging Area
–  Validation : valider seulement les fichiers modifiés et indexés
§  Avant indexation, tous les fichiers se trouvent dans le staging area
§  git status -s

–  Les nouveaux fichiers qui ne sont pas suivis sont précédés de ??,
–  les fichiers nouveaux et indexés sont précédés de A,
–  les fichiers modifiés de M et ainsi de suite

1er Commit
§  Vérification du contenu d’un dépôt
§  Création d’un fichier

1er Commit
§  Vérification du contenu d’un dépôt
§  Création d’un fichier

1er commit
§  Edition du fichier
§  Indexation du fichier

–  git add file.txt ou git add . ou git add --all

1er commit
§  Commit du fichier
§  Vérification du contenu
§  Pour un 2ème commit

–  Refaire les deux étapes précédentes : indexation et validation
–  Fusionner les deux étapes

Les autres commits
§  Une nouvelle modification dans le fichier
§  Vérification du dépôt
§  Commiter

Afficher les commits
§  L’historique
§  Pour afficher seulement les deux dernier commit

–  git log -2
§  Afficher les points de différences avec le commit précédent

§  Afficher les commits sous forme de graphe
§  Les points de différences entre deux commits
§  La différence d’un Commit avec le staging area

–  git diff idCommit1

Naviguer entre les commits
§  Vérifier le contenu d’un fichier dans un commit précédent
§  On peut faire aussi

–  git checkout HEAD^^^ : HEAD^^^: 3ème ancêtre du commit actuel
–  Ou git checkout HEAD~3
–  Ou git checkout idCommit^^^ : idCommit^^^ 3ème ancêtre du
commit précisé
–  Ou git checkout idCommit~3
§  Pour pointer sur le dernier commit sans préciser son identifiant
–  git checkout master
Naviguer entre les commits
§  Exemple

Modifier le message du Commit
§  Avec l’argument m
–  git commit --amend –m "second commit »
§  Ou
§  [vim] Mode insert avec i et sauvegarde avec :wq

Annulation d’un commit
§  Etape 1 : Créer un 2ème fichier file2.txt et faire un 3ème Commit
avec le message "creating file2.txt »
§  Ajouter une 3ème ligne « third » dans file.txt et faire un 4ème
Commit avec le message «third»
§  Ajouter une 4ème ligne « fourth » dans file.txt et faire un 5ème
Commit avec le message «fourth»

Annulation d’un commit
§  Vérification des modifications
§  Comment annuler le commit ayant comme message creating file2.txt

–  git revert idCommit
§  Vérifier l’annulation

Supprimer des modifications
§  Trois possibilités
–  Annuler le commit et garder les modifications dans le working
directory (mode mixed : par défaut)
–  Annuler le commit et garder les modifications dans le staging
area (mode soft)
–  Annuler le commit et ne pas garder les modifications (mode hard)
§  Syntaxe
–  git reset --mode idCommit
§  Exemple
–  git reset --hard idCommit
§  Explication
–  Tous les Commit réalisés après le commit ayant comme identifiant
idCommit seront annulés et impossible de les récupérer.
–  En faisant git status, il n’y a rien à indexer ni à valider.

Supprimer les modifications : mixed
§  Exemple

Supprimer les modifications : soft
§  Exemple

Supprimer les modifications : hard
§  Exemple

TAGS

Les Tags (étiquette)
§  Problématique
–  Pour accéder à un commit qui présente une version importante de notre
projet
–  Il faut chercher le commit en question en lisant les messages de tous les
Commit, et ensuite faire git checkout
§  Solution : utiliser les étiquettes (tags)
§  Les tags, c’est quoi ?

–  une étiquette : permet de marquer un Commit/une version de l’application
–  référence vers un Commit
§  Syntaxe de création d’un tag sur le Commit actuel

–  git tag -a nom-tag -m "message"
Exemple
–  git tag -a v0 -m "premiere version du projet"
§  Syntaxe de création d’un tag sur un commit par son identifiant
–  git tag -a nom-tag idCommit -m "message"
Exemple
–  git tag -a v0 6ded57e -m "premiere version du projet"

Les Tags (étiquette)
§  2 types de Tag :
–  léger (un pointeur sur un commit spécifique)
–  annoté (stocké comme objet avec des méta données)

Tags
§  Exemple : Créer, lister et modifier message d’un tag

Tags
§  Exemple : naviguer dans les tags et supprimer un tag
§  Chercher les é+queEes

correspondant à un mo+f par+culier

LES BRANCHES

Les branches
§  Les branches, déjà : master est une branche principale
–  contenant seulement des Commit représentant les différentes
versions de notre application
–  Comment faire alors? ⇒ Créer des branches et les utiliser
§  Une branche,

–  c’est quoi? déviation par rapport à la branche principale pointeur
sur le dernier Commit
–  Quand? développer une nouvelle fonctionnalité, préparer une
correction
§  Pour créer une branche

–  git branch nom-branche
§  Changer de branche
–  git checkout nom-branche
§  Créer et changer de branche
–  git checkout -b nom-branche
Les branches
§  Remarque 1
–  En créant une branche, cette dernière pointe sur le commit à partir
duquel elle a été créée
§  Remarque 2
–  En faisant un Commit à partir de la branche créée, cette dernière
dévie de la branche principale
§  Pour lister les branches locales

–  git branch --list
§  Ou tout simplement
–  git branch
§  Pour lister les branches (avec l’identifiant du dernier commit de
chaque branche)
–  git branch -v

Les branches
§  Pour lister les branches distantes
–  git branch -r
§  Ou aussi
–  git branch --all
§  Pour supprimer une branche vide (ou fusionnée)

–  git branch -d nom-branche
§  Pour forcer la suppression d’une branche

–  git branch -D nom-branche

Branche : Cas
$ git add README test.rb LICENSE
$ git commit -m 'initial commit of my project'
§  Le dépôt Git contient 5 objets :

–  un blob pour le contenu de chacun de vos trois fichiers,
–  un arbre (tree) qui liste le contenu du répertoire et spécifie quels noms
de fichiers sont attachés à quels blobs
–  un objet commit portant le pointeur vers l’arbre de la racine ainsi que
toutes les méta-données attachées au commit.
Branche : en bref
§  Chaque commit stocke un pointeur vers le commit le précédant
§ Une branche est simplement un pointeur

léger et déplaçable vers un commit

Branche : en bref
$ git branch testing
–  HEAD : un pointeur spécial pour savoir sur

quel branche on se trouve
$ git log --oneline --decorate

f30ab (HEAD, master, testing) add feature #32 - ability to add new
34ac2 fixed bug #ch1328 - stack overflow under certain conditions
98ca9 initial commit of my project
$ git checkout testing

Branche : en bref
$ vim test.rb
$ git commit -a -m 'made a change'
$ git checkout master

Branche : en bref
$ vim test.rb
$ git commit -a -m 'made other changes'
$ git log --oneline --decorate --graph --all

* c2b9e (HEAD, master) made other changes
| * 87ab2 (testing) made a change
|/
* f30ab add feature #32 - ability to add new formats to the
* 34ac2 fixed bug #ch1328 - stack overflow under certain conditions
* 02/2K20
98ca9 initial commit of my project
Forma+on So.ilys University 45
FUSION

Situation
§  Vous effectuez les tâches suivantes :
1.  vous travaillez sur un site web ;
2.  vous créez une branche pour un nouvel article en cours ;
3.  vous commencez à travailler sur cette branche.
§  À cette étape, vous recevez un appel pour vous dire qu’un problème
critique a été découvert et qu’il faut le régler au plus tôt. Vous faites
donc ce qui suit :
1.  vous basculez sur la branche de production ;
2.  vous créez une branche pour y ajouter le correctif ;
3.  après l’avoir testé, vous fusionnez la branche du correctif et
poussez le résultat en production ;
4.  vous rebasculez sur la branche initiale et continuez votre travail.

Branches & Fusion
1.  vous travaillez sur un site web
2.  vous créez une branche pour un nouvel article en cours ;

$ git checkout -b iss53
Switched to a new branch "iss53"
3.  vous commencez à travailler sur cette branche.

$ vim index.html
$ git commit -a -m "ajout d'un pied de page [problème 53]"

Branches & Fusion
§  Réception d’un appel : problème sur le site
–  Il faut revenir à la branche master (on suppose que tous les
changements sur la branche sont validés)
Switched to branch 'master’
$ git checkout -b hotfix
Switched to a new branch 'hotfix'
$ vim index.html
$ git commit -a -m "correction de l'adresse email incorrecte"
[hotfix 1fb7853] "correction de l'adresse email incorrecte"
1 file changed, 2 insertions(+)

Branches & Fusion
§  Une fois le travail de correction terminer il faut le fusionner dans la
branche master pour la déployer en production
–  Revenir à la branche où il y aura fusion & git merge nom-branche
$ git merge hotfix
Updating f42c576..3a0874c
Fast-forward
index.html | 2 ++
1 file changed, 2 insertions(+)'
fast-forward : Comme le commit C4 pointé par hotfix (branche

fusionnée) était directement devant le commit C2 (HEAD), Git a
simplement déplacé le pointeur (vers l’avant)
§  il faut supprimer la branche hotfix

$ git branch -d hotfix
Deleted branch hotfix

Branches & Fusion
§  Et retourner à la branche de dev iss53
$ git checkout iss53
Switched to branch "iss53"
$ vim index.html
$ git commit -a -m 'Nouveau pied de page terminé [issue 53]'
[iss53 ad82d7a] Nouveau pied de page terminé [issue 53]
1 file changed, 1 insertion(+)
Noter que le travail réalisé dans la branche hotfix n’est pas

contenu dans les fichiers de la branche iss53.
git merge master permettra de les rapatrier sur iss53

Fusions (Merges)
Une fois le travail sur la branche dev iss53 est
terminé, il sera fusionné
$ git checkout master Il faut migrer vers la branche à laquelle on souhaite
Switched to branch 'master' fusionner
$ git merge iss53 git merge --no-ff nom-branche
Merge made by the 'recursive' strategy.
README | 1 +
1 file changed, 1 insertion(+)
three-way merge : Au lieu d’avancer simplement le

pointeur, Git crée un nouvel instantané qui résulte de la
fusion à trois sources et crée automatiquement un
nouveau commit (merge commit)
$ git branch -d iss53

Conflits de fusions
§  Si lors de la fusion Git trouve deux versions d'une même partie d'un
fichier sur les deux branches. un conflit sera détecté
$ git merge iss53
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
$ git status
On branch master
You have unmerged paths.
(fix conflicts and run "git commit") Tout ce qui comporte des conflits et n’a pas
été résolu est listé comme unmerged
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: index.html
no changes added to commit (use "git add" and/or "git commit -a")

Rappel : Gestion des branches
§  Lister les branches $ git branch
iss53
* master
testing
§  Lister les branches avec le dernier commits de chacune

$ git branch -v
iss53 93b412c fix javascript issue
* master 7a98805 Merge branch 'iss53'
test 782fd34 add scott to the author list in the readmes
§  Pour lister les branches fusionnées et non fusionnées

$ git branch --merged
iss53 On peut supprimer les branches déjà
* master fusionnées avec git branche -d
$ git branch --no-merged
test
$ git branch -d test

error: The branch 'test' is not fully merged.
If you are sure you want to delete it, run 'git branch -D test'.

Les branches
§  branches dans un processus de stabilité progressive
Master : pour le code en+èrement stable et Develop ou next pour les développements en
testé (ou bien même uniquement du code qui cours qui font encore l’objet de tests de
a été ou sera publié au sein d’une release) stabilité (pas toujours stable)
Topic : (de faible durée de vie), intégrée dans

develop une fois prêtes, (passent l’intégralité
des tests et n’introduisent pas de bugs).
Exemple Branche topic
Une autre idée de résoudre
§  Soit l’historique suivant le problème #91
Pour résoudre le
problème #91
Entre temps on a

avancé sur le master
Une idée dont je doute

de sa per+nence .

Exemple : Branche topic
§  On décide de garder la solution v2
pour le problème #91
§  Que mon « idée idiote » semble

géniale
§  En jetant la branche iss9, on perds

les commits C5 et C6

Pour résumer la Fusion
§  Problématique
–  Lors de l’élaboration d’un projet, plusieurs branches seront créées,
chacune pour une tâche bien particulière
–  Solution : fusionner les branches et rapatrier les modifications
d’une branche dans une autre
§  Fusion : deux cas possibles

–  sans conflit
•  fast forward : sans commit de fusion
•  non fast forward (avec l’option --no-ff) : avec un commit de
merge
–  avec conflit : avec un commit de merge

Pour résumer la fusion
§  étapes
–  Exécuter la commande git merge nom-branche
–  Résoudre le conflit en modifiant le(s) fichier(s) de conflit
–  Faire un Commit de merge

Fusion : Annulation
§  On peut annuler l’opération sans faire le commit de merge (après la
détection un conflit)
–  git merge --abort
–  git reset --merge
–  git reset --hard HEAD
§  On peut toujours annuler le merge

–  git reset --hard HEADˆ

Exercice 1
§  Créer un nouveau repository Git
§  Ajouter un fichier et le commiter (C1)
§  Créer une branche (B1) à partir de C1
§  Faire un checkout sur B1
§  Modifier le fichier et faire un Commit (C2)
§  Merge B1 dans master de manière à avoir un Commit de merge

dans master

Exercice 2
§  Modifier le fichier et le commiter (C2)
§  Modifier le fichier et faire un Commit (C3)
§  Merge B1 dans master en résolvant le conflit

REBASE

Rebase
§  Problème de la fusion
–  Des cycles, des fois, inutiles
–  Des Commit de merge non nécessaires
–  Solution : rebase
§  Le rebase, permet de

–  manipuler l’historique en réécrivant le passé
–  linéariser le graphe de commit
•  en évitant les Commit de merge et
•  en fusionnant les Commit d’une même branche dans un seul
Commit

Merge vs. Rebase
merge
rebase
Rebase : prendre toutes les modifications

qui ont été validées sur une branche et les
rejouer sur une autre.
$ git checkout experiment

$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command
Rebase
§  Fonctionnement
–  Git cherche l’ancêtre commun le plus récent des deux branches
–  en récupérant toutes les différences introduites par chaque commit de
la branche courante,
–  en les sauvegardant dans des fichiers temporaires,
–  en réinitialisant la branche courante sur le même commit que la
branche de destination et
–  en appliquant finalement chaque modification dans le même ordre.

$ git merge experiment

Rebase : exemple

Rebase : exemple

Rebase avancé
§  soit un historique avec deux branches thématiques
qui sortent l’une de l’autre
$ git rebase --onto master server client
Extraire la branche client, déterminer les

patchs depuis l’ancêtre commun des
branches client et server puis les rejouer
sur master
Rebase avancé
$ git merge client
–  On décide de tirer (pull) la branche server aussi. Il est possible de

rebaser la branche server sur la master sans avoir à l’extraire avant
$ git rebase master server

$ git merge server
$ git branch -d client
$ git branch -d server

Ne rebasez jamais des commits qui ont déjà
été "pushé" sur un dépôt public.
DANGER REBASE

Danger du rebase
§  On a Cloné un dépôt et baser
du travail dessus
§  Un collaborateur travaille et

inclut une fusion et push ce
travail sur le serveur central.
§  On récupère et on fusionne

la nouvelle branche distante.

Danger du rebase
§  Ensuite, le collaborateur
décide de faire marche
arrière et de rebaser son
travail.
$ git push --force
§  pour forcer l’écrasement de
l’historique sur le serveur.
§  On récupéré alors les
données du serveur, qui
amènent les nouveaux
commits.
§  On est dans le pétrin L. Si

on fait un git pull, on
créera un commit de fusion
incluant les deux historiques
et le dépôt local ressemblera
à ça :
Exercice 3
§  Modifier le fichier et le commiter (C2)
§  Créer un nouveau fichier et faire un Commit (C3)
§  Afficher le graphe
§  Merge B1 dans master de manière à avoir un historique linéaire
§  Afficher le graphe

VOYAGER ET MODIFIER LE
PASSÉ

Rebase interactif
§  inverser l’ordre de deux ou plusieurs Commit
§  modifier le message d’un Commit
§  supprimer un Commit
§  fusionner plusieurs Commit en un seul
§  Comment ?
–  git rebase -i idCommit

Rebase interactif
§  Comment fusionner plusieurs Commit ? Commençons par
–  Créer un fichier c.txt et faire un Commit
–  Créer un fichier d.txt et faire un Commit
–  Créer un fichier e.txt et faire un Commit
$git log --oneline

e8058fc (HEAD -> master) commit e
ff2c409 commit d
5960613 commit c

Rebase interactif
§  Pour fusionner les trois derniers Commit
–  git rebase -i HEAD ̃3
§  [vim] Les trois premières lignes affichées
–  pick 5960613 commit c
–  pick ff2c409 commit d
–  pick e8058fc commit e
§  Dans vim

–  cliquer sur i pour avoir le mode INSERTION
–  remplacer pick de deux derniers Commit par squash
–  cliquer sur echap, saisir :wq et cliquer sur entree
§  Vérifier les changements

–  git log --oneline

Rebase interactif
§  Comment supprimer des Commit ?
–  créer un fichier f.txt et faire un Commit
–  créer un fichier g.txt et faire un Commit
–  créer un fichier h.txt et faire un Commit
§  En faisant git log --oneline
–  e8058fc (HEAD -> master) commit h
–  ff2c409 commit g
–  5960613 commit f

Rebase interactif
§  Pour supprimer des Commit
§  [vim] Les trois premières lignes affichées
–  pick 5960613 commit f
–  pick ff2c409 commit g
–  pick e8058fc commit h
§  Dans vim
–  remplacer pick par drop pour les Commit à supprimer
–  cliquer sur echap,
–  saisir :wq et cliquer sur entree

Rebase interactif
§  Comment renommer un Commit ?
§  Commençons par créer un fichier i.txt et faire un Commit

–  e8058fc (HEAD -> master) commit i

rebase
§  Pour renommer un Commit
§  [vim] La première ligne affichée

–  pick e8058fc commit i
§  Dans vim

–  remplacer pick par reword et modifier le message
–  cliquer sur echap,
–  saisir :wq et cliquer sur entree


rebase
§  Comment inverser l’ordre des Commit ?
–  créer un fichier j.txt et faire un Commit
–  créer un fichier k.txt et faire un Commit
–  créer un fichier l.txt et faire un Commit

–  e8058fc (HEAD -> master) commit l
–  f2c409 commit k
–  5960613 commit j

rebase
§  Pour inverser des Commit
§  Les trois premières lignes affichées
–  pick 5960613 commit j
–  pick ff2c409 commit k
–  pick e8058fc commit l
§  Dans vim
–  placer le curseur au début du Commit à déplacer
–  puis cliquer sur dd pour le couper
–  cliquer sur p pour coller le Commit copié
–  cliquer sur echap, saisir :wq et cliquer sur entree

Réécrire l’histoire : filter-branche
§  Pour réécrire un grand nombre de commits de manière scriptable
–  Supprimer un fichier de tous les commits
$ git filter-branch --tree-filter 'rm -f passwords.txt' HEAD
Rewrite 6b9b3cf04e7c5686a9cb838c3f36a8cb6a0fc2bd (21/21)
Ref 'refs/heads/master' was rewritten
•  --tree-filter exécute la commande pour chaque commit

–  supprimer tous les fichiers temporaires
$git filter-branch --tree-filter "find * -type f -name '*~' -delete"
HEAD
–  Modifier un email
$ git filter-branch --commit-filter '
if [ "$GIT_AUTHOR_EMAIL" = "schacon@localhost" ];
then
GIT_AUTHOR_NAME="Scott Chacon";
GIT_AUTHOR_EMAIL="schacon@example.com";
git commit-tree "$@";
else
git commit-tree "$@";
fi' HEAD

Problématique
•  Des travaux non-finis (qu’on ne peut valider)
•  Nécessité de publier des travaux validés (d’une autre branche)
•  Impossible de changer de branche sans supprimer les
modifications courantes
•  ⇒ Solution : utiliser la planque (stash) pour mettre les travaux
encours de coté
STASH

Stash
§  Exemple : sur la branche master
echo bonjour > fichier1.txt # crée et ajoute bonjour dans fichier.txt
echo bonsoir > fichier2.txt
git add . # indexer les deux fichiers
git commit -m "first commit"
git checkout -b ma-branche
§  Exemple : sur la branche ma-branche

echo hello >> fichier1.txt
git commit -am "second commit for fichier1"
echo ciao >> fichier1.txt #
§  Impossible de changer de branche car on n’a pas validé les

dernières modifications
error: Your local changes to the following files would be overwritten
by checkout:
file1.txt
Please commit your changes or stash them before you switch branches.
Aborting

Stash
§  Pour ajouter un (ou plusieurs) fichier(s) au stash
–  git stash save
§  Si le fichier modifié se trouve dans le staging area
–  git stash push
§  Pour afficher le contenu de la planque
–  git stash list
§  Pour récupérer un fichier dy stash et y garde une copie
–  git stash apply
§  Pour vider la planque
–  git stash drop
§  Pour récupérer un fichier de la planque sans qu’une copie y reste
–  git stash pop
§  On peut préciser le nom du fichier à ajouter et donner un nom au
stash au moment de l’ajout, ce qui nous permettra de traiter les
fichiers un par un
Stash : exemple
§  Exemple

Stash : exemple

Stash
§  Mode interactif

Le fichier .gitignore
§  Idée
–  Si on a un (ou plusieurs) fichier(s) (de configuration par exemple)
qu’on ne voit aucun intérêt de les valider
–  On peut les citer dans un fichier de configuration appelé .gitignore
–  Un nom par ligne
–  Ce fichier peut être indexé et validé
§  Exemple
echo informatique.txt >> .gitignore
echo *.html >> .gitignore
echo view/* >> .gitignore
echo java >> informatique.txt
§  Explication
–  En faisant git status, aucun fichier à indexer à l’exception
de .gitignore
–  Tous les fichiers avec l’extension html sont ignorés Aussi,
–  tous les fichiers du répertoire view

§  Les règles de construction des patrons à placer dans le
fichier .gitignore sont les suivantes :
–  les lignes vides ou commençant par # sont ignorées ;
–  les patrons standards de fichiers sont utilisables ;
–  si le patron se termine par une barre oblique (/), il indique un
répertoire ;
–  un patron commençant par un point d’exclamation (!) indique des
fichiers à inclure malgré les autres règles.

# pas de fichier .a
*.a
# mais suivre lib.a malgré la règle

précédente
!lib.a
# ignorer uniquement le fichier TODO à

la racine du projet
/TODO
# ignorer tous les fichiers dans le

répertoire build
build/
# ignorer doc/notes.txt, mais pas doc/

server/arch.txt
doc/*.txt
# ignorer tous les fichiers .txt sous

le répertoire doc/
doc/**/*.txt

L’historique du pointeur HEAD
§  Pour connaître le journal du pointeur HEAD
–  git reflog
§  Pour avoir un peu plus de détails
–  git log -g

REMOTE

Dépôt nu
§  dépôt sans espace de travail (en lecture seule) pas de Commit
possible
§  une sorte de serveur pour tous les utilisateurs
§  Créer un répertoire

–  mkdir firstGitBare
§  Se placer dans ce répertoire
–  cd firstGitBare
§  Créer un dépôt nu
–  git init --bare
§  Dépôt distant?
–  Dépôt nu, site hébergeur (GitHub, Bitbucket...)...

Dépôt distant
§  À partir de notre premier dépôt (firstGit), créer un premier dépôt
distant
–  git remote add origin /cheminVers/firstGitBare
§  Afficher la liste des dépôts distants
–  git remote
§  Afficher les branches distantes
§  Envoyer (publier) la branche master sur le dépôt distant
–  git push origin master
§  Afficher les branches distantes
§  Ou aussi
–  git branch -a
§  Supprimer une branche distante
–  git push origin --delete nomBranche

Dépôt distant
§  Pour supprimer un remote
–  git remote remove nomRemote
§  Pour renommer un remote
–  git remote rename oldName newName
§  Cloner le dépôt firstGit dans firstGitClone
–  Se placer dans le parent du dépôt courant cd ..
–  git clone /cheminVers/firstGitBare firstGitClone
§  Se placer dans le répertoire cloné
–  cd firstGitClone
§  Vérifier le dépôt distant
–  git remote -v
§  Vérifier les Commit

Cloner un dépôt
§  Préparer un nouveau Commit
–  echo bonjour >> new.txt
–  git add .
–  git commit -m "adding new.txt »
§  Publier le commit dans firstGitBare

–  git push origin master
§  Pour récupérer le Commit depuis firstGit

–  git pull origin master

Git - commands
§  Zones contenant les différences
dossier de travail, où on Zone locale contenant
modifie les fichiers tous les commits
Une zone temporaire

permettant le
déplacement des fichiers Zone distante (GitLab)
Zone dans la quelle se trouvent les
contenant tous les
fichiers qui vont être commités par
02/2K20 Forma+on So.ilys University commits 101
le prochain commit
Exercice 4
§  Créer un nouveau repository GitHub (R1)
§  Cloner le repository (R2)
§  Lister toutes les branches locales et distantes
§  Sur R1, modifier le fichier et commiter (C2)
§  Sur R2, récupérer C2
§  Vérifier avec git log
§  Sur R2, créer une branche B1
§  Aller sur B1, modifier le fichier et commiter (C3)
§  Publier B1 sur R1
§  Créer une branche B2 sur R1
§  Récupérer B2 sur R2
§  Dans R2, aller sur B2
§  Tagger B2 sur R2 (T1)
§  Publier T1 sur R1
§  Vérifier que T1 est sur R1
§  Sur R1 B1, modifier la première ligne du fichier et commiter (C4)
§  Sur R2 B1, modifier la première ligne du fichier et commiter (C5)
§  Publier C5 sur R1 (conflit)
§  Résoudre le conflit
§  Vérifier la présence d’un commit de merge sur R1 B1

GIT FLOW

System branching
§  master : principal peu de
commit , version destiné à
la production (stable)
§  develop : sur laquelle tous
les développeurs
travaillent, plusieurs
commit (non stable)
§  feature branche : travailler
de manière isolé è
fusionné vers develop
§  Si le projet atteint un
certain niveau on va créer
une release sur la branche
release
§  Si la release est
satisfaisante è merger sur
la master avec un tag et la
merger sur develop
§  Hotfixes : petit bug facile à
corriger
Le nom du branche doit commencer par le nom du +cket JIRA, exp :
BCUTOOLS-‐588:maj login
Git flow

Git flow

Git CheatSheet

Git CheatSheet

Git CheatSheet

Git CheatSheet

Git CheatSheet

L’atelier permet de simuler le scénario suivant: 2
développeurs Titi et Sylvestre qui avancent sur des
taches en parallèles et synchronisent leurs travaux
avec un repository central:
ATELIER

Situation
1.  Titi initie le projet et le synchronise
avec le repository central
2.  Sylvestre récupère le projet initié
3.  Les deux développeurs
commencent leurs
développements respectifs:
Sylvestre la couche web Repo
(Controller) et Titi la couche GitLab
service.
4.  Sylvestre termine ses devs et
synchronise son travail avec le
repository central
5.  Titi termine ses devs, il essai de
faire son « push ». Il découvre que
la branche master distante a
évolué́, essai alors de récupérer le
travail de Sylvestre, mais git
détecte un conflit.
6.  Titi résout le conflit et fait le push

Etape 1: initialisation du projet
§  Initialiser un projet
§  Sauvegarder des modifications
§  Inspecter un repository
§  Manipuler les commandes git suivantes:
–  git init
–  git config
–  git remote,
–  git remote add ︎
–  git status
–  git add
–  git commit
–  git push

Etape 1
Vérifier les prérequis de l'atelier:
•  Le repository central existe et qu'il est bien accessible
•  (h4p://192.168.6.146/university-‐soAilys/S2/tp-‐git)
1 •  L’ou+llage suivant est installé :
•  Gitbash ou équivalent
•  ou+l de ges+on de conflit (Meld ou équivanlent)
•  Le devtoolkit est en place (eclipse, java, maven)
Commençons par créer le dossier « repo-‐++ » du premier
2
développeur
Générer le projet u+lisant h4p://start.spring.io/ , le dezipper et
3
l’importer au niveau d’eclipse
4 Parcourir le code généré́, le fichier .gi+gnore
Créer un repo git u+lisant la commande git init et parcourir
5
rapidement le dossier .git créé
Configurer les paramètres de l'u+lisateur Ti+ u+lisant les
6
commandes git config
Configurer une connexion au repository distant u+lisant la
7
commande git remote add
Ajouter les fichiers du projet au staging area u+lisant la
8
commande git add
9 Commiter les fichiers déjà placés en staging u+lisant git commit
Push les changements dans le repo local vForma+on
ers le repo distant
10 02/2K20 So.ilys University 115
u+lisant la commande git push
Etape 2: Les tâches du 1er développeur
§  Cloner un repo existant distant
§  Manipuler les branches
§  Effectuer un merge
§  Manipuler les commandes git suivantes:
–  git clone
–  git branch
–  git checkout, git checkout –b ︎
–  git log
–  git merge

11 Créer le dossier « repo-‐Sylvestre » du deuxième développeur
Sylvestre va cloner le repo distant u+lisant la commade git clone. CeEe commande permet d'ini+aliser
12
un nouveau repository en local et de le peupler avec le contenu dans le repo distant
13 Configurer les paramètre du développeur Sylvestre u+lisant la commande git config
14 Afficher l'état du working dir et du staging area u+lisant la commande git status
Sylvestre a pour tâche de créer la couche Controller. Pour ce faire, il va commencer par créer une
15
branche u+lisant git branch ou git checkout -‐b
Effectuer les modifica+ons au niveau du code
package tn.softilys.university.person.web;
import org.junit.Test; 
import org.junit.runner.RunWith; 
import org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest; import
org.springframework.test.context.junit4.SpringRunner;
@RunWith(SpringRunner.class) @WebMvcTest(PersonController.class) public class
16 PersonControllerTest {
@Test 
public void getPerson_returnPersonDetails() throws Exception {
}
}
------------------ 
package tn.softilys.university.person.web;
public class PersonController { }
17 Vérifier que le code fonc+onne u+lisant mvn clean install

18 Commiter avec un commentaire significa+f et visualiser l’historique u+lisant la commande git log
Con+nuer avec le reste des modifica+ons package tn.so.ilys.university.person.web;
import org.springframework.http.ResponseEntity; 
import org.springframework.web.bind.annotation.GetMapping; import
org.springframework.web.bind.annotation.PathVariable; import
org.springframework.web.bind.annotation.RestController; import
tn.softilys.university.person.domain.Person; 
import tn.softilys.university.person.service.PersonService;
@RestController 
public class PersonController {
private PersonService service;
19 public PersonController(PersonService service) { this.service = service;
}
} 
----------------------------------- 
package tn.softilys.university.personhak.service;
import org.springframework.stereotype.Service; import
tn.softilys.university.personhak.domain.Person;
@Service 
public class PersonService {
public Person getPersonDetails(String anyString) { return null; 
}}

package tn.softilys.university.person.domain;
public class Person { private String email; private String fname; private String
lname;
public Person(String email, String fname, String lname) { this.email = email; 
this.fname = fname; 
this.lname = lname;
}
public String getEmail() { return email; 
}
public void setEmail(String email) { this.email = email; 
20 }
public String getFname() { return fname; 
}
public void setFname(String fname) { this.fname = fname; 
}
public String getLname() { return lname; 
}
public void setLname(String lname) { this.lname = lname; 
} 
}
Merger son travail avec la branche master et pusher au niveau du repo central. Une fois le
21
travail fait, il est possible de supprimer la branche en ques+on

Etape 2: Les tâches du 2ème développeur
§  Travail collaboratif
§  Pratiquer quelques techniques de reprise d’erreurs
§  Gérer des conflits
§  Manipulation les commandes git suivantes:
–  git pull
–  git commit --amend ︎
–  git mergetool

Etape 2: Les tâches du 2ème développeur
Entre temps, lorsque Sylvestre avançait sur ses taches, TiTi était en train d’avancer sur les siennes
22
de façon parallèle. Pour ce faire il créé la branche pour son feature
23 Effectue les implémenta+ons nécessaires (voir slide suivant) sur une branche dédiée
24 Compile son travail et vérifie qu’il n’y a pas d’erreurs

Commiter son travail en local, u+lise l’op+on de commit amend pour améliorer le log du code déjà
commité
25 Essai de pusher et découvre que le repo distant a évoluer
Faire un pull ou un pull -‐-‐rebase. Ceci va générer un conflit: git n’arrive pas à merger
26
automa+quement certaines modifica+ons
27 Configurer un ou+l de ges+on des conflits et gérer le conflit en ques+on
28 TiTi push son travail après ges+on de conflit, au niveau du repo distant

Softilys University Support GIT

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Softilys University Support GIT

Transféré par

Droits d'auteur :

Formats disponibles

Consigne de sécurité

02/2K20 Forma+on So.ilys University 2

02/2K20 Forma+on So.ilys University 4

§ Avril 2013 : Github déclare avoir 3.5 millions d’utilisateurs

§ Mai 2018, Git est acheté par Microsoft

§ Mai 2019 : Github déclare avoir 37 millions d’utilisateurs et plus de

02/2K20 Forma+on So.ilys University 5

§ On a besoin soit de

02/2K20 Forma+on So.ilys University 6

02/2K20 Forma+on So.ilys University 7

02/2K20 Forma+on So.ilys University 8

02/2K20 Forma+on So.ilys University 9

– Le répertoire Git : stocke les méta-données et la BD. C’est la partie la plus

– Un fichier de la copie de travail peut avoir deux états : sous suivi de

§ Comment créer un dépôt?

02/2K20 Forma+on So.ilys University 12

§ Pour désactiver la coloration dans la console (par défaut activée)

§ Pour consulter la liste de configurations (et vérifier les

§ Pour vérifier la valeur d’une propriété de configuration

02/2K20 Forma+on So.ilys University 13

§ git status -s

02/2K20 Forma+on So.ilys University 14

§ Création d’un fichier

02/2K20 Forma+on So.ilys University 15

§ Création d’un fichier

02/2K20 Forma+on So.ilys University 16

§ Indexation du fichier

02/2K20 Forma+on So.ilys University 17

§ Vérification du contenu

§ Pour un 2ème commit

02/2K20 Forma+on So.ilys University 18

§ Vérification du dépôt

02/2K20 Forma+on So.ilys University 19

§ Pour afficher seulement les deux dernier commit

02/2K20 Forma+on So.ilys University 21

§ Les points de différences entre deux commits

§ La différence d’un Commit avec le staging area

02/2K20 Forma+on So.ilys University 22

§ On peut faire aussi

02/2K20 Forma+on So.ilys University 24

§ [vim] Mode insert avec i et sauvegarde avec :wq

02/2K20 Forma+on So.ilys University 25

02/2K20 Forma+on So.ilys University 26

§ Comment annuler le commit ayant comme message creating file2.txt

§ Vérifier l’annulation

02/2K20 Forma+on So.ilys University 27

02/2K20 Forma+on So.ilys University 28

02/2K20 Forma+on So.ilys University 29

02/2K20 Forma+on So.ilys University 30

02/2K20 Forma+on So.ilys University 31

02/2K20 Forma+on So.ilys University 32

§ Les tags, c’est quoi ?

§ Syntaxe de création d’un tag sur le Commit actuel

02/2K20 Forma+on So.ilys University 33

02/2K20 Forma+on So.ilys University 34

02/2K20 Forma+on So.ilys University 35

§ Chercher les é+queEes

02/2K20 Forma+on So.ilys University 36

02/2K20 Forma+on So.ilys University 37

§ Une branche,

§ Pour créer une branche

§ Pour lister les branches locales

02/2K20 Forma+on So.ilys University 39

§ Pour supprimer une branche vide (ou fusionnée)

§  Avril 2013 : Github déclare avoir 3.5 millions d’utilisateurs

§  Mai 2018, Git est acheté par Microsoft

§  Mai 2019 : Github déclare avoir 37 millions d’utilisateurs et plus de

§  On a besoin soit de

–  Le répertoire Git : stocke les méta-données et la BD. C’est la partie la plus

–  Un fichier de la copie de travail peut avoir deux états : sous suivi de

§  Comment créer un dépôt?

§  Pour désactiver la coloration dans la console (par défaut activée)

§  Pour consulter la liste de configurations (et vérifier les

§  Pour vérifier la valeur d’une propriété de configuration

§  git status -s

§  Création d’un fichier

§  Création d’un fichier

§  Indexation du fichier

§  Vérification du contenu

§  Pour un 2ème commit

§  Vérification du dépôt

§  Pour afficher seulement les deux dernier commit

§  Les points de différences entre deux commits

§  La différence d’un Commit avec le staging area

§  On peut faire aussi

§  [vim] Mode insert avec i et sauvegarde avec :wq

§  Comment annuler le commit ayant comme message creating file2.txt

§  Vérifier l’annulation

§  Les tags, c’est quoi ?

§  Syntaxe de création d’un tag sur le Commit actuel

§  Chercher les é+queEes

§  Une branche,

§  Pour créer une branche

§  Pour lister les branches locales

§  Pour supprimer une branche vide (ou fusionnée)

§  Pour forcer la suppression d’une branche

§  Le dépôt Git contient 5 objets :

§ Une branche est simplement un pointeur

–  HEAD : un pointeur spécial pour savoir sur

2.  vous créez une branche pour un nouvel article en cours ;

3.  vous commencez à travailler sur cette branche.

§  il faut supprimer la branche hotfix

§  Lister les branches avec le dernier commits de chacune

§  Pour lister les branches fusionnées et non fusionnées

§  Que mon « idée idiote » semble

§  En jetant la branche iss9, on perds

§  Fusion : deux cas possibles

§  On peut toujours annuler le merge

§  Créer un nouveau repository Git

§  Ajouter un fichier et le commiter (C1)

§  Créer une branche (B1) à partir de C1

§  Faire un checkout sur B1

§  Modifier le fichier et faire un Commit (C2)

§  Merge B1 dans master de manière à avoir un Commit de merge

§  Créer un nouveau repository Git

§  Ajouter un fichier et le commiter (C1)

§  Modifier le fichier et le commiter (C2)

§  Créer une branche (B1) à partir de C1

§  Faire un checkout sur B1

§  Modifier le fichier et faire un Commit (C3)

§  Merge B1 dans master en résolvant le conflit

§  Le rebase, permet de