Git, Github et Github Actions - Maîtrise des Fondamentaux
Chapitre 2 - Guide Débutant - Introduction à Git et GitHub

Découvrir Git et GitHub

Plan de formation

Qu'est-ce que Git ?

Git est un système de contrôle de version distribuée qui permet aux développeurs de suivre les modifications apportées au code source au fil du temps. Il facilite la collaboration entre plusieurs développeurs en permettant la gestion des versions, la fusion des modifications et la résolution des conflits.

Le contrôle de version distribuée est un modèle dans lequel chaque utilisateur possède une copie complète du référentiel, y compris l'historique complet des modifications. Contrairement aux systèmes centralisés, cela permet à chaque développeur de travailler de manière autonome, de créer des branches, de fusionner des modifications et de collaborer même sans connexion Internet. Git est l'un des systèmes de contrôle de version distribuée les plus populaires.

Qu'est-ce que GitHub ?

GitHub est une plateforme d'hébergement de code qui utilise Git comme système de contrôle de version. Elle permet aux développeurs de stocker, gérer et partager leur code avec d'autres personnes. GitHub offre également des fonctionnalités de collaboration, telles que les pull requests, les issues et les wikis, qui facilitent le travail en équipe.

Interactions entre Git et GitHub

Git et GitHub interagissent étroitement pour offrir une expérience de développement fluide. Git gère les versions du code localement sur la machine de chaque développeur, tandis que GitHub sert de référentiel distant pour stocker et partager ce code. Les développeurs utilisent Git pour effectuer des commits, des branches et des fusions, puis poussent ces modifications vers GitHub pour les partager avec d'autres.

Interaction entre Git et GitHub
Interactions entre Git et GitHub
Source : Alphorm.com → Formation GitHub → Maîtrise des fondamentaux

Pourquoi utiliser Git avec GitHub ?

L'utilisation de Git avec GitHub présente plusieurs avantages. Tout d'abord, cela permet une meilleure collaboration entre les développeurs, car chacun peut travailler sur sa propre copie du code et soumettre des modifications via des pull requests. De plus, GitHub offre des outils de gestion de projet, tels que les issues et les tableaux Kanban, qui facilitent le suivi des tâches et l'organisation du travail. Enfin, GitHub permet de sauvegarder le code dans le cloud, offrant ainsi une protection contre la perte de données.

Aperçu de l'interface GitHub

L'interface de GitHub se compose de plusieurs éléments clés, notamment :

Installer Git localement

Plan de formation

Installation de Git sur Windows

Pour s'assurer que Git est correctement installé, ouvrir une invite de commande (cmd) ou PowerShell et taper la commande suivante : 

git version

Si Git est installé correctement, la version de Git installée sera affichée.

Installation de Git sur Ubuntu

Pour installer Git sur Ubuntu, ouvrir un terminal et exécuter les commandes suivantes : 

sudo apt-get update
sudo apt-get install git-all
git version

La commande sudo apt-get update met à jour la liste des paquets disponibles, tandis que sudo apt-get install git-all installe Git et tous ses composants associés. La commande git version va permettre de vérifier que Git est correctement installé en affichant la version installée.

Il est possible d'installer une version gratuite de Ubuntu sur Windows en passant par le marketplace de Microsoft.

Configurer Git localement

Plan de formation

Configuration initiale de Git 

git config --global user.name 'Votre nom'
git config --global user.email 'votre.email@example.com'
git config --list

Ces trois commandes permettent de définir le nom d'utilisateur, l'e-mail ainsi que d'afficher la configuration.

Attention :
Il est nécessaire de réutiliser les mêmes paramètres pour la création du compte (si le compte n'est pas encore existant).

Démo de la configuration

Pour des raisons de confidentialité, je ne rentre pas en détails sur ma configuration personnelle.

Expliquer la configuration d'un compte GitHub

Plan de formation

Création d'un compte GitHub

Pour créer un compte GitHub, il faut se rendre sur le site officiel : https://github.com/join. Il est possible de s'inscrire avec une adresse e-mail, un nom d'utilisateur et un mot de passe ou en utilisant un compte Google ou Apple.

Astuce :
Il ne faut pas oublier de vérifier son adresse e-mail en cliquant sur le lien envoyé par GitHub. Le mail pourrait arriver dans les spams.

Configuration de la sécurité

Il est fortement recommandé d'activer l'authentification à deux facteurs (2FA) pour sécuriser son compte GitHub. Pour ce faire, il faut se rendre dans les paramètres du compte, puis dans la section "Security" et suivre les instructions pour activer la 2FA en utilisant une application d'authentification ou par SMS. Le SMS est moins sécurisé qu'une application d'authentification.

Organisation sur GitHub

Il est possible de créer ou de rejoindre une organisation sur GitHub pour collaborer avec d'autres utilisateurs. Il est possible de gérer les membres, les permissions et les projets (dépôts) de manière centralisée au sein d'une organisation.

Avantages des organisations

Configurer un compte GitHub

Plan de formation

Démo : Création d'un compte GitHub

Lors de la création d'un compte GitHub, une fois avoir validé les données personnelles, il faut encore confirmer qu'on n'est pas un robot via une énigme. C'est seulement après que l'e-mail de vérification avec le code à 6 chiffres est envoyé.

Une fois la création du compte terminée, il faut se connecter.
Après la première connexion, différentes questions sont posées pour personnaliser l'expérience utilisateur.

Démo : Configuration de la sécurité

Pour configurer la sécurité, il faut se rendre dans les paramètres du compte en cliquant sur l'icône de profil en haut à droite, puis sur "Settings".
Dans le menu de gauche, cliquer sur "Password and authentication" puis sur "Enable two-factor authentication".
Il est possible de choisir entre une application d'authentification (recommandée) ou par SMS.
Après avoir choisi l'option, suivre les instructions pour terminer la configuration.

Démo : Organisation sur GitHub

Pour créer une organisation, cliquer sur l'icône de profil en haut à droite, puis sur "Your organizations".
Cliquer ensuite sur le bouton "New organization" et suivre les instructions pour créer une nouvelle organisation.
Il est possible d'inviter des membres à rejoindre l'organisation et de gérer les permissions via les paramètres de l'organisation.

Astuce :
Il est seulement possible de créer une organisation si on ne fait pas partie d'une autre organisation.

Explorer la création et le clonage de dépôts

Plan de formation

Créer un dépôt sur GitHub

Pour créer un dépôt sur GitHub, cliquer sur le bouton "New" dans la section "Your repositories" de la page d'accueil ou dans le menu de gauche.

Créer un nouveau dépôt sur GitHub
Créer un dépôt sur GitHub
Source : mon compte GitHub

Il faut ensuite remplir les informations requises, telles que le nom du dépôt, la description (optionnelle), la visibilité (publique ou privée) et les options supplémentaires comme l'initialisation avec un README, un .gitignore ou une licence.
Cliquer ensuite sur le bouton "Create repository" pour finaliser la création du dépôt.

Configurer le dépôt

Après avoir créé le dépôt, il est possible de le configurer en accédant aux paramètres du dépôt via l'onglet "Settings".
Dans les paramètres, il est possible de gérer les options :

Cloner un dépôt

Il faut utiliser la commande git clone suivie de l'URL du dépôt pour cloner un dépôt existant sur la machine locale.
L'URL peut être trouvée en cliquant sur le bouton "Code" dans la page du dépôt, puis en copiant l'URL sous l'onglet "HTTPS" ou "SSH".
Par exemple, pour cloner un dépôt en utilisant HTTPS, la commande serait : 

git clone https://github.com/username/repository.git

Créer et cloner des dépôts

Plan de formation

Démo : Créer et configurer un dépôt sur GitHub

Création du dépôt pour la formation
Exemple de réglages pour la création d'un dépôt.
Source : Mon compte GitHub

Démo : Cloner un dépôt

Pour cloner un dépôt, il faut copier l'URL du dépôt en cliquant sur le bouton "Code" dans la page du dépôt, puis en copiant l'URL sous l'onglet "HTTPS" ou "SSH".
Par exemple, pour cette formation, il est possible de cloner le dépôt en utilisant HTTPS avec la commande suivante :

Ensuite, dans un terminal PowerShell, il faut se placer dans le répertoire où l'on souhaite cloner le dépôt, par exemple dans le répertoire C:\www. Pour ce faire, il faut taper la commande suivante :

Copier l'URL du dépôt dans GitHub
Copier l'URL du dépôt dans GitHub
Source : Mon compte GitHub 
cd C:\www

Pour finir, il faut exécuter la commande ci-dessous : 

git clone https://github.com/username/formation-github-actions-ci-cd.git

Découvrir les commandes Git de base

Plan de formation

Initialiser un dépôt Git

Il y a 2 façons d'initialiser un dépôt Git :

  1. En créant un nouveau dépôt sur GitHub et en le clonant localement (voir vidéo précédente).
  2. En initialisant un dépôt localement avec la commande git init. Par exemple, pour initialiser un dépôt dans le répertoire courant, il faut exécuter la commande suivante : 
git init

Cette commande crée un nouveau sous-répertoire nommé .git qui contient tous les fichiers nécessaires au dépôt.
Après avoir initialisé le dépôt, il est possible d'ajouter des fichiers, de suivre les modifications et d'enregistrer les changements.

Suivre les modifications

Pour suivre les modifications apportées aux fichiers dans le dépôt, il faut utiliser la commande git add pour ajouter les fichiers modifiés à l'index (staging area).
Par exemple, pour ajouter un fichier spécifique, il faut utiliser la commande suivante : 

git add nom-du-fichier

Pour ajouter tous les fichiers modifiés, il est possible d'utiliser la commande suivante : 

git add .

La commande git status permet de vérifier l'état des fichiers dans le dépôt, en affichant les fichiers modifiés, ajoutés ou supprimés. 

git status

Enregistrer les modifications

Pour enregistrer les modifications dans l'historique du dépôt, il faut utiliser la commande git commit avec l'option -m pour ajouter un message décrivant les modifications apportées. Par exemple : 

git commit -m "Message décrivant les modifications"

Vérifier l'historique

La commande git log permet de consulter l'historique des commits dans le dépôt, en affichant les messages de commit, les auteurs et les dates. 

git log

Appliquer les commandes Git

Plan de formation

Démo : Pratiquer les commandes fondamentales de Git

Modifications README.md et création .gitignore

Pour commencer, on adapte le contenu du fichier README.md pour y ajouter une description. 

# formation-github-actions-ci-cd
Ce dépôt contient des exemples de configuration CI/CD utilisant GitHub Actions. Il est destiné à une formation sur l'intégration continue et le déploiement continu (CI/CD).

## Structure du dépôt

- `.github/workflows/` : Contient les fichiers de workflow GitHub Actions.
- `src/` : Contient le code source de l'application de démonstration.
- `tests/` : Contient les tests automatisés.

## Utilisation

1. Clonez ce dépôt :
   ```bash
   git clone https://github.com/votre-utilisateur/github-actions-ci-cd.git
   ```

Ensuite, on ajoute le fichier .gitignore pour ignorer les fichiers logs et temporaires. 

# Fichiers temporaires
# Ignore Logs
logs/
*.log

# Temporary files
tmp/
temp/

Contrôler l'état des fichiers

En utilisant la commande git status, on peut voir les fichiers modifiés et non suivis. 

git status

Cela va nous montrer les fichiers modifiés et non suivis. 

PS C:\www\formation-github-actions-ci-cd> git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git restore ..." to discard changes in working directory)
        modified:   README.md

Untracked files:
  (use "git add ..." to include in what will be committed)
        .gitignore

no changes added to commit (use "git add" and/or "git commit -a")

Ajouter les fichiers au dépôt

Pour ajouter les fichiers modifiés et non suivis à l'index, on utilise la commande git add --all. 

git add --all

Recontrôler l'état des fichiers

Ensuite, on peut revérifier l'état des fichiers dans le dépôt avec la commande git status. 

git status

Cela va nous montrer que les fichiers sont prêts à être commités. 

PS C:\www\formation-github-actions-ci-cd> git status
On branch main
Your branch is up to date with 'origin/main'.

Changes to be committed:
  (use "git restore --staged <file ..." to unstage)
		new file:   .gitignore
		modified:   README.md

Faire le premier commit

Pour faire le premier commit, on utilise la commande git commit avec un message décrivant les modifications. 

git commit -m "first commit : Add README.md and .gitignore files"

Vérifier l'historique des commits

Pour vérifier l'historique des commits, on utilise la commande git log. 

git log

Cela va nous montrer l'historique des commits avec les messages, les auteurs et les dates. 

PS C:\www\formation-github-actions-ci-cd> git log
	commit 61bda9b49925503cbbbb5ba4db0a1c87bee2ee5c (HEAD -> main)
Author: nom-de-l-auteur <nom-de-l-auteur@gmail.com>
Date:   Sat Oct 11 16:08:21 2025 +0200

    first commit : Add README.md and .gitignore files

commit c876b6283f6be3bc98cc3c3d9f44726c300e9e89 (origin/main, origin/HEAD)
Author: nom-de-l-auteur <108182082+NomDeLAuteur@users.noreply.github.com>
Date:   Sat Oct 11 11:25:12 2025 +0200

    Initial commit

Git Add, Git Status, Git Commit, Git Log dans VS Code

Visual Studio Code (VSCode) intègre des fonctionnalités Git qui permettent de gérer les dépôts directement depuis l'éditeur.

Git dans VSCode
Emplacement de Git dans VS Code
Source : Mon PC

Voici comment utiliser les commandes Git de base dans VSCode :

Découvrir les commandes Git Pull, Git Push et Git Fetch

Plan de formation

Configurer un dépôt distant

Pour configurer un dépôt distant, il faut utiliser la commande git remote add suivie du nom du dépôt distant (généralement "origin") et de l'URL du dépôt distant.
Par exemple : 

git remote add origin https://github.com/username/repo.git

Pousser des modifications (Push)

Pour pousser des modifications vers le dépôt distant, il faut utiliser la commande git push suivie du nom du dépôt distant et de la branche.
Par exemple, pour pousser la branche principale (main) vers le dépôt distant nommé "origin" : 

git push origin main

Récupérer des modifications (Fetch)

Pour récupérer des modifications depuis le dépôt distant sans les fusionner avec la branche locale, il faut utiliser la commande git fetch suivie du nom du dépôt distant (comme un bouton actualiser).
Par exemple, pour récupérer les modifications depuis le dépôt distant nommé "origin" : 

git fetch origin

Tirer des modifications (Pull)

Pour tirer des modifications depuis le dépôt distant et les fusionner avec la branche locale, il faut utiliser la commande git pull suivie du nom du dépôt distant et de la branche. Cela peut être décomposé en deux étapes : d'abord, récupérer les modifications avec git fetch, puis les fusionner avec git merge.
Par exemple, pour tirer les modifications de la branche principale (main) depuis le dépôt distant nommé "origin" : 

git pull origin main

Astuce :
Il est possible que des conflits surviennent lors d'un git pull si les modifications locales et distantes touchent les mêmes lignes de code. Dans ce cas, il faudra résoudre les conflits manuellement avant de pouvoir finaliser la fusion.

Utiliser les commandes Git Pull, Git Push et Git Fetch

Plan de formation

Démo : Pratiquer les commandes Git push, pull et fetch

Pour cette démonstration, on va utiliser le dépôt créé précédemment pour la formation.
Le dépôt est déjà configuré avec un dépôt distant nommé "origin" pointant vers le dépôt GitHub.

Modifier fichier Test

Pour commencer, nous allons modifier le fichier Test pour y modifier une ligne de texte. 

Test new commit

Vérifier le status

Ensuite, nous allons vérifier l'état des fichiers dans le dépôt avec la commande git status. 

git status

Cela va nous montrer que le fichier Test a été modifié. 

On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git restore ..." to discard changes in working directory)
        modified:   Test

no changes added to commit (use "git add" and/or "git commit -a")

Ajouter le fichier Test à l'index

Nous allons maintenant ajouter le fichier Test à l'index avec la commande git add --all. 

git add --all

Cette commande ajoute tous les fichiers modifiés et non suivis à l'index.

Astuce :
Il est également possible d'utiliser la commande git add . pour ajouter tous les fichiers modifiés dans le répertoire courant et ses sous-répertoires.

Faire le commit

Nous allons maintenant faire le commit des modifications avec la commande git commit. 

git commit -m "Modify Test file"

Cela va enregistrer les modifications dans l'historique du dépôt avec le message "Modify Test file". 

[main 36c7704] Modify Test file
 1 file changed, 1 insertion(+), 1 deletion(-)

Pousser les informations sur le dépôt distant (Push)

Nous allons maintenant faire le push des modifications vers le dépôt distant avec la commande git push. 

git push origin main

Cela va envoyer les modifications de la branche principale (main) vers le dépôt distant nommé "origin". 

Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 12 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 271 bytes | 135.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To https://github.com/YannJordan/formation-github-actions-ci-cd.git
   a3fe274..36c7704  main -> main

Contrôle des modifications sur GitHub

Nous pouvons vérifier que les modifications ont bien été poussées vers le dépôt distant en allant sur la page du dépôt sur GitHub.
Nous devrions voir le commit "Modify Test file" dans l'historique des commits.

Commit Modify Test file sur GitHub
Commit "Modify Test file" sur GitHub
Source : Mon compte GitHub

Récupérer les modifications avec Git Fetch

La commande git fetch permet de récupérer les modifications depuis le dépôt distant sans les fusionner avec la branche locale. Cela permet de voir les nouvelles branches et les commits sans affecter l'état actuel de la branche locale. Pour simuler la modification par un autre utilisateur, nous allons modifier un fichier directement sur GitHub (fortement déconseillé en production).
Une fois le commit fait sur GitHub, nous allons revenir à notre terminal et exécuter la commande suivante : 

git fetch --all

Cela va récupérer les modifications depuis le dépôt distant nommé "origin". 

remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 1), reused 0 (delta 0), pack-reused 0 (from 0)
Unpacking objects: 100% (3/3), 929 bytes | 35.00 KiB/s, done.
From https://github.com/YannJordan/formation-github-actions-ci-cd
   f938c3b..bd53708  main       -> origin/main

Dans VSCode, nous ne pouvons pas encore voir les modifications car elles n'ont pas encore été fusionnées avec la branche locale.

Fusionner les modifications avec Git Pull

Pour voir les modifications dans le fichier Test, nous devons utiliser la commande git pull. 

git pull --all

Cela va tirer les modifications depuis le dépôt distant et les fusionner avec la branche locale. 

Updating f938c3b..bd53708
Fast-forward
 Test | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Mêmes procédures via VSCode

Nous pouvons également effectuer les mêmes opérations (ajout, commit, push) directement depuis Visual Studio Code (VSCode) en utilisant l'interface graphique intégrée pour Git.

Pour commencer, il faut modifier un fichier pour voir le changement dans l'onglet de contrôle de source (icône avec trois branches).

Git Add via VSCode

Pour ajouter les fichiers modifiés à l'index, il suffit de cliquer sur le signe "+" à côté des fichiers dans la section de contrôle de source.

Ajout des fichiers via VSCode
Ajout des fichiers via VSCode
Source : Mon PC

Git Commit via VSCode

Il faut ajouter un commentaire de commit dans le champ prévu à cet effet puis cliquer sur le bouton ✓ Commit pour valider le commit.

Commit des fichiers via VSCode
Commit des fichiers via VSCode
Source : Mon PC

Git Push via VSCode

Pour pousser les modifications vers le dépôt distant, il faut cliquer sur le bouton 🔃 Sync Changes 1 (le numéro va varier en fonction du nombre de changements à synchroniser).

Push des fichiers via VSCode
Push des fichiers via VSCode
Source : Mon PC

Un message va alors s'afficher dans un dialogue :

Message de Push des fichiers via VSCode
Message de Push des fichiers via VSCode
Source : Mon PC

En cliquant sur OK, le push est effectué et les modifications sont envoyées vers le dépôt distant.

Important :
Avant de faire un git push, VSCode effectue automatiquement un git pull pour s'assurer que la branche locale est à jour avec le dépôt distant. Si des conflits surviennent, ils devront être résolus manuellement avant de pouvoir finaliser le push.

Synchronisation avant Pull via VSCode

Pour effectuer un git pull via VSCode, il suffit de cliquer sur l'icône de synchronisation dans la barre d'état à côté de "Changes".

Synchronisation avant Pull via VSCode
Synchronisation avant de faire un Pull via VSCode
Source : Mon PC

Git Pull via VSCode

Pour effectuer un git pull via VSCode, il suffit de cliquer sur l'icône de synchronisation dans la barre d'état à côté de "Changes".

Pull des fichiers via VSCode
Pull des fichiers via VSCode
Source : Mon PC

Expliquer la gestion des branches et la fusion

Plan de formation

Créer des branches

Pour créer une nouvelle branche, il faut utiliser la commande git branch suivie du nom de la branche.
Par exemple, pour créer une branche nommée "feat/add-new-yaml-file" : 

git branch feat/add-new-yaml-file

Changer des branches (basculer entre les branches)

Pour changer de branche, il faut utiliser la commande git checkout suivie du nom de la branche.
Par exemple, pour changer de branche vers "feat/add-new-yaml-file" : 

git checkout feat/add-new-yaml-file

Astuce :
Pour créer une nouvelle branche et basculer dessus en une seule commande, il est possible d'utiliser git checkout -b nom-de-la-branche.

Fusionner des branches

Pour fusionner une branche dans une autre, il faut d'abord se placer sur la branche de destination avec git checkout, puis utiliser la commande git merge suivie du nom de la branche à fusionner.
Par exemple, pour fusionner la branche "feat/add-new-yaml-file" dans la branche principale (main) : 

git checkout main
git merge feat/add-new-yaml-file

Gérer les branches et fusionner les modifications

Plan de formation

Démo : Création des branches

En utilisant la commande git branch sans définir de nom de branche, on peut voir la liste des branches existantes dans le dépôt. La branche courante est indiquée par un astérisque (*). 

git branch

Pour créer une nouvelle branche "feat/add-new-yaml-file", on utilise la commande suivante : 

git branch feat/add-new-yaml-file

La branche est maintenant créée, mais on est toujours sur la branche principale (main).
Pour vérifier que la branche a bien été créée, on peut utiliser à nouveau la commande git branch.
Le résultat devrait ressembler à ceci : 

  feat/add-new-yaml-file
* main

Démo : Changement de branches

Pour changer de branche et basculer sur la branche "feat/add-new-yaml-file", on utilise la commande suivante : 

git checkout feat/add-new-yaml-file

Le message de confirmation indique que l'on est maintenant sur la branche "feat/add-new-yaml-file". 

Switched to branch 'feat/add-new-yaml-file'

Pour vérifier que l'on est bien sur la bonne branche, on peut utiliser la commande git branch à nouveau.
Le résultat devrait ressembler à ceci : 

* feat/add-new-yaml-file
  main

Ajouter des fichiers et les commiter et pousser sur la nouvelle branche

Pour cette démonstration, on va ajouter un nouveau fichier YAML "hello-world.yml" dans le répertoire racine.
Le contenu du fichier hello-world.yml est le suivant : 

greeting: "Hello, World!"
is_active: true
count: 5
items:
  - item1
  - item2
  - item3

Ensuite, on ajoute le fichier à l'index avec la commande git add --all.
Après avoir ajouté le fichier, on peut vérifier l'état des fichiers dans le dépôt avec la commande git status.
Le résultat devrait ressembler à ceci : 

On branch feat/add-new-yaml-file
Changes to be committed:
  (use "git restore --staged <file ..." to unstage)
		new file:   hello-world.yml

Pour enregistrer les modifications dans l'historique du dépôt, on utilise la commande git commit avec un message décrivant les modifications apportées.
Par exemple : 

git commit -m "Add hello-world.yml file"

Le message de confirmation indique que le commit a été effectué avec succès. 

[feat/add-new-yaml-file 616d94f] Add yaml file
 1 file changed, 7 insertions(+)
 create mode 100644 hello-world.yml

Pour pousser les modifications vers le dépôt distant, on utilise la commande git push suivie du nom du dépôt distant et de la branche.
Par exemple, pour pousser la branche "feat/add-new-yaml-file" vers le dépôt distant nommé "origin" : 

git push origin feat/add-new-yaml-file

Le message de confirmation indique que la branche a été poussée avec succès vers le dépôt distant. 

Enumerating objects: 6, done.
Counting objects: 100% (6/6), done.
Delta compression using up to 12 threads
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 517 bytes | 258.00 KiB/s, done.
Total 5 (delta 2), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (2/2), completed with 1 local object.
remote:
remote: Create a pull request for 'feat/add-new-yaml-file' on GitHub by visiting:
remote:      https://github.com/YannJordan/formation-github-actions-ci-cd/pull/new/feat/add-new-yaml-file
remote:
To https://github.com/YannJordan/formation-github-actions-ci-cd.git
 * [new branch]      feat/add-new-yaml-file -> feat/add-new-yaml-file

On peut vérifier que la branche a bien été poussée vers le dépôt distant en allant sur la page du dépôt sur GitHub.
Nous devrions voir la nouvelle branche "feat/add-new-yaml-file" dans la liste des branches.

Nouvelle branche sur GitHub
Nouvelle branche sur GitHub
Source : Mon compte GitHub

Le gros avantage des branches est de pouvoir travailler sur des fonctionnalités ou des corrections de bugs sans affecter la branche principale (main).
Une fois les modifications terminées et testées, on peut fusionner la branche dans la branche principale.

Démo : Fusion des branches

Admettons qu'un collaborateur aurait ajouté un fichier test2, dont le contenu serait : 

New Test file

Si l'on bascule sur la branche principale (main) avec la commande git checkout main et que l'on fait un git pull --all, on récupère les modifications apportées par le collaborateur.

Ensuite, nous allons intégrer les modifications de la branche main dans la branche "feat/add-new-yaml-file".
Pour cela, on se place sur la branche "feat/add-new-yaml-file" avec la commande git checkout feat/add-new-yaml-file, puis on utilise la commande git merge main.

Le terminal va attendre que l'on saisisse un message de commit pour la fusion.
Si c'est VSCode qui est configuré comme éditeur par défaut, il faut saisir le message de commit dans l'éditeur, puis enregistrer et valider avec le bouton ✔️ (point 3 de l'image) pour finaliser la fusion.

Exemple de message pour la fusion des branches
L'éditeur VSCode s'ouvre pour saisir le message pour la fusion des branches.
Il est possible que le message doivent être saisi dans le terminal ou un autre éditeur selon la configuration Git.
Source : Mon PC

Le message de confirmation indique que la fusion a été effectuée avec succès. 

Merge made by the 'ort' strategy.
 test2 | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 test2

Il faut ensuite pousser les modifications vers le dépôt distant avec la commande git push origin feat/add-new-yaml-file.
Il est aussi possible de le faire directement depuis VSCode en cliquant sur le bouton Publish Branch

Découvrir les concepts de Forks, Pull Requests et Revue de Code

Plan de formation

Création de Forks

Un Fork est une copie personnelle d'un dépôt GitHub d'un autre utilisateur qui permet de proposer des modifications sans affecter le dépôt original.
Pour créer un Fork, il suffit de cliquer sur le bouton Fork en haut à droite de la page du dépôt GitHub.

Gestion de Pull Requests

Une Pull Request , en abrégé PR, est une demande de fusion de modifications d'une branche dans une autre, généralement utilisée pour intégrer des changements d'une branche de fonctionnalité dans la branche principale (main). La PR est également utilisée pour fusionner des modifications d'un Fork vers le dépôt d'origine.
Les PR permettent aux collaborateurs de revoir les modifications avant qu'elles ne soient fusionnées, assurant ainsi la qualité du code et facilitant la collaboration.

Revue de Code

La revue de code est le processus par lequel les modifications proposées dans une Pull Request sont examinées par d'autres développeurs avant d'être fusionnées.
Cela permet de détecter les erreurs, d'améliorer la qualité du code et de partager les connaissances au sein de l'équipe.

Les relecteurs peuvent laisser des commentaires, suggérer des modifications et approuver ou rejeter la Pull Request.

Créer des Forks

Plan de formation

Démo : Création d'un Fork

Afin de pouvoir créer un Fork, il faut que le dépôt d'origine soit public ou que vous ayez les droits nécessaires pour forker un dépôt privé.
De plus, il est nécessaire d'avoir un compte GitHub pour pouvoir créer un Fork.

Pour cette démonstration, nous allons créer un Fork du dépôt utilisé pour la formation.
Nous allons sur la page du dépôt sur GitHub et cliquons sur le bouton Fork en haut à droite.

En cliquant sur le bouton Fork, une nouvelle page s'ouvre pour configurer diverses options pour le Fork.
Nous pouvons choisir le compte ou l'organisation où le Fork sera créé.
Nous pouvons également choisir de nommer le Fork ou de le conserver tel quel.
Enfin, nous pouvons choisir de copier toutes les branches ou seulement la branche main.

Création d'un Fork sur GitHub
Création d'un Fork sur GitHub
Source : Mon compte GitHub

Après avoir configuré les options, nous cliquons sur le bouton Create fork pour créer le Fork.
Le Fork est maintenant créé et nous sommes redirigés vers la page du Fork.
Nous pouvons voir que le Fork a été créé avec succès et que nous avons une copie complète du dépôt d'origine.

Créer une Pull Request

Plan de formation

Démo : Création d'une Pull Request

Pour cette démonstration, nous allons allons proposer une pull request depuis la branche "feat/add-new-yaml-file" vers la branche principale (main) du dépôt d'origine.
Nous allons ignorer le Fork pour cette démonstration.

Nous allons sur la page du dépôt sur GitHub et cliquons sur l'onglet Pull requests en haut de la page, puis sur le bouton Create pull request.
Nous sommes redirigés vers une nouvelle page pour créer la Pull Request.

Création d'une Pull Request sur GitHub - Étape 1
Création d'une Pull Request sur GitHub - Étape 1
Source : Mon compte GitHub

Le point 1 de l'image permet de choisir la branche de destination (base) pour la Pull Request et le point 2 permet de choisir la branche source (compare) à partir de laquelle les modifications seront apportées.

Une fois les branches sélectionnées, un résumé des modifications est affiché en dessous.
Nous pouvons voir les fichiers modifiés, ajoutés ou supprimés ainsi que les différents commits qui ont été effectués.
Il reste plus qu'à cliquer sur le bouton Create pull request pour passer à l'étape suivante.

Création d'une Pull Request sur GitHub - Étape 2
Création d'une Pull Request sur GitHub - Étape 2
Source : Mon compte GitHub

Pull Request Titre et Description

Nous devons maintenant saisir un titre et une description pour la Pull Request.
Le titre doit être concis et descriptif, tandis que la description peut fournir plus de détails sur les modifications apportées.

Sur la droite de la page, nous pouvons voir diverses options pour gérer la Pull Request : telles que l'assignation de relecteurs, l'ajout d'étiquettes (labels), la sélection d'un projet ou d'un jalon (milestone) entre autre.

Pull Request Reviewers

Permet d'assigner des relecteurs pour la revue de code. Si Copilot est activé, il peut être défini comme reviewer avant qu'un humain ne le fasse. Les reviewers sont chargés d'examiner les modifications proposées, de laisser des commentaires, de suggérer des améliorations et d'approuver ou de rejeter la Pull Request. Cela garantit que le code est examiné par plusieurs personnes avant d'être fusionné, ce qui améliore la qualité et la sécurité du projet.

Pull Request Assignees

Permet d'assigner des personnes responsables de la Pull Request. Les personnes assignées (assignees) sont généralement celles qui doivent effectuer une action spécifique sur la Pull Request, comme la corriger, la compléter ou la fusionner. Contrairement aux reviewers, les assignees sont responsables du suivi et de la résolution de la Pull Request jusqu'à sa clôture. Cela facilite la gestion des responsabilités et le suivi de l'avancement dans les équipes de développement.

Pull Request Labels

Permet d'ajouter des étiquettes pour catégoriser la Pull Request. Cela permet de mieux organiser et filtrer les Pull Requests pour trouver rapidement celles qui concernent un sujet spécifique.

Pull Request Projects

Les projets (Projects) sur GitHub servent à organiser et suivre l'avancement des tâches, fonctionnalités ou bugs dans un tableau Kanban ou une liste. Associer une Pull Request à un projet permet de visualiser son état d'avancement, de lier le travail de développement à la gestion de projet, et de faciliter la collaboration et le suivi des workflows d'équipe. Cela aide à prioriser, planifier et automatiser certaines actions (comme déplacer la PR dans une colonne « En cours » ou « Terminé » lors de sa fusion).

Pull Request Milestones

Les jalons (Milestones) servent à regrouper plusieurs issues et pull requests sous un même objectif ou une même échéance (par exemple, une version à livrer). Associer une Pull Request à un milestone permet de suivre la progression vers cet objectif, de visualiser quelles tâches restent à accomplir, et d'organiser le travail par lots ou versions. Cela facilite la planification et la gestion des versions du projet.

Une fois toutes les informations saisies et les options configurées, nous cliquons sur le bouton Create pull request pour finaliser la création de la Pull Request.

Options Merge Pull Request

Une fois la Pull Request créée, nous pouvons voir diverses options pour fusionner la Pull Request sur le bouton Merge pull request.
Les options disponibles sont :

Effectuer des Revues de Code

Plan de formation

Démo : Revue de Code d'une Pull Request

Pour cette démonstration, nous allons effectuer une revue de code d'une Pull Request créée précédemment.
Nous allons sur la page de la Pull Request sur GitHub.

Nous pouvons voir les détails de la Pull Request, y compris le titre, la description, les commits et les fichiers modifiés.
Nous allons commencer par examiner les fichiers modifiés en cliquant sur l'onglet Files changed.

Dans l'onglet Files changed, nous pouvons voir les différences entre la branche source et la branche cible.
Les lignes ajoutées sont mises en évidence en vert, tandis que les lignes supprimées sont mises en évidence en rouge.

Nous pouvons laisser des commentaires sur des lignes spécifiques en cliquant sur l'icône de commentaire (symbole "+") en début de ligne.
Nous pouvons également approuver ou demander des modifications en utilisant les boutons en haut à droite de la page.

Ajout de commentaires dans une Pull Request
Il est possible d'ajouter des commentaires sur des lignes spécifiques.
Source : Mon compte GitHub

Il est également possible de faire des suggestions de modifications directement dans les commentaires.
Pour cela, il suffit de cliquer sur l'icône de suggestion (symbole "+-") dans la barre d'outils de la zone de commentaire.
Nous pouvons ensuite saisir la suggestion de modification dans le format approprié.

Ajout de suggestions dans une Pull Request
Ajouter une suggestion de modifications de code.
Source : Mon compte GitHub

Une fois que nous avons terminé la revue de code, nous pouvons cliquer sur le bouton Finish your review.
Nous pouvons choisir de laisser un commentaire général sans approuver la PR, d'approuver la PR ou de demander des modifications.

Terminer la revue du code sur GitHub
Options pour terminer la revue du code.
Source : Mon compte GitHub

Astuce :
Il n'est pas possible d'approuver sa propre Pull Request tout comme il n'est pas possible de demander à faire des changements sur sa propre Pull Request.

Il est possible de commiter les suggestions faites lors de la revue de code en cliquant sur le bouton Commit suggestion dans chaque commentaire de suggestion.
Les suggestions seront alors ajoutées en tant que nouveaux commits dans la branche source de la Pull Request.

Une fois que toutes les suggestions ont été commitées et que la Pull Request a été approuvée, nous pouvons fusionner la Pull Request en utilisant l'une des options de fusion disponibles (Merge commit, Squash and merge, Rebase and merge).
La Pull Request est alors fusionnée dans la branche cible et peut être supprimée si nécessaire. Elle restera visible dans les PR fermées pour référence future.

Utiliser les Issues GitHub

Plan de formation

Utilisation avancée des Issues

Les Issues sur GitHub sont des tickets utilisés pour suivre les tâches, les bugs, les demandes de fonctionnalités ou toute autre activité liée à un projet.
Chaque Issue peut contenir un titre, une description détaillée, des commentaires, des étiquettes (labels), des assignés (assignees), des jalons (milestones) et des projets (projects).
Les Issues permettent aux équipes de collaborer (en interne ou externe en cas de open source) efficacement en centralisant les discussions et le suivi des progrès.

Tags et Releases

Les Tags sont des marqueurs utilisés pour identifier des points spécifiques dans l'historique d'un dépôt Git, souvent utilisés pour marquer des versions (releases) importantes.
Les Releases sont des versions officielles d'un projet, généralement associées à un tag. Elles peuvent inclure des notes de version, des fichiers binaires ou des packages téléchargeables.
Les Releases facilitent la distribution et la gestion des versions d'un projet, permettant aux utilisateurs de télécharger des versions stables et documentées.

Démo : Création d'une Issue

Pour cette démonstration, nous allons créer une nouvelle Issue dans le dépôt utilisé pour la formation.
Nous allons sur la page du dépôt sur GitHub et cliquons sur l'onglet Issues en haut de la page, puis sur le bouton New issue.

Nous sommes redirigés vers une nouvelle page pour créer la Issue.
Nous devons saisir un titre et une description pour la Issue.
Le titre doit être concis et descriptif, tandis que la description peut fournir plus de détails sur le problème ou la tâche à accomplir.

Sur la droite de la page, nous pouvons voir diverses options pour gérer la Issue : telles que l'assignation de responsables (assignees), l'ajout d'étiquettes (labels), la sélection d'un projet ou d'un jalon (milestone).

Une fois toutes les informations saisies et les options configurées, nous cliquons sur le bouton Submit new issue pour créer la Issue.

Création d'une Issue sur GitHub
Création d'une Issue sur GitHub.
Source : Mon compte GitHub

La Issue est maintenant créée et nous sommes redirigés vers la page de la Issue.
Nous pouvons voir les détails de la Issue, y compris le titre, la description, les commentaires et les options de gestion.

Utiliser les Tags et Releases

Plan de formation

Démo : Création d'un Tag

La commande git tag va nous permettre d'afficher la liste des tags existants dans le dépôt.
Pour créer un nouveau tag, nous allons utiliser la commande git tag -a v0.1 -m "first tag".
Cette commande crée un tag annoté nommé "v0.1" avec le message "first tag". 

git tag
git tag -a v0.1 -m "first tag"

Pour pousser le tag vers le dépôt distant, nous utilisons la commande git push origin --tags. 

git push origin --tags

Nous pouvons vérifier que le tag a bien été poussé vers le dépôt distant en allant sur la page du dépôt sur GitHub et en cliquant sur l'onglet Tags.

Liste des Tags sur GitHub
Liste des Tags sur GitHub
Source : Mon compte GitHub

Démo : Création d'un Release

Pour créer une nouvelle Release, nous allons sur la page du dépôt sur GitHub et cliquons sur Releases dans le menu de droite, puis sur le bouton Create a new release.
Nous sommes redirigés vers une nouvelle page pour créer la Release.

Nous devons choisir un tag pour la Release.
Nous pouvons soit sélectionner un tag existant dans la liste déroulante, soit créer un nouveau tag en saisissant son nom dans le champ prévu à cet effet.
Nous allons choisir le tag "v0.1" que nous avons créé précédemment.
Nous devons également saisir un titre.

A l'aide du bouton Generate release notes, GitHub va automatiquement générer des notes de version basées sur les commits et les Pull Requests associées au tag sélectionné.
Nous pouvons ensuite modifier les notes de version si nécessaire.

Astuce :
Pour les versions Beta, il est recommandé d'ajouter le suffixe "-beta" au nom du tag, par exemple "v0.1-beta".
Cela permet de différencier les versions stables des versions de test.

Une fois toutes les informations saisies et les options configurées, nous cliquons sur le bouton Publish release pour créer la Release.

Découvrir les concepts de sécurité et de gestion avancée des dépôts

Plan de formation

Sécurité des Dépôts

La sécurité des dépôts sur GitHub est essentielle pour protéger le code source, les données sensibles et les informations confidentielles.
Voici quelques bonnes pratiques pour assurer la sécurité des dépôts :

Utilisation des Secrets

Les Secrets sur GitHub sont des variables d'environnement sécurisées utilisées pour stocker des informations sensibles telles que des clés API, des jetons d'accès ou des mots de passe.
Les Secrets sont chiffrés et ne sont pas visibles dans les logs ou le code source, ce qui les rend idéaux pour protéger les données sensibles lors de l'exécution de workflows GitHub Actions.

Pour utiliser les Secrets, vous devez les ajouter aux paramètres du dépôt ou de l'organisation.
Une fois ajoutés, vous pouvez référencer les Secrets dans vos workflows GitHub Actions en utilisant la syntaxe $.

Revues de Sécurité et Scans automatisés

Politiques de Branches

Les politiques de branches sur GitHub permettent de définir des règles et des exigences pour la gestion des branches dans un dépôt.
Cela inclut des exigences telles que l'approbation de revues de code, le passage de tests automatisés, ou la restriction des fusions directes dans certaines branches.
Les politiques de branches aident à maintenir la qualité du code, à prévenir les erreurs et à assurer la conformité aux normes de développement.

Gérer les permission et configurer les Secrets GitHub

Plan de formation

Démo : Gestion des permissions

Pour cette démonstration, nous allons gérer les permissions d'un dépôt GitHub.
Nous allons sur la page du dépôt sur GitHub et cliquons sur l'onglet Settings en haut de la page, puis sur Collaborators dans le menu de gauche.
Nous pouvons voir la liste des collaborateurs actuels et leurs rôles.
Nous pouvons ajouter un nouveau collaborateur en saisissant son nom d'utilisateur ou son adresse e-mail dans le champ prévu à cet effet, puis en cliquant sur le bouton Add collaborator.
Nous pouvons également modifier les rôles des collaborateurs existants en cliquant sur le menu déroulant à côté de leur nom et en sélectionnant le rôle approprié.
Les rôles disponibles sont :

Démo : Utilisation des Secrets

Les Secrets

Pour cette démonstration, nous allons ajouter un nouveau Secret à un dépôt GitHub.
Nous allons sur la page du dépôt sur GitHub et cliquons sur l'onglet Settings en haut de la page, puis sur Secrets and variables dans le menu de gauche, et enfin sur Actions.
Nous cliquons sur le bouton New repository secret pour ajouter un nouveau Secret.

Nous devons saisir un nom pour le Secret dans le champ Name et la valeur du Secret dans le champ Value.
Le nom du Secret doit être en majuscules et ne doit pas contenir d'espaces.
La valeur du Secret peut être n'importe quelle chaîne de caractères, y compris des clés API, des jetons d'accès ou des mots de passe.

Création d'un nouveau secret sur GitHub
Création d'un nouveau secret sur GitHub.
Source : Mon compte GitHub

Astuce :
Il n'est pas autorisé d'utiliser le mot "GITHUB" dans le nom d'un Secret car ce préfixe est réservé aux secrets gérés par GitHub.

Les Secrets sont chiffrés et ne sont pas visibles dans les logs ou le code source, ce qui les rend idéaux pour protéger les données sensibles lors de l'exécution de workflows GitHub Actions.

Une fois créé, un Secret ne peut pas être affiché à nouveau.
Si vous avez besoin de modifier la valeur d'un Secret, vous devez le supprimer et en créer un nouveau avec la même clé.

Les Variables

Les Variables dans GitHub Actions sont similaires aux Secrets, mais elles sont généralement utilisées pour stocker des valeurs non sensibles qui peuvent être partagées entre les jobs d'un workflow.
Les Variables peuvent être définies au niveau du dépôt, de l'organisation ou du workflow.

Configurer les Scans Automatisés et les Politiques de Branches

Plan de formation

Démo : Revue de Sécurité

Sur la page du dépôt sur GitHub, sur l'onglet Settings en haut de la page, puis sur Advanced Security dans le menu de gauche, nous pouvons voir diverses options pour configurer la sécurité du dépôt, y compris les analyses de code et les revues de sécurité.

Démo : Politiques des Branches

Pour cette démonstration, nous allons configurer des politiques de branches pour la branche principale (main) d'un dépôt GitHub.
Nous allons sur la page du dépôt sur GitHub et cliquons sur l'onglet Settings en haut de la page, puis sur Branches dans le menu de gauche.
Nous voyons une section intitulée Branch protection rules.
Nous cliquons sur le bouton Add branch ruleset pour ajouter une nouvelle règle de protection de branche.

Bypass list

La Bypass list permet de spécifier des utilisateurs ou des équipes qui peuvent contourner certaines règles de protection de branche. Par exemple, même si la fusion directe dans la branche principale est interdite pour la plupart des utilisateurs, les membres de la bypass list pourront effectuer des actions restreintes comme le push direct ou la fusion sans passer par une Pull Request.

Pour configurer la bypass list, il suffit d'ajouter les utilisateurs ou équipes concernés dans la section correspondante lors de la création ou modification d'une règle de protection de branche.

Target branches

La section Target branches permet de définir à quelles branches s'appliquera la règle de protection. Vous pouvez spécifier une ou plusieurs branches en utilisant leur nom exact (par exemple main) ou des motifs génériques (par exemple release/* pour toutes les branches commençant par "release/").

Cela permet d'appliquer des politiques différentes selon les branches (par exemple, des règles strictes sur main et plus souples sur les branches de développement).

Cases à cocher des Branch Rules (Branch Protection Rules)

Lors de la configuration d'une règle de protection de branche (Branch Protection Rule) sur GitHub, plusieurs cases à cocher sont disponibles pour affiner la sécurité et le workflow. Voici les principales options :

Ces options permettent d'adapter la protection des branches aux besoins de l'équipe et du projet, en renforçant la qualité et la sécurité du code fusionné dans les branches critiques.