Git

Objectifs du cours

Comprendre les concepts fondamentaux de Git
Maîtriser les commandes essentielles
Apprendre le cycle de travail collaboratif
Gérer les conflits de fusion
Utiliser Git avec des plateformes d'hébergement de code (GitLab)

Qu'est-ce que Git ?

Git est un système de contrôle de version distribué qui permet aux développeurs de suivre les modifications apportées aux fichiers et de collaborer efficacement sur des projets. Contrairement aux systèmes de contrôle de version centralisés, Git permet à chaque développeur de posséder une copie complète du dépôt, facilitant ainsi le travail hors ligne et la gestion des branches.

Fonctionnement de git

Le workflow, c'est la façon dont on utilise Git pour gérer les modifications dans un projet. Il se compose de plusieurs étapes clés : le répertoire de travail, la zone de staging, le dépôt local et le dépôt distant.

Workflow Git :

Répertoire de travail : C'est l'endroit où vous travaillez sur vos fichiers. Exemple : projet ouvert dans VS Code.

Zone de staging : C'est une étape intermédiaire où vous préparez les fichiers que vous souhaitez inclure dans votre prochain commit. Vous utilisez la commande git add . pour ajouter des fichiers à cette zone.

Dépôt local : C'est l'endroit où Git enregistre l'historique de vos modifications. Lorsque vous faites un commit avec git commit -m "message", les fichiers de la zone de staging sont enregistrés dans le dépôt local.

Dépôt distant : C'est une copie en ligne de votre dépôt, hébergée sur une plateforme comme GitLab . Vous utilisez la commande git push pour envoyer vos commits du dépôt local vers le dépôt distant, complétant ainsi la boucle et le workflow Git.

Note

À noter que ce processus est transparent et ne "déplace" pas physiquement les fichiers entre ces différentes zones. Les fichiers restent dans votre répertoire de travail, mais Git gère les états et les versions des fichiers à travers ces étapes.

Installer Git (une seule fois)

Téléchargement : Rendez-vous sur le site officiel de Git : https://git-scm.com/downloads et téléchargez la version adaptée à votre système d'exploitation (Windows, macOS, Linux).
Installation : Suivez les instructions d'installation et laisser par défaut les options proposées.
Pour utiliser Git, il faut également avoir un compte sur une plateforme d'hébergement de code comme GitHub, GitLab ou Bitbucket. Dans notre cours, nous allons utiliser GitLab.
1. Créer un compte (si ce n'est pas déjà fait) sur GitLab en utilisant votre adresse e-mail du Cégep
Configuration initiale de Git (à ne faire qu'une seule fois) :
- Ouvrez un terminal (ou Git Bash sur Windows).
- Configurez votre nom d'utilisateur et votre adresse e-mail avec les commandes suivantes :
```
git config --global user.name "Votre Nom"
git config --global user.email "courriel@cegepgarneau.ca"
```
- Vérifiez la configuration avec :
```
git config --list
```
Vous devriez voir votre nom et votre e-mail listés.

Cloner un dépôt distant vers votre machine locale

La première étape pour travailler avec Git est de cloner un dépôt distant vers votre machine locale.

Vous devez d'abord avoir préalablement créé un dépôt distant sur GitLab avant de continuer.

Sur votre ordinateur (Windows), vous allez à l'endroit (dossier) où vous voulez cloner le dépôt (exemple : OneDrive/Web2).
Ouvrez une fenêtre de terminal CMD (click droit + "Ouvrir dans Windows Terminal").
Tapez la commande suivante pour cloner le dépôt distant (remplacez <URL-du-dépôt> par l'URL de votre dépôt GitLab) :
```
git clone <URL-du-dépôt>
// Exemple : git clone https://gitlab.com/votre-nom-utilisateur/test-git.git
```

URL du dépôt GitLab : C'est l'adresse web que vous trouvez sur la page principale de votre projet GitLab, sous le bouton "Clone". Choisir l'option HTTPS. alt text

Résultat attendu : Un nouveau dossier est créé portant le nom du dépôt sur GitLab, contenant tous les fichiers du projet. Si le projet est vide, le dossier sera également vide, mais il contiendra un sous-dossier caché .git qui gère le suivi des versions.

Une fois le clone effectué, vous pouvez ouvrir le dossier du projet dans VS Code. Lorsque ce dossier est chargé dans VS Code, l'éditeur détecte automatiquement qu'il s'agit d'un dépôt Git et active les fonctionnalités de gestion de version intégrées.

À partir d'ici, toutes les opérations Git peuvent être effectuées directement depuis VS Code, ou en ligne de commande dans le terminal intégré.

Commandes Gits essentielles (important)

Voici les commandes Git essentielles que vous utiliserez fréquemment :

Commande	Description
`git clone <URL-du-dépôt>`	Clone un dépôt distant sur votre ordinateur local.
`git add .`	Ajoute les fichiers modifiés à la zone de staging.
`git commit -m "Message du commit"`	Valide les fichiers ajoutés à la zone de staging dans le dépôt local avec un message descriptif.
`git push origin <branche>`	Envoie les commits du dépôt local vers le dépôt distant sur la branche spécifiée (souvent `main` ou `master`).
`git pull origin <branche>`	Récupère les modifications du dépôt distant et les fusionne dans le répertoire de travail.

Workflows de git

Workflow basique (utilisateur unique)

Travailler sur les fichiers dans le répertoire de travail.
Ajouter les modifications à la zone de staging avec git add ..
Faire un commit des modifications dans le dépôt local avec `git commit -m "Message
Pousser les commits vers le dépôt distant avec git push origin main.
Répéter les étapes 1 à 4 pour chaque série de modifications.

Ce workflow est idéal pour les projets personnels ou lorsque vous travaillez seul sur un projet et ne génère aucun conflit de fusion car vous êtes le seul à apporter des modifications.

Workflow collaboratif (plusieurs utilisateurs, sans conflits)

Avant de commencer à travailler, récupérer les dernières modifications du dépôt distant avec git pull origin main.
Travailler sur les fichiers dans le répertoire de travail.
Ajouter les modifications à la zone de staging avec git add ..
Faire un commit des modifications dans le dépôt local avec `git commit -m "Message
Pousser les commits vers le dépôt distant avec git push origin main.
Répéter les étapes 1 à 5 pour chaque série de modifications.

Voir ce workflow complet étape par étape.

Workflow collaboratif avec gestion des conflits

Avant de commencer à travailler, récupérer les dernières modifications du dépôt distant avec git pull) origin main.
Travailler sur les fichiers dans le répertoire de travail.
Ajouter les modifications à la zone de staging avec git add ..
Faire un commit des modifications dans le dépôt local avec `git commit -m "Message
Pousser les commits vers le dépôt distant avec git push origin main.
Si des conflits surviennent lors du git pull, résoudre les conflits manuellement dans les fichiers concernés.
Après avoir résolu les conflits, ajouter les fichiers modifiés à la zone de staging avec git add ..
Faire un commit des résolutions de conflits dans le dépôt local avec git commit -m "Résolution des conflits".
Pousser les commits vers le dépôt distant avec git push origin main.

Voir ce workflow complet étape par étape avec gestion des conflits.

Le fichier .gitignore

Le fichier .gitignore est un fichier spécial dans un dépôt Git qui indique à Git quels fichiers ou dossiers il doit ignorer lors du suivi des modifications. Cela permet d'éviter d'ajouter accidentellement des fichiers temporaires, des dépendances, des fichiers de configuration locaux ou d'autres éléments qui ne devraient pas être versionnés.

Comment créer un fichier .gitignore

Créez un fichier nommé .gitignore (avec un point au début) à la racine de votre dépôt Git.
Ouvrez ce fichier dans un éditeur de texte (comme VS Code).
Ajoutez les patterns des fichiers ou dossiers à ignorer, un par ligne.

Syntaxe du fichier .gitignore

Commentaires : Les lignes commençant par # sont des commentaires et sont ignorées par Git.
Patterns simples : Le nom exact d'un fichier ou dossier, par exemple node_modules.
Wildcards : Utilisez * pour remplacer zéro ou plusieurs caractères, par exemple *.log pour ignorer tous les fichiers .log.
Dossiers : Ajoutez un / à la fin pour spécifier un dossier, par exemple temp/.
Négation : Commencez par ! pour inclure un fichier qui serait normalement ignoré, par exemple !important.txt.

Exemples courants

Voici un exemple de contenu pour un fichier .gitignore typique pour un projet web :

# Fichiers temporaires
*.tmp
*.temp

# Dossiers de dépendances
node_modules/
vendor/

# Fichiers de configuration locaux
.env
config.local.php

# Logs
*.log
logs/

# Fichiers système
.DS_Store
Thumbs.db

# Éditeur
.vscode/
.idea/

Comment utiliser .gitignore

Une fois le fichier .gitignore créé et configuré :

Git ignorera automatiquement les fichiers correspondant aux patterns lors des commandes git add . ou git status.
Si des fichiers déjà suivis par Git correspondent à un pattern dans .gitignore, vous devrez les retirer manuellement avec git rm --cached <fichier> puis committer la suppression.
Le fichier .gitignore lui-même doit être ajouté et committé pour être partagé avec l'équipe.

Conseil

Il existe des templates de .gitignore prédéfinis pour différents langages et frameworks sur GitHub. Vous pouvez les rechercher et les adapter à vos besoins.

Exercices pratiques

Exercice 1 : Collaboration Git en équipe (Équipe de 2)

Avant de commencer

Cet exercice se fait en équipe de 2. Chaque étudiant a un rôle précis à suivre. Lisez attentivement toutes les étapes avant de commencer et respectez l'ordre indiqué.

Objectif

Pratiquer le workflow collaboratif de Git en simulant une situation réelle où deux développeurs travaillent sur le même projet. Vous apprendrez à créer un dépôt partagé, à collaborer et à comprendre ce qui se passe lorsque deux personnes poussent des modifications vers le même dépôt distant.

Étape 1 — Étudiant 1 : Créer le dépôt distant sur GitLab

Connectez-vous à votre compte GitLab.
Cliquez sur New project (Nouveau projet).
Choisissez Create blank project (Créer un projet vide).
Donnez un nom au projet, par exemple : exercice-git-equipe.
Assurez-vous que la visibilité est réglée sur Private.
Décochez l'option « Initialize repository with a README » (Initialiser le dépôt avec un README).
Cliquez sur Create project.

Étape 2 — Étudiant 1 : Ajouter l'étudiant 2 comme membre du projet

Dans le projet GitLab, allez dans le menu de gauche : Manage → Members.
Cliquez sur Invite members (Inviter des membres).
Entrez l'adresse courriel (ou le nom d'utilisateur GitLab) de l'Étudiant 2.
Sélectionnez le rôle Maintainer.
Cliquez sur Invite.

Pourquoi Maintainer ?

Le rôle Maintainer permet à l'Étudiant 2 de pousser (push) directement sur la branche main. Avec un rôle inférieur (comme Developer), il pourrait rencontrer des restrictions selon la configuration du projet.

Étape 3 — Les 2 étudiants : Cloner le dépôt sur votre ordinateur

Chaque étudiant effectue les manipulations suivantes sur son propre ordinateur :

Sur GitLab, copiez l'URL HTTPS du projet (bouton Clone → Clone with HTTPS).
Sur votre ordinateur, ouvrez un terminal CMD à l'endroit où vous souhaitez cloner le projet.
Exécutez la commande :
```
git clone <URL-du-dépôt>
```
Ouvrez le dossier cloné dans VS Code.

À ce stade, les deux étudiants possèdent une copie locale du projet (vide).

Étape 4 — Étudiant 1 : Créer la page `index.html`

Dans VS Code, créez un fichier index.html à la racine du projet avec le contenu suivant :

html

<!DOCTYPE html>
<html lang="fr">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Accueil</title>
</head>
<body>

    <header>
        <h1>Mon site web</h1>
    </header>

    <nav>
        <ul>
            <li><a href="index.html">Accueil</a></li>
            <li><a href="contact.html">Contact</a></li>
        </ul>
    </nav>

    <main>
        <h2>Bienvenue sur la page d'accueil</h2>
        <p>Ceci est la page principale du site.</p>
    </main>

    <footer>
        <p>&copy; 2026 - Exercice Git en équipe</p>
    </footer>

</body>
</html>

Remarquez le lien vers contact.html dans la navigation. Cette page sera créée par l'Étudiant 2.

Étape 5 — Étudiant 1 : Envoyer son travail sur le dépôt distant

L'Étudiant 1 doit pousser son travail en premier. Dans le terminal intégré de VS Code :

git add .
git commit -m "Ajout de la page index.html"
git push origin main

✅ Le push devrait fonctionner sans problème puisque le dépôt distant est vide.

Étape 6 — Étudiant 2 : Créer la page `contact.html`

Important

L'Étudiant 2 commence à travailler en même temps que l'étudiant 1, sans faire de git pull au préalable. Cela simule une situation réelle où deux développeurs travaillent en parallèle.

Dans VS Code, créez un fichier contact.html à la racine du projet avec le contenu suivant :

html

<!DOCTYPE html>
<html lang="fr">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Contact</title>
</head>
<body>

    <header>
        <h1>Mon site web</h1>
    </header>

    <nav>
        <ul>
            <li><a href="index.html">Accueil</a></li>
            <li><a href="contact.html">Contact</a></li>
        </ul>
    </nav>

    <main>
        <h2>Contactez-nous</h2>
        <p>Vous pouvez nous joindre par courriel à info@exemple.com.</p>
    </main>

    <footer>
        <p>&copy; 2026 - Exercice Git en équipe</p>
    </footer>

</body>
</html>

Remarquez le lien vers index.html dans la navigation. Cette page a été créée par l'Étudiant 1.

Étape 7 — Étudiant 2 : Tenter d'envoyer son travail

L'Étudiant 2 fait ses commandes Git :

git add .
git commit -m "Ajout de la page contact.html"
git push origin main

🔴 Que va-t-il se passer ?

Le git push de l'Étudiant 2 sera rejeté par GitLab ! Vous verrez un message d'erreur semblable à :

 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'https://gitlab.com/...'
hint: Updates were rejected because the remote contains work that you do not
hint: have locally. Integrate the remote changes (e.g., 'git pull ...') before pushing again.

Pourquoi ? Parce que l'Étudiant 1 a déjà poussé des modifications (le fichier index.html) sur le dépôt distant. Le dépôt distant contient maintenant des commits que l'Étudiant 2 n'a pas dans son dépôt local. Git refuse le push pour protéger le travail existant et éviter d'écraser les modifications de l'Étudiant 1.

Étape 8 — Étudiant 2 : Résoudre la situation

Pour corriger la situation, l'Étudiant 2 doit d'abord récupérer les modifications du dépôt distant :

git pull origin main

Cette commande va :

Télécharger les commits de l'Étudiant 1 (le fichier index.html).
Fusionner automatiquement ces modifications avec le travail local de l'Étudiant 2.

Dans ce cas, il n'y a aucun conflit puisque les deux étudiants ont travaillé sur des fichiers différents (index.html et contact.html). La fusion se fait automatiquement.

Ensuite, l'Étudiant 2 peut finalement pousser son travail :

git push origin main

✅ Cette fois, le push fonctionne ! Le dépôt distant contient maintenant les deux fichiers : index.html et contact.html.

Exercice 2 : Collaboration continue - Ajout d'images (Équipe de 2)

Avant de commencer

Cet exercice continue directement après l'Exercice 1. À ce stade, l'Étudiant 2 a poussé ses modifications, mais l'Étudiant 1 n'a pas encore fait de pull pour récupérer contact.html.

Objectif

Comprendre l'importance de faire un git pull avant chaque session de travail pour s'assurer que votre dépôt local est à jour. Les deux étudiants vont travailler simultanément sur leurs pages respectives en ajoutant une image, en respectant le workflow collaboratif.

Rappel du Workflow collaboratif (sans conflits)

Comme vu dans la théorie, le workflow collaboratif commence toujours par :

Avant de commencer à travailler, récupérer les dernières modifications du dépôt distant avec git pull origin main.
Travailler sur les fichiers dans le répertoire de travail.
Ajouter les modifications à la zone de staging avec git add ..
Faire un commit des modifications dans le dépôt local avec git commit -m "Message".
Pousser les commits vers le dépôt distant avec git push origin main.

Pourquoi cette étape initiale est-elle cruciale ? Parce que si vous commencez à travailler sur une version obsolète du projet, vous risquez de rencontrer des problèmes lors du push (comme dans l'Exercice 1). Le git pull garantit que vous avez toutes les modifications récentes avant de commencer.

Étape 1 — Étudiant 1 : Récupérer les modifications récentes

L'Étudiant 1 doit commencer par récupérer le travail de l'Étudiant 2 (le fichier contact.html) :

git pull origin main

✅ Maintenant, l'Étudiant 1 a le projet complet avec les deux pages.

Étape 2 — Les 2 étudiants : Préparer le dossier images

Chaque étudiant doit créer un dossier images à la racine du projet et y placer une image.

Dans VS Code, créez un nouveau dossier nommé images à la racine du projet.
Téléchargez ou créez une image simple (par exemple, une image de 200x200 pixels avec du texte "Image Étudiant 1" ou "Image Étudiant 2").
Nommez l'image image-etudiant-1.jpg pour l'Étudiant 1 et image-etudiant-2.jpg pour l'Étudiant 2.
Placez l'image dans le dossier images/.

Organisation des fichiers

Il est recommandé de placer les images dans un dossier dédié pour une meilleure organisation du projet. Cela facilite la maintenance et évite de polluer la racine du projet.

Étape 3 — Étudiant 1 : Modifier `index.html` pour ajouter l'image

L'Étudiant 1 modifie sa page index.html en ajoutant l'image dans la section <main> :

html

<main>
    <h2>Bienvenue sur la page d'accueil</h2>
    <p>Ceci est la page principale du site.</p>
    <img src="images/image-etudiant-1.jpg" alt="Image Étudiant 1" width="200" height="200">
</main>

Étape 4 — Étudiant 2 : Modifier `contact.html` pour ajouter l'image

L'Étudiant 2 modifie sa page contact.html en ajoutant l'image dans la section <main> :

html

<main>
    <h2>Contactez-nous</h2>
    <p>Vous pouvez nous joindre par courriel à info@exemple.com.</p>
    <img src="images/image-etudiant-2.jpg" alt="Image Étudiant 2" width="200" height="200">
</main>

Étape 5 — Étudiant 1 : Envoyer ses modifications

L'Étudiant 1 suit le workflow collaboratif :

git add .
git commit -m "Ajout d'une image à la page index.html"
git push origin main

✅ Le push devrait réussir car l'Étudiant 1 a fait un pull au préalable.

Étape 6 — Étudiant 2 : Envoyer ses modifications

L'Étudiant 2 suit également le workflow collaboratif. Même s'il a déjà fait un pull récemment, il est bon de le refaire pour être sûr :

git pull origin main
git add .
git commit -m "Ajout d'une image à la page contact.html"
git push origin main

✅ Le push devrait réussir. Comme les deux étudiants modifient des fichiers différents (index.html vs contact.html), il n'y a pas de conflit.

Étape 7 — Les 2 étudiants : S'assurer d'avoir la version finale du projet

Pour être certain que chacun a toutes les modifications, les deux étudiants font un dernier pull :

git pull origin main

✅ Maintenant, chaque étudiant possède :

index.html avec l'image de l'Étudiant 1
contact.html avec l'image de l'Étudiant 2
Le dossier images/ avec les deux images

Résumé de l'exercice

Cette façon de travailler (Workflow) se rapport au Workflow collaboratif (plusieurs utilisateurs, sans conflits) présenté dans la théorie de ce cours.

Voir ce workflow complet étape par étape.

Exercice 3 : Gestion des conflits de fusion (Équipe de 2)

Avant de commencer

Cet exercice continue directement après l'Exercice 2. À ce stade, les deux étudiants ont fait le git pull final et possèdent la version complète du projet avec les images. Important : Les deux étudiants doivent être physiquement devant l'ordinateur de l'Étudiant 1 pour observer en temps réel ce qui se passe lors de la gestion des conflits. Cela permet de comprendre visuellement le processus de résolution.

Objectif

Apprendre à gérer les conflits de fusion Git. Les conflits surviennent lorsque deux personnes modifient la même partie d'un fichier. Vous apprendrez à les identifier, les résoudre manuellement et à pousser la résolution.

Rappel : Quand surviennent les conflits ?

Les conflits de fusion se produisent lorsque :

Deux développeurs modifient la même ligne ou la même section d'un fichier.
Git ne peut pas fusionner automatiquement les changements car il ne sait pas quelle version garder.

Dans cet exercice, les deux étudiants vont modifier le même fichier styles.css, créant intentionnellement un conflit.

Étape 1 — Les 2 étudiants : Créer le dossier et fichier CSS

Chaque étudiant doit créer le dossier css à la racine du projet et y ajouter un fichier styles.css avec des règles de base.

Dans VS Code, créez un nouveau dossier nommé css à la racine du projet.
Créez un fichier styles.css dans ce dossier avec le contenu suivant :

css

/* Styles de base pour le site */
body {
    font-family: Arial, sans-serif;
    margin: 0;
    padding: 0;
}

header, nav, main, footer {
    padding: 20px;
}

Étape 2 — Étudiant 1 : Ajouter ses règles CSS

L'Étudiant 1 ajoute ses propres règles à styles.css. Modifiez le fichier pour ajouter :

css

/* Styles de base pour le site */
body {
    font-family: Arial, sans-serif;
    margin: 0;
    padding: 0;
    background-color: lightblue; /* Code ajouté par Étudiant 1 */
    font-size: 16px; /* Code ajouté par Étudiant 1 */
    line-height: 1.5; /* Code ajouté par Étudiant 1 */
}

header, nav, main, footer {
    padding: 20px;
}

header {
    background-color: #333;
    color: white;
}

Étape 3 — Étudiant 2 : Ajouter ses règles CSS

L'Étudiant 2 ajoute également ses propres règles à styles.css. Modifiez le fichier pour ajouter :

css

/* Styles de base pour le site */
body {
    font-family: Arial, sans-serif;
    margin: 0;
    padding: 0;
    background-color: lightgreen; /* Code ajouté par Étudiant 2 */
    color: darkgreen; /* Code ajouté par Étudiant 2 */
    text-align: center; /* Code ajouté par Étudiant 2 */
}

header, nav, main, footer {
    padding: 20px;
}

nav {
    background-color: #f4f4f4;
}

Attention : Les deux étudiants modifient la même ligne background-color de body. Cela va créer un conflit !

Étape 4 — Étudiant 2 : Envoyer ses modifications en premier

L'Étudiant 2 suit le workflow complet :

git pull origin main  # Pour être sûr d'être à jour
git add .
git commit -m "Ajout de styles CSS de base et couleur de fond"
git push origin main

✅ Le push réussit car l'Étudiant 2 est le premier à pousser.

Étape 5 — Étudiant 1 : Tenter d'envoyer ses modifications

L'Étudiant 1 fait ses commandes Git :

git add .
git commit -m "Ajout de styles CSS et couleur de fond"
git push origin main

🔴 Que va-t-il se passer ?

Le git push de l'Étudiant 1 sera rejeté ! Git détecte que le dépôt distant a évolué depuis le dernier pull de l'Étudiant 1. L'Étudiant 1 doit d'abord faire un git pull pour récupérer les changements de l'Étudiant 2.

Étape 6 — Étudiant 1 : Récupérer les modifications et gérer le conflit

L'Étudiant 1 exécute :

git pull origin main

Cette fois, Git ne peut pas fusionner automatiquement car les deux étudiants ont modifié les mêmes parties de la règle body dans styles.css. Vous verrez un message comme :

Auto-merging css/styles.css
CONFLICT (content): Merge conflict in css/styles.css
Automatic merge failed; fix conflicts and then commit the result.

Le fichier styles.css contient maintenant des marqueurs de conflit. Ouvrez-le dans VS Code :

css

/* Styles de base pour le site */
body {
    font-family: Arial, sans-serif;
    margin: 0;
    padding: 0;
<<<<<<< HEAD
    background-color: lightblue; /* Code ajoutée par Étudiant 1 */
    font-size: 16px; /* Code ajoutée par Étudiant 1 */   
    line-height: 1.5; /* Code ajoutée par Étudiant 1 */
=======
    background-color: lightgreen; /* Code ajoutée par Étudiant 2 */
    color: darkgreen; /* Code ajoutée par Étudiant 2 */
    text-align: center; /* Code ajoutée par Étudiant 2 */
>>>>>>> 1234567890abcdef... (commit hash)
}

header, nav, main, footer {
    padding: 20px;
}

header {
    background-color: #333;
    color: white;
}

nav {
    background-color: #f4f4f4;
}

Explication des marqueurs :

<<<<<<< HEAD : Marque le début de vos changements (Étudiant 1).
======= : Sépare vos changements des changements de l'autre branche.
>>>>>>> 1234567890abcdef... : Marque la fin des changements de l'autre branche (Étudiant 2).

Étape 7 — Résoudre le conflit manuellement

Les deux étudiants doivent observer l'écran de l'Étudiant 1. Résoudre le conflit en choisissant une version ou en combinant les deux :

Option 1 : Garder la version de l'Étudiant 1 Supprimez les marqueurs et gardez :

    background-color: lightblue;
    font-size: 16px;
    line-height: 1.5;

Option 2 : Garder la version de l'Étudiant 2 Remplacez par :

    background-color: lightgreen;
    color: darkgreen;
    text-align: center;

Supprimez tous les marqueurs (<<<<<<<, =======, >>>>>>>) et gardez seulement le code souhaité.

Conseil

Discutez avec votre coéquipier pour décider de la résolution. Dans un vrai projet, la communication est essentielle !

Étape 8 — Valider la résolution du conflit

Après avoir résolu le conflit dans le fichier :

git add css/styles.css
git commit -m "Résolution du conflit dans styles.css : VERSION X conservée"
git push origin main

✅ Le push réussit maintenant ! Le conflit est résolu.

Étape 9 — Étudiant 2 : Récupérer la résolution finale

Pour s'assurer d'avoir la version finale :

git pull origin main

✅ Les deux étudiants ont maintenant le projet avec le fichier styles.css résolu.

Résumé de l'exercice

Importance de l'observation en binôme

Les conflits Git peuvent sembler abstraits au début. En étant physiquement côte à côte devant l'ordinateur de l'Étudiant 1, vous pouvez voir :

Les marqueurs de conflit apparaître en temps réel
Comment VS Code colore les sections conflictuelles
L'impact visuel des résolutions
La communication nécessaire entre coéquipiers

Cette expérience pratique est cruciale pour comprendre pourquoi les conflits arrivent et comment les éviter à l'avenir (en communiquant mieux et en travaillant sur des sections différentes quand possible).

Exercice 4 : Collaboration finale - Accessibilité et styles avancés (Équipe de 2)

Avant de commencer

Cet exercice continue directement après l'Exercice 3. Les deux étudiants ont résolu le conflit et possèdent la version finale du projet avec styles.css résolu. Ils vont maintenant travailler simultanément pour améliorer le site web de manière collaborative.

Objectif

Créer un site web complet, accessible et visuellement attrayant. L'Étudiant 1 se concentre sur l'accessibilité, tandis que l'Étudiant 2 améliore les styles CSS. À la fin, le site doit être conforme aux standards d'accessibilité de base et avoir un design visuel professionnel.

Rappel des rôles

Étudiant 1 : Responsable de l'accessibilité
Étudiant 2 : Responsable de styliser le site

Étape 1 — Les 2 étudiants : Rappel du workflow

Avant de commencer, assurez-vous d'être synchronisés :

git pull origin main

Étape 2 — Étudiant 1 : Améliorer l'accessibilité

Rendez les pages index.html et contact.html accessibles en :

Ajoutant des attributs aria-label appropriés sur les éléments <nav> et <main>.
Créant un lien d'évitement (skip link) caché en haut de chaque page, menant directement au contenu principal (rappel : voir le Module 4 pour la technique du lien caché avec CSS).

Travaillez sur les deux fichiers HTML pour assurer une accessibilité cohérente.

Étape 3 — Étudiant 2 : Améliorer les styles CSS

Affine le fichier styles.css en :

Utilisant des sélecteurs HTML et, au besoin, des classes personnalisées pour styliser les éléments.
Ajoutant un logo au site (par exemple, dans le header ou comme image de fond).
Créant un design visuel plus complet et professionnel.

Utilisez les sélecteurs vus dans les modules précédents pour cibler précisément les éléments.

Étape 4 — Envoi des modifications

Chaque étudiant envoie ses modifications quand il est prêt :

Étudiant 1 (accessibilité) :

git add .
git commit -m "Amélioration de l'accessibilité : aria-label et skip link"
git push origin main

Étudiant 2 (styles) :

git pull origin main  # Au cas où l'Étudiant 1 a poussé en premier
git add .
git commit -m "Amélioration des styles CSS et ajout du logo"
git push origin main

Étape 5 — Gestion des conflits (si nécessaire)

Si le dernier étudiant à pousser rencontre un rejet :

Faire git pull origin main.
Résoudre les conflits manuellement (comme dans l'Exercice 3).
Valider la résolution avec git add, git commit, git push.

Étape 6 — Synchronisation finale

Les deux étudiants font un dernier pull pour s'assurer d'avoir la version complète :

git pull origin main

Résultat attendu

À la fin de cet exercice, le site doit :

Être accessible (aria-label, skip link fonctionnel).
Avoir un design visuel complet et professionnel.
Être synchronisé entre les deux étudiants.

Un conflit survient lorsque les mêmes fichiers ont été modifiés localement et sur le dépôt distant. Git marque les sections conflictuelles dans les fichiers et vous devez les résoudre manuellement.

Question 8

Comment résoudre un conflit lors d'un git pull ?

Réponse

Éditez les fichiers en conflit pour choisir quelles modifications garder, supprimez les marqueurs de conflit (<<<<<<<, =======, >>>>>>>), puis utilisez git add et git commit pour valider la résolution.

bash

# Après édition manuelle des fichiers
git add fichier-en-conflit.html
git commit -m "Résolution du conflit"

Question 9

Quelle séquence de commandes utiliser pour envoyer des modifications au dépôt distant ?

Réponse

La séquence typique est : git add ., git commit -m "message", git pull origin main (pour synchroniser), puis git push origin main.

bash

git add .
git commit -m "Modifications apportées"
git pull origin main
git push origin main

Question 10

Comment synchroniser son dépôt local avec le dépôt distant ?

Réponse

Utilisez git pull pour récupérer les modifications distantes, puis git push pour envoyer vos modifications locales. Cela assure que les deux dépôts sont à jour.

bash

git pull origin main
git push origin main

Question 11

Mise en situation : deux programmeurs travaillent en même temps sur un projet. Quelle commande devraient-ils exécuter en premier avant même de commencer à coder ?

Également : que se passerait-il si cette commande est ignorée ?

Réponse

Ils devraient exécuter git pull pour récupérer les dernières modifications du dépôt distant et s'assurer que leur dépôt local est synchronisé avant de commencer à travailler.

bash

git pull origin main

Si ils oubliaient cette étape et commençaient à travailler sans synchroniser, ils risqueraient de rencontrer des conflits lors du push, car leurs modifications locales pourraient être basées sur une version obsolète du projet. Le push serait rejeté et ils devraient faire un pull pour récupérer les changements avant de pouvoir pousser à nouveau.

Git ​

Objectifs du cours ​

Qu'est-ce que Git ? ​

Fonctionnement de git ​

Installer Git (une seule fois) ​

Cloner un dépôt distant vers votre machine locale ​

Commandes Gits essentielles (important) ​

Workflows de git ​

Workflow basique (utilisateur unique) ​

Workflow collaboratif (plusieurs utilisateurs, sans conflits) ​

​

Workflow collaboratif avec gestion des conflits ​

Le fichier .gitignore ​

Comment créer un fichier .gitignore ​

Syntaxe du fichier .gitignore ​

Exemples courants ​

Comment utiliser .gitignore ​

Exercices pratiques ​

Exercice 1 : Collaboration Git en équipe (Équipe de 2) ​

Objectif ​

Étape 1 — Étudiant 1 : Créer le dépôt distant sur GitLab ​

Étape 2 — Étudiant 1 : Ajouter l'étudiant 2 comme membre du projet ​

Étape 3 — Les 2 étudiants : Cloner le dépôt sur votre ordinateur ​

Étape 4 — Étudiant 1 : Créer la page index.html ​

Étape 5 — Étudiant 1 : Envoyer son travail sur le dépôt distant ​

Étape 6 — Étudiant 2 : Créer la page contact.html ​

Étape 7 — Étudiant 2 : Tenter d'envoyer son travail ​

🔴 Que va-t-il se passer ? ​

Étape 8 — Étudiant 2 : Résoudre la situation ​

Exercice 2 : Collaboration continue - Ajout d'images (Équipe de 2) ​

Objectif ​

Rappel du Workflow collaboratif (sans conflits) ​

Étape 1 — Étudiant 1 : Récupérer les modifications récentes ​

Étape 2 — Les 2 étudiants : Préparer le dossier images ​

Étape 3 — Étudiant 1 : Modifier index.html pour ajouter l'image ​

Étape 4 — Étudiant 2 : Modifier contact.html pour ajouter l'image ​

Étape 5 — Étudiant 1 : Envoyer ses modifications ​

Étape 6 — Étudiant 2 : Envoyer ses modifications ​

Étape 7 — Les 2 étudiants : S'assurer d'avoir la version finale du projet ​

Exercice 3 : Gestion des conflits de fusion (Équipe de 2) ​

Objectif ​

Rappel : Quand surviennent les conflits ? ​

Étape 1 — Les 2 étudiants : Créer le dossier et fichier CSS ​

Étape 2 — Étudiant 1 : Ajouter ses règles CSS ​

Étape 3 — Étudiant 2 : Ajouter ses règles CSS ​

Étape 4 — Étudiant 2 : Envoyer ses modifications en premier ​

Étape 5 — Étudiant 1 : Tenter d'envoyer ses modifications ​

🔴 Que va-t-il se passer ? ​

Étape 6 — Étudiant 1 : Récupérer les modifications et gérer le conflit ​

Étape 7 — Résoudre le conflit manuellement ​

Étape 8 — Valider la résolution du conflit ​

Étape 9 — Étudiant 2 : Récupérer la résolution finale ​

Résumé de l'exercice ​

Exercice 4 : Collaboration finale - Accessibilité et styles avancés (Équipe de 2) ​

Objectif ​

Rappel des rôles ​

Étape 1 — Les 2 étudiants : Rappel du workflow ​

Étape 2 — Étudiant 1 : Améliorer l'accessibilité ​

Étape 3 — Étudiant 2 : Améliorer les styles CSS ​

Étape 4 — Envoi des modifications ​

Étape 5 — Gestion des conflits (si nécessaire) ​

Étape 6 — Synchronisation finale ​

Résultat attendu ​

Vérification des connaissances ​

Question 1 ​

Question 2 ​

Question 3 ​

Question 4 ​

Question 5 ​

Question 6 ​

Question 7 ​

Question 8 ​

Question 9 ​

Question 10 ​

Question 11 ​

Git

Objectifs du cours

Qu'est-ce que Git ?

Fonctionnement de git

Installer Git (une seule fois)

Cloner un dépôt distant vers votre machine locale

Commandes Gits essentielles (important)

Workflows de git

Workflow basique (utilisateur unique)

Workflow collaboratif (plusieurs utilisateurs, sans conflits)

Workflow collaboratif avec gestion des conflits

Le fichier .gitignore

Comment créer un fichier .gitignore

Syntaxe du fichier .gitignore

Exemples courants

Comment utiliser .gitignore

Exercices pratiques

Exercice 1 : Collaboration Git en équipe (Équipe de 2)

Objectif

Étape 1 — Étudiant 1 : Créer le dépôt distant sur GitLab

Étape 2 — Étudiant 1 : Ajouter l'étudiant 2 comme membre du projet

Étape 3 — Les 2 étudiants : Cloner le dépôt sur votre ordinateur

Étape 4 — Étudiant 1 : Créer la page `index.html`

Étape 5 — Étudiant 1 : Envoyer son travail sur le dépôt distant

Étape 6 — Étudiant 2 : Créer la page `contact.html`

Étape 7 — Étudiant 2 : Tenter d'envoyer son travail

🔴 Que va-t-il se passer ?

Étape 8 — Étudiant 2 : Résoudre la situation

Exercice 2 : Collaboration continue - Ajout d'images (Équipe de 2)

Objectif

Rappel du Workflow collaboratif (sans conflits)

Étape 1 — Étudiant 1 : Récupérer les modifications récentes

Étape 2 — Les 2 étudiants : Préparer le dossier images

Étape 3 — Étudiant 1 : Modifier `index.html` pour ajouter l'image

Étape 4 — Étudiant 2 : Modifier `contact.html` pour ajouter l'image

Étape 5 — Étudiant 1 : Envoyer ses modifications

Étape 6 — Étudiant 2 : Envoyer ses modifications

Étape 7 — Les 2 étudiants : S'assurer d'avoir la version finale du projet

Exercice 3 : Gestion des conflits de fusion (Équipe de 2)

Objectif

Rappel : Quand surviennent les conflits ?

Étape 1 — Les 2 étudiants : Créer le dossier et fichier CSS

Étape 2 — Étudiant 1 : Ajouter ses règles CSS

Étape 3 — Étudiant 2 : Ajouter ses règles CSS

Étape 4 — Étudiant 2 : Envoyer ses modifications en premier

Étape 5 — Étudiant 1 : Tenter d'envoyer ses modifications

🔴 Que va-t-il se passer ?

Étape 6 — Étudiant 1 : Récupérer les modifications et gérer le conflit

Étape 7 — Résoudre le conflit manuellement

Étape 8 — Valider la résolution du conflit

Étape 9 — Étudiant 2 : Récupérer la résolution finale

Résumé de l'exercice

Exercice 4 : Collaboration finale - Accessibilité et styles avancés (Équipe de 2)

Objectif

Rappel des rôles

Étape 1 — Les 2 étudiants : Rappel du workflow

Étape 2 — Étudiant 1 : Améliorer l'accessibilité

Étape 3 — Étudiant 2 : Améliorer les styles CSS

Étape 4 — Envoi des modifications

Étape 5 — Gestion des conflits (si nécessaire)

Étape 6 — Synchronisation finale

Résultat attendu

Vérification des connaissances

Question 1

Question 2

Question 3

Question 4

Question 5

Question 6

Question 7

Question 8

Question 9

Question 10

Question 11