Les bonnes pratiques

Git / GitHub

Auteur Version Date

Firas GABSI – GABSI Consulting V1 16.01.2023



 Table des ma ères
Contexte ..................................................................................................................................................3
Ges on des branches ..............................................................................................................................3
Commit et merge request : .....................................................................................................................4
Ges on de version du projet ...............................................................................................................8
Sécurité ...............................................................................................................................................9
Les commandes GIT : ............................................................................................................................10
ti
ti


ti

 Contexte
Ce document vise à décrire les bonnes pra que Git ainsi que la ges on du projet avec ce
système de versionning.

Ges on des branches

Dès le lancement du projet, nous avons deux branches dont les rôles sont prédé nis
de la manière suivante :
• Master :
Le rôle de la branche « master » est de contenir la dernière version déployée.
Note : Les mises à jour ne seront réalisées qu’au moment d’une livraison ou pendant
la correc on d’une anomalie localisé dans « prod » en urgence (ce qu’on appel par
« ho ix », ce e opéra on n’est pas fréquente).
Une livraison marque généralement la n d’un sprint.

• Dev :
Le rôle de la branche « DEV » est de contenir la prochaine version à déployer
Note : Les mises à jour seront réalisées tout au long du sprint

Chaque nouvelle branche doit respecter la nomenclature suivante : « role_branche/

numéro_jira »

Le tableau suivant explique ce e nomenclature:

item Modalité Descrip on du rôle

« Feature » si la nouvelle branche con ent une nouvelle fonc onnalité
Role_branch « Bug x » si la nouvelle branche permet de corriger une erreur
e si le rôle de la branche est de corriger une erreur de
« Ho ix »
produc on
Numéro_jira Numéro du JIRA

La date de livraison des branches di ère selon leur type :

- Les branches de type « feature » et « bug x » ne peuvent être livrée qu’à la n de
chaque sprint.
- les branches « ho ix » peut être livrée dès qu’elles sont prêtent.

Si vous travaillez avec d'autres personnes sur votre projet, il est important de tenir
vos branches à jour avec les dernières modi ca ons de la branche « dev ».


tf
tf
ti

fi
ti
ti

ti

tt

tf
ti

ti

tt
ff
fi
fi
fi
ti
ti

ti

ti

fi
fi
 De ce e façon, lorsque vous pousser une demande d'extrac on, il n'y aura pas de
con its de fusion et votre modi ca on sera plus suscep ble d'être acceptée. Bien sûr, vous
ne devez pas accepter aveuglément tous les changements de la branche principale - s'il y a
des changements avec lesquels vous n'êtes pas d'accord, discutez-en avec votre équipe avant
de les fusionner dans votre propre branche.
Pour cela, il faut exécuter les commandes git suivants :
git checkout dev
git pull
git checkout nom_de_votre_branche
git rebase dev

Si vous travaillez sur une nouvelle fonc onnalité pour votre projet, créez une branche
dis ncte pour celle-ci au lieu de travailler directement dans la branche « dev ». De ce e
façon, si votre fonc onnalité n'est pas encore prête pour « la release », vous pouvez la
garder hors de la branche « dev » jusqu'à ce qu'elle soit prête à être fusionnée.

Commit et merge request :

Faites des commits propres qui ne concernent qu'une seule chose:

Très souvent, on fait plusieurs changements de natures di érentes dans une session
de travail. Il ne faut pas les regrouper en un seul commit, mais plutôt répar r en plusieurs
commits dis ncts. On saura ainsi plus facilement ce qui a été fait, puisque la descrip on
associée à chaque commit sera simple (et ne concernera qu'une chose), et si on a besoin de
revenir en arrière, on pourra choisir de défaire le commit qui concerne le problème
spéci que, plutôt que de tout défaire ce qu'on a fait dans la session de travail.

Écrire des messages de commit clairs :

Lorsque vous pousser votre code dans votre référen el, écrivez des messages de
valida on clairs et concis expliquant ce qui a changé et pourquoi. Ce e approche vous aide,
ainsi que vos collaborateurs, à comprendre l'historique du projet, ce qui facilite la recherche
de modi ca ons spéci ques lorsque vous en avez besoin.
Il est recommandé de :
- Soit me re le numéro le numéro de jira associée suivie de son tre (« numero_jira :
tre_jira »)
- Soit une brève descrip on ce qui a été réalisée dans la branche.

Ne validez pas les chiers inu les :

Avant de valider votre code, consultez la liste des chiers modi és pour vous assurer
que vous ne comme ez pas accidentellement quelque chose que vous ne voulez pas. Il est
facile d'oublier de supprimer les chiers temporaires ou générés avant de valider, mais cela





ti

ti
fl
fi
ti
tt
fi

ti
ti
tt
fi
ti
tt
ti
fi
ti

fi
fi
ti

ti

ti

fi
ti

ti
ff

tt
ti
fi
ti

ti
tt
 peut encombrer votre référen el et rendre plus di cile la recherche ultérieure des éléments
importants.

Chaque développeur doit créer une « merge request » vers la branche DEV dès que
celui-ci termine sa tâche, il ne peut pas et il ne doit pas émerger directement sa branche
dans « dev ».
Celle-ci sera par la suite fusionnée quand les condi ons suivantes seront remplies
- Condi on de valida on : une erce personne doit valider la « merge request »
- Condi on technique : la merge request ne présente aucun con it avec le code dans
la branche des na on.
- Condi on d’exécu on : les « jobs » suivants ont été correctement exécutés.

Mé ers (job) Missions

Véri er la structure du projet

Build Véri er la disponibilité de toutes les dépendances nécessaire au
lancement du projet

Test Lancer tous les tests unitaires du projet

Analyse du code Tester la vulnérabilité des dépendances du projet

ti
fi
fi
ti
ti
ti

ti
ti
ti
ti

ti
ti
ffi
ti
fl

 En cas d’échec d’un de ces « job », un mail est envoyé aux personnes concernées.

NB : il est important de supprimer la branche une fois fusionnée avec la branche « dev » a n
d’éviter d’avoir une liste des branches inu les.

U lisez de bons noms de variables et méthodes

Choisir de bons noms de variables et méthodes est une par e importante de
l'écriture de code lisible. Après tout, si quelqu'un ne peut pas comprendre ce qu'une variable
ou une méthode est censée représenter, il ne pourra pas comprendre le code qui l'u lise.
Prenez donc le temps de choisir des noms de variables descrip fs qui faciliteront la
lecture et la maintenance de votre code.

Assurez-vous que la structure de votre projet ainsi que vos tests réussissent avant de
pousser votre code :
Assurez-vous que tous vos tests réussissent avant de valider votre code ! Sinon, vous
pourriez introduire des erreurs dans votre base de code qui auraient pu être facilement
évitées. Il y a des jobs qui se lancent à chaque créa on / mise à jour d’une demande de
fusion pour tester la structure de votre code et la bonne exécu on de vos tests unitaire.

Écrivez des tests pour votre code

Si votre projet a une suite de tests automa sée, assurez-vous d'écrire des tests pour
votre nouveau code avant de le valider. De ce e façon, vous pouvez être sûr que votre code
fait ce qu'il est censé faire et qu'il ne cassera rien lorsqu'il sera fusionné dans la branche
principale.

Ne dupliquez pas le code inu lement

La duplica on de code est généralement considérée comme une mauvaise idée car
elle peut entraîner des erreurs et des incohérences en cours de route. Si vous vous retrouvez
à copier-coller des morceaux de code autour de votre projet, prenez du recul et voyez s'il
existe une meilleure façon de structurer les choses a n de ne pas avoir à dupliquer autant de
code.

Ne comme ez pas de code cassé

Tout comme les aver ssements, le code brisé vous indique également que quelque
chose ne va pas. Alors, ne pousser pas votre code ! Au lieu de cela, corrigez toutes les erreurs
dans votre code avant de le pousser; sinon, vous courez le risque de casser quelque chose
dans le processus de développement.

Ignorer correctement les chiers

Assurez-vous d'ajouter des chiers à votre chier « .gi gnore » qui n'ont pas besoin
d'être suivis par Git (par exemple, des binaires compilés).







ti

tt
ti

fi
ti
ti

fi

ti

tt

ti
fi
fi
ti

ti
ti
ti
ti

ti

fi
 Ne modi ez pas l'historique des commits qui ont été publiés
Ce principe vous évitera de perdre de temps inu lement. Si vous changez l'historique
des commits qui sont visibles par tous, vous risquez de causer des problèmes lorsqu'un
développeur voudra faire une fusion avec son entrepôt local. Donc, pensez-y bien avant
d'u liser une commande qui change l'historique des commits (comme rebase), et si vous le
faites, faites-le seulement sur une branche locale.

Livraison
Pour réaliser une livraison, une « Merge request » de la branche « DEV » vers la
branche « MASTER » doit être réalisée.
La Merge request doit donc être fusionnée, en respectant les condi ons décrites ci-dessus.
Après la fusion, les 3 job (Github Ac ons) suivants sont lancés automa quement :

Job Missions
Build Assurer que la nouvelle version du projet après la fusion est toujours
Test opéra onnelle.
Préparer la version du master avant d’être déployer :
• Incrémenter la version du projet dans les branches « dev » et
Release
« master ».
• Créer un nouveau tag

Au niveau de l’interface principale du projet dans GitHub, il existe une rubrique qui
s’appelle « Releases », elle permet de gérer les di érents release e ectuées sur le projet,
donc il est important de la me re à jour.

ti
ti

fi

tt
ti

ff

ti

ti
ff
ti

 La créa on d’un nouveau élément dans ce e rubrique est réalisée une fois que la
branche « dev » est margée dans « master » et que le job « release » est terminée
correctement, car ce dernier crée un « tag » (car chaque release est associée à un tag).
Au moment de créa on d’une nouvelle release, il est pra que de lister les di érentes
« feature » et « bug x » e ectués depuis la dernière release. GitHub est en mesure de
détecter automa quement ces derniers à travers le bouton « Generate release notes » dans
le formulaire de créa on d’une release.
Ce formulaire est accessible via le bouton « Dra a new release » depuis le menu
principale (à travers le bouton « releases »).

Ges on de version du projet

La conven on Seman c Versioning, u lisée par de nombreux logiciels, propose une

façon pour dé nir la version du projet sous la forme suivante X.Y.Z avec la signi ca on
suivante :
- X correspond à la version majeure : changements non rétrocompa bles. Les
évolu ons majeures apportent de nouvelles fonc onnalités, en changeant radicalement
l'apparence ou l'architecture du logiciel.
- Y correspond à la version mineure : ajouts de fonc onnalités rétrocompa bles,
principalement des correc ons de bugs, ajouts de quelques fonc onnalités.






ti
ti

ti
fi
ti
ti
ti
fi
ti
ti
ff
ti

ti
tt
ti
ft
ti
ti
ti

ti
ff
fi

ti
ti
 - Z correspond au correc f : correc ons d’anomalies rétrocompa bles, failles de
sécurité.

Ce e conven on est de plus en plus adoptée, notamment dans le milieu de l’open-

source.
La version du projet est enregistrée dans le chier « package.json ».

Les tags devront respecter une certaine nomenclature à savoir la le re « v » suivie du

numéro de la version. Une con gura on Github a été apporter pour oublier les u lisateurs a
respecter la nomenclature des tags.

Sécurité

A n de véri er la vulnérabilité du code réalisé, un exécuteur Github est con guré

dont le rôle est de :
• Analyser les dépendances u lisées dans le projet et qui sont dé nit dans la branche «
master »
• Comparer chaque dépendance dé nit à sa base de données à jour
En cas de présence d’une faille de sécurité dans une dépendance, il doit :
• Envoyer une alerte par mail aux u lisateurs dé nis dans le projet
• Ajouter une alerte dans le Dashboard
• Proposer une correc on adaptée à savoir la bonne version à u liser (qui con ent
généralement le correc f de ce e anomalie).

L’accès à ce e fonc onnalité se fait à travers la rubrique « security » :

Ce e fonc onnalité propose des informa ons supplémentaire tel que une évalua on globale
de du niveau de sécurité du projet, …




tt

fi

tt
ti

tt
ti

fi
ti
ti
ti
ti
fi
tt
ti
fi
ti

ti

ti
fi

ti
fi
fi

ti

tt
ti
ti
ti
ti
fi
 Les commandes GIT :
Création

Opération Commande

Cloner un dépôt GIT existant $ git clone git@github.com:zentotechnologie/repo.git

Create a new dépôt locale $ git init



Modi cations locales

Opération Commande

Rechercher les fichiers modifiés dans votre répertoire de

$ git status
travail

Rechercher les modifications apportées aux fichier(s)

$ git diff
sélectionné(s)

Ajouter les modifications effectuées au prochain commit $ git add .

Ajoutez les modifications dans au prochain commit $ git add -p <fichier>

Commiter les modifications dans les fichiers suivis $ git commit -a

Commiter les modifications effectuées $ git commit




fi

 Modifier le dernier commit (__ Ne modifiez pas les commits $ git commit --
publiés !__) amend

Historique des commits

Opération Commande

Afficher tous les commits, en commençant par le plus récent $ git log

Afficher les modifications pour un fichier spécifique $ git log -p <fichier>

Qui a changé quoi et quand dans $ git blame <fichier>

Branches & Tags

Opération Commande

Lister toutes les branches existantes $ git branch

Changer HEAD branche $ git checkout <branche>

Créez une nouvelle branche basée sur votre $ git branch <nouvelle-
HEAD actuel branche>

Créer une nouvelle branche basée sur une $ git checkout --track <remote/
branche distante branche>

Supprimer une branche locale $ git branch -d <branche>

Marquez le commit actuel avec une balise $ git tag <nom-du-tag>

Mise à jour & Publication

Opération Command

Lister toutes les commandes actuellement

$ git remote -v
configurées

Afficher les informations sur une télécommande $ git remote show <remote>

Add new remote repository, named $ git remote add <remote> <url>

Download all changes from , but don‘t integrate

$ git fetch <remote>
into HEAD

Download changes and directly merge/ integrate

$ git pull <remote> <branche>
into HEAD
 Publish local changes on a remote $ git push <remote> <branche>

$ git branch -dr <remote/

Delete a branch on the remote
branche>

Publier les tags $ git push --tags

Merge & Rebase

Opération Commande

Fusionnez dans votre HEAD actuel $ git merge <branche>

Rebasez votre HEAD actuel dans (__ Ne rebasez

$ git rebase <branche>
pas les commits publiés !__)

Annuler une rebase $ git rebase --abort

Continuer un rebase après avoir résolu les conflits $ git rebase --continue

Utilisez votre outil de fusion configuré pour résoudre

$ git mergetool
les conflits

Utilisez votre éditeur pour résoudre manuellement

$ git add <fichier-resolu> $
les conflits et (après résolution) marquer le fichier
git rm <fichier-resolu>
comme résolu

Annulation

Opération Commande

Ignorer toutes les modifications locales dans votre $ git reset --hard
répertoire de travail HEAD

$ git checkout HEAD

Ignorer les modifications locales dans un fichier spécifique
<fichier>

Annuler un commit (en produisant un nouveau commit

$ git revert <commit>
avec des modifications contraires)

Réinitialisez votre pointeur HEAD sur un commit précédent $ git reset --hard
et supprimez toutes les modifications depuis <commit>

Réinitialisez votre pointeur HEAD sur un commit précédent

et conservez toutes les modifications en tant que $ git reset <commit>
modifications non mises en scène

Réinitialisez votre pointeur HEAD sur un commit précédent $ git reset --keep
et conservez les modifications locales non validées <commit>