2. Sour ce Code Management
◇ La gestion du code source (SCM)
est utilisée pour suivre les
modifications apportées à un
référentiel de code source.
◇ SCM suit un historique des
modifications apportées à une base
de code et aide à résoudre les
conflits lors de la fusion des mises
à jour de plusieurs contributeurs.
◇ SCM est également synonyme de
contrôle de version.
4. Pour quoi utiliser git ?
Objectifs :
◇ travailler à plusieurs sans se marcher dessus :
indispensa ble pour les projets en équipe
◇ garder un historique propre de toutes les
modifications : on orga nise son tra va il sous forme de
“commits” documentés
5. La théor ie de git
W orking directory
C’est la zone de travail :
les fichiers tout juste
modifiés sont ici
Index
Zone qui permet de
stocker les modifications
séléctionées en vue d’être
commitées
Local repository
Code commité, prêt à être
envoyé sur un serveur
distant
3 zones, 3 ambiances
Les modifications sont sauvegardés 3 fois
6. Un bon commit est un commit :
◇ qui ne concerne qu’une seule
fonctionna lité du progra mme
◇ le plus petit possible tout en resta nt
cohérent
◇ Idéa lement qu’il compile seul
Les commits
C’est quoi concrètement un commit ?
◇ une différence (ajout / suppression de
lignes)
◇ des méta-données (titre, hash,
auteur)
Commit : ensemble de modifica tions cohérentes du
code
7. Les commits
4a7f5a6c478.. 7a4d5f97d8bb.. 0a4d9f8d4dda..
Formulaire ajout
commentaire
Ajout
commentaire
dans base de
données
Affichage des
commentaires
des publications
Arbre de commits dans le git repository
8. Aller jusqu’au commit
W orking directory
C’est la zone de travail :
les fichiers tout juste
modifiés sont ici
Index
Zone qui permet de
stocker les modifications
séléctionées en vue d’être
commitées
Local repository
Code commité, prêt à être
envoyé sur un serveur
distant
3 zones, 3 ambiances
Les modifications sont sauvegardés 3 fois
git add git commit
9. Aller jusqu’au commit
Où j’en suis dans mes 3 zones ?
git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: views/add_commentaire.php
no changes added to commit (use "git add" and/or "git commit -a")
10. Aller jusqu’au commit
Visualiser les différences entre le working directory et l’index
git diff
diff --git a/views/add_commentaire.php b/views/add_commentaire.php
index e69de29..8cff573 100644
--- a/views/add_commentaire.php
+++ b/views/add_commentaire.php
@@ -0,0 +1,6 @@
<?php include('header.php'); ?>
+<form action="/commentaire/ajouter" method="post">
+ <p>Pseudo : <input type="text" name="pseudo"/></p>
+ <p>Commentaire : <textarea name="commentaire"></textarea></p>
+</form>
11. Aller jusqu’au commit
Ajouter mes modifications à la zone de staging (index)
git add views/add_commentaire.php
git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: views/add_commentaire.php
12. Aller jusqu’au commit
Récupitulatif des commandes
w orking directory index git repository
git add mon_fichier
git add -p (interactif)
git add -A (tout ajouter)
git commit -m “message”
git diff git diff --staged
a fficha ge
différences
a jouter des
modifica tions
13. Revenir au der nier commit
git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: model/commentaires_model.php
no changes added to commit (use "git add" and/or "git commit -a")
14. Revenir au der nier commit
Enlever des modifications dans le working directory
git checkout -- monfichier
git status
On branch master
nothing to commit, working directory clean
15. Désindexer des fichier s
git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: model/commentaires_model.php
16. Désindexer des fichier s
git reset HEAD monfichier
git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: model/commentaires_model.php
no changes added to commit (use "git add" and/or "git commit -a")
17. Aller jusqu’au commit
Récupitulatif des commandes
w orking directory index git repository
git diff git diff --staged
git add monfichier git commit -m “titre”
git checkout -- monfichier git reset HEAD monfichier
git reset --hard
git commit -am “titre” (si le fichier a déjà été indexé)
18. ◇ branche : pointeur vers un commit
◇ une bra nche principa le : master
◇ Bra nche coura nte : HEAD
◇ en généra l, une bra nche pa r fonctionna lité en cours de
développement
Les br anches
20. Les br anches et commits
4a7f5a6c478.. 7a4d5f97d8bb.. 0a4d9f8d4dda..
formulaire ajout
commentaire
ajout
commentaire
dans base de
données
affichage des
commentaires
des publications
Arbre de commits dans le git repository
master
HEAD
21. Pull Request
Collaborer avec des Pull Requests
Une Pull Request est une fonctionnalité essentielle pour la collaboration sur des
projets Git.
Elle permet aux collaborateurs de proposer des modifications à une branche
principale et de demander leur intégration.
Points clés :
◇ Crée un espace pour la discussion et la révision des modifications.
◇ Les autres contributeurs peuvent examiner, commenter et approuver les
modifications.
◇ Facilite un flux de travail de révision de code avant la fusion.
22. Gestion des br anches
Création et modification de branches
git branch : affichage des branches
git branch ma_branche : créer la branche ma_branche
git checkout ma_branche : déplace HEAD vers ma_branche
git checkout -b ma_branche : créer la branche
ma_branche et déplace HEAD dessus
ou pour simplifier...
23. Gestion des br anches
Merge : intégration des modifications d’une branche dans la branche
courante
git merge ma_branche: merge ma branche dans la branche
courante
C1 C2 C3
C4 C5
ma ster*
bugFix
24. C1 C2 C3
C4 C5
ma ster*
bugFix
C6
Gestion des br anches
Merge : intégration des modifications d’une branche dans la branche
courante
git merge ma_branche: merge ma branche dans la branche
courante
26. ◇ git directory sur un serveur distant pour le travail collaboratif
◇ Dépots dista nts :
■ github
■ Gitlab
Pourquoi gitla b ?
◇ code review, merge request, interfa ce web, CI/CD...
Les dépôts distants
27. Voir et ajouter des
dépots dis tan ts
git clone <url>
Cloner un dépot distant : crée un dossier et récupère les fichiers
28. Envoyer sur le dépot
dis tan t
git push
Envoie notre local repository sur le dépot distant
On ne touche plus aux commits pushés !
29. Recevoir depuis le dépot
dis tan t
git pull
Récupère les commits sur le dépot distant et met à jour le working directory
31. Le schéma de base de git
Récupitulatif des commandes
w orking directory index git repository
git diff git diff --staged
git add git commit
git checkout -- git reset
git reset --hard
remote git
repository
git push
git pull
git fetch
32. Pour accéder aux dépots sur gitlab, il faut y ajouter sa clé
On génère une pa ire de clés :
ssh-keygen -t rsa -C "prenom.nom@email.tn"
On a ffiche le contenu de la clé publique :
cat ~/.ssh/id_rsa.pub
On copie tout le contenu de la clé publique sur https://gitla b.com/ > mon profil > clés SSH
Authentification par clé
34. La zone de chaos : Stas h
Le stash ça sert à :
◇ Sa uvega rder les modifica tions du working directory da ns une
zone ta mpon pour rendre le working directory propre.
◇ Possibilité de rejouer les modifica tions sta shées n’importe où
◇ Peut être vu comme une zone de brouillons
35. Stash : les
com m an des
On stash un ensemble de modifications
git stash
On récupères les modifica tions sta shées
git stash apply
Pour plusieurs sta shs :
git stash list
git stash apply stash@{id}
Effa cer le contenu du sta sh
git stash clear
36. Git Flow
Git Flow est une méthodologie de gestion des branches pour le
développement de logiciels.
Git Flow facilite la gestion des fonctionnalités, des correctifs et des
versions dans un projet logiciel.
37. Pr incipes de Git Flow
•Git Flow se compose de plusieurs types de branches clés :
• Branches principale (Main) : Représente la version de
production sta ble.
• Branches de fonctionnalités (Feature) : Pour le développement
de nouvelles fonctionna lités.
• Branches de publication (Release) : Prépa re une version pour
la production.
• Branches de correctifs (Hotfix) : Corrige des problèmes de
production.
•Les développeurs suivent un processus spécifique pour fusionner ces
bra nches en utilisa nt des règles strictes.
38. Gestion des Releases
dan s Git
Les "Releases" (ou versions) dans Git permettent de marquer des points
spécifiques dans l'historique du projet logiciel.
Pourquoi utiliser les Releases ?
•Ma rquer des versions sta bles du logiciel.
•Fa ciliter la gestion des mises à jour et des déploiements.
•Permettre a ux utilisa teurs de télécha rger des versions spécifiques.
39. Gestion des Releases
dan s Git
Comment créer une Release :
1.git checkout [branche-cible] : Aller sur la bra nche que vous souha itez ma rquer
comme version sta ble.
2.git tag [nom-de-la-release] : Créer un ta g pour la version
(pa r exemple, v1.0.0).
3.git push origin [nom-de-la-release] : Pousser le ta g vers
le dépôt dista nt.
40. Pour aller plus loin avec
git...
◇ git rebase ou git merge ?
◇ balader ses commits avec git cherry-pick
◇ afficher un commit : git show <commit>
◇ Engueulez vos a mis : git blame <fichier>
◇ visua liser l’historique des commits : git log
◇ J’a i tout ca ssé ! git reflog