Programme de la journée

Objectifs de la journée

À la fin de la journée, vous saurez :

• Expliquer ce qu'est le DevOps et pourquoi les entreprises l'adoptent
• Distinguer intégration continue, livraison continue et déploiement continu
• Cartographier le pipeline d'une application web
• Contribuer à un dépôt partagé : branche → Pull Request → revue → merge
• Résoudre un conflit Git sans paniquer

Lien avec le titre pro DWWM : compétence « Préparer et exécuter le déploiement d'une application web ». Votre pipeline de la semaine pourra servir de preuve dans votre dossier professionnel.

Où en est-on ? La boucle DevOps

            ╭─────────── DEV ───────────╮      ╭──────────────── OPS ────────────────╮
          ╭─▶ PLAN ──▶ CODE ──▶ BUILD ──╮      ╭─▶ RELEASE ──▶ DEPLOY ──▶ OPERATE ──╮
          │   ▲━━━━━━━━━━━▲             ▼      │                                     │
          │    AUJOURD'HUI             TEST ───╯                                     │
          │                                                                          │
          ╰───────────────────────────────── MONITOR ◀───────────────────────────────╯

Aujourd'hui : comprendre la boucle entière, puis maîtriser les deux premières cases — planifier et coder à plusieurs avec Git.

Le fil rouge de la semaine : TaskFlow

Un gestionnaire de tâches volontairement simple : l'effort porte sur le DevOps, pas sur le code.

taskflow/
├── front/   # Vite + JavaScript (sans framework), servi par nginx
├── api/     # Node 20 + Express, port 3000, GET /health
└── (BDD)    # PostgreSQL 16 : une table "tasks"

Une histoire (trop) banale

Vendredi, 18h. Léa, développeuse, a fini sa fonctionnalité. « Ça marche sur ma machine ! » Elle envoie un zip à Karim, administrateur système.
Karim copie les fichiers sur le serveur par FTP. Le site affiche une page blanche.
Il manquait une version de PHP, un fichier de configuration et une étape de migration de la base de données.
Samedi, 2h du matin : retour à l'ancienne version. Lundi : réunion « qui a cassé la prod ? ».

• FTP (File Transfer Protocol) : envoi manuel de fichiers vers un serveur
• Prod (production) : l'environnement où sont les vrais utilisateurs

Questions : où sont les problèmes ? Est-ce la faute de Léa ? de Karim ?

Le « mur de la confusion »

      ÉQUIPE DEV                  ║║║               ÉQUIPE OPS
   (développement)                ║║║          (exploitation, « Ops »)
                                  ║║║
  Objectif : livrer vite          ║║║    Objectif : que rien ne casse
  des nouveautés                  ║║║    (stabilité)
                                  ║║║
  « Mon code est fini,     ─── zip ──▶     « Encore une livraison
    à vous de jouer ! »           ║║║        le vendredi soir… »
                                  ║║║
  Mesuré sur : fonctionnalités    ║║║    Mesuré sur : disponibilité

Deux équipes, deux objectifs opposés : l'une veut changer, l'autre veut stabiliser. Résultat : livraisons rares, énormes, risquées… et des reproches.

Une analogie : la cuisine et la salle

Le DevOps, c'est faire travailler Dev et Ops comme une seule équipe, avec un objectif commun : livrer souvent et sans casse.

Petite histoire du DevOps

DevOps = contraction de Development et Operations. Le mot vient du nom de la conférence de 2009.

Ce qu'est (et n'est pas) le DevOps

C'est une culture + des pratiques + des outils pour livrer des logiciels rapidement et de façon fiable.

CALMS : les 5 piliers

Culture avant outils : une équipe qui se renvoie la faute restera lente, même avec les meilleurs outils du monde.

La boucle infinie du cycle de vie

            ╭─────────── DEV ───────────╮      ╭──────────────── OPS ────────────────╮
          ╭─▶ PLAN ──▶ CODE ──▶ BUILD ──╮      ╭─▶ RELEASE ──▶ DEPLOY ──▶ OPERATE ──╮
          │                             ▼      │                                     │
          │                            TEST ───╯                                     │
          │                                                                          │
          ╰────────── retours : bugs, usages, mesures ◀── MONITOR ◀──────────────────╯

• Le symbole ∞ (infini) : la boucle ne s'arrête jamais
• Chaque tour de boucle = une petite amélioration livrée aux utilisateurs
• Ce que l'on observe en production (monitor) nourrit la planification suivante (plan)

Les 8 étapes appliquées à TaskFlow

Mesurer : les 4 indicateurs DORA

DORA (DevOps Research and Assessment) : équipe de recherche qui étudie des milliers d'entreprises chaque année.

Deux indicateurs de vitesse, deux de stabilité : les meilleures équipes sont bonnes sur les quatre à la fois.

Les chiffres : élite vs faible

Ordres de grandeur issus des rapports State of DevOps (DORA, 2019-2023).

Surprise : les équipes qui livrent le plus souvent sont aussi celles qui cassent le moins.

Pourquoi « petit et souvent » est moins risqué

  Livraison rare (tous les 3 mois)          Livraisons fréquentes (chaque jour)

  ████████████████████████████  ← 300        █ █ █ █ █ █ █ █ █ █   ← 5 changements
  changements d'un coup                      à chaque fois

  Panne ? Lequel des 300 est fautif ?        Panne ? C'est l'un des 5 derniers.
  → des jours d'enquête                      → trouvé et corrigé en minutes

Analogie : déménager tout un appartement en un seul voyage, ou faire plusieurs petits trajets. Si un carton tombe, vous savez exactement lequel.

À retenir — 1.1

• Le DevOps est né du mur entre Dev (changer vite) et Ops (rester stable)
• C'est d'abord une culture (CALMS), les outils viennent ensuite
• Le cycle de vie d'une application est une boucle infinie en 8 étapes
• On mesure avec les 4 indicateurs DORA : 2 de vitesse, 2 de stabilité
• Petit et souvent = moins de risques, réparations plus rapides

Le problème : l'intégration « big bang »

  Semaine 1          Semaine 2          Semaine 3          Le jour J
  Alice ───────────────────────────────────────────┐
  (formulaire)                                     │
  Bob ─────────────────────────────────────────────┼──▶  ON FUSIONNE TOUT
  (base de données)                                │     → 47 conflits
  Chloé ───────────────────────────────────────────┘     → l'appli ne démarre plus
  (design)                                               → 3 jours pour réparer

Chacun travaille seul trop longtemps. Plus on attend pour assembler (« intégrer ») le travail, plus l'assemblage est douloureux.

Intégration continue (CI)

CI = Continuous Integration. On intègre son travail dans la branche commune souvent (au moins une fois par jour), et chaque envoi est vérifié automatiquement.

  git push ──▶ un serveur détecte le push ──▶ installe ──▶ lint ──▶ tests ──▶ build
                                                                               │
                          tout est vert : on peut fusionner  ◀───────────────┤
                          un test échoue : l'auteur est prévenu en minutes ◀─┘

Les 3 règles :

1. Petits commits, intégrés souvent
2. Tests automatisés : aucune vérification ne repose sur la mémoire d'un humain
3. Build rouge = priorité de toute l'équipe : on répare avant de continuer

La CI sur TaskFlow : ce que la machine exécute

Ce que vous tapiez à la main, la CI le fait à chaque push :

$ npm ci
added 312 packages in 6s
$ npm run lint
> eslint src tests
$ npm test
 ✓ tests/app.test.js (6 tests) 45ms
 Test Files  1 passed (1)
      Tests  6 passed (6)

• Lint : vérification automatique du style et des erreurs courantes (ESLint)
• Tests : vérifient que le code fait ce qu'il doit (Vitest)
• Si une seule commande échoue → le pipeline est rouge → la fusion est bloquée

Livraison continue (Continuous Delivery)

On va plus loin : à chaque changement validé, l'application est prête à être déployée (image construite, testée, rangée).

  push ──▶ CI (tests) ──▶ build de l'image ──▶ image prête ──▶ [ BOUTON ] ──▶ prod
                                                                  
                                                     un humain décide QUAND

• Le déploiement est une action simple (un clic), pas une procédure de 3 pages
• L'humain choisit le moment : après une démo client, hors période de soldes…
• Abréviation : CD… comme la suivante, d'où la confusion !

Déploiement continu (Continuous Deployment)

Dernière marche : aucun humain entre le merge et la production.

  push ──▶ CI (tests) ──▶ build de l'image ──▶ déploiement automatique ──▶ prod
                                                        
                                       si tous les tests passent, ça part en prod

• Exige une grande confiance dans les tests et la supervision
• Chaque merge sur main est visible par les utilisateurs quelques minutes plus tard
• C'est ce que vous ferez avec TaskFlow le jour 4 : un merge → la prod change seule

Les trois côte à côte

Analogie de la boulangerie :

• CI = on goûte chaque fournée dès sa sortie du four
• Livraison continue = le pain est toujours prêt en vitrine, le vendeur le tend au client
• Déploiement continu = le pain part tout seul chez le client par drone

Les environnements : dev, test, prod

• VPS (Virtual Private Server) : un serveur virtuel loué chez un hébergeur — ce qu'on utiliserait en vrai, vu en théorie au jour 4
• Règle d'or : les environnements doivent être le plus semblables possible — c'est ce que Docker va permettre

« You build it, you run it »

« Vous l'avez construit, vous le faites tourner. » — Werner Vogels, Amazon (2006)

En tant que développeur web, vous êtes directement concerné : le DevOps fait partie de votre métier.

À retenir — 1.2

• CI : intégrer souvent + vérifier automatiquement à chaque push
• Livraison continue : toujours prêt à déployer, un humain appuie sur le bouton
• Déploiement continu : en prod sans humain, si tous les voyants sont verts
• Trois environnements : dev → test → prod, aussi semblables que possible
• Responsabilité partagée : « you build it, you run it »

Une case par étape de la boucle

PaaS (Platform as a Service) : un hébergeur qui fait tourner votre application sans que vous gériez le serveur.

Ce que nous utiliserons cette semaine, et pourquoi

• SSH (Secure Shell) : connexion sécurisée à un serveur distant (vue en théorie au jour 4)

Le pipeline cible de TaskFlow (vendredi soir… sans stress)

 Développeur        GitHub                  GitHub Actions              Production (taskflow-prod)
 ───────────        ──────                  ──────────────              ──────────────────────────
 git switch -c ───▶ Pull Request ─────────▶ ci.yml (J3)
 feature/x          revue d'un pair         lint + tests + build
                        │                       │
                    merge sur main ◀─────── checks verts
                        │
                        └─────────────────▶ release.yml (J3)
                    ghcr.io ◀────────────── build + push des images
                                                │
                                                └─ job deploy (J4) ───▶ docker compose up -d
                                                   (runner local)       Nginx HTTPS ◀── utilisateurs
                                                                        /health ◀── Uptime Kuma

Aujourd'hui : comprendre ce schéma. Jour 4 au soir : chaque flèche fonctionnera pour de vrai.

TP 0 — Déroulé (1h)

Énoncé complet : tp/tp0-cartographie-pipeline/README.md

TP 0 — Lire un workflow (sans l'écrire)

name: CI                        # nom affiché dans l'onglet Actions
on: [push, pull_request]        # QUAND : à chaque push et chaque PR
jobs:
  test:                         # un "job" = une suite d'étapes
    runs-on: ubuntu-latest      # OÙ : une machine Linux fournie par GitHub
    steps:
      - uses: actions/checkout@v4      # récupérer le code
      - uses: actions/setup-node@v4    # installer Node
        with: { node-version: 20 }
      - run: npm ci                    # installer les dépendances
      - run: npm test                  # lancer les tests

Questions : quel est le déclencheur ? Que se passe-t-il si npm test échoue ? Quelle étape de la boucle manque ?

• YAML : format de fichier texte basé sur l'indentation (comme Python)

TP 0 — Livrable et critères

Votre schéma du pipeline cible de TaskFlow doit faire apparaître :

Gardez ce schéma : il servira de base à docs/ARCHITECTURE.md et à votre présentation finale.

Avant de commencer : votre poste est prêt ?

• Une ligne en échec ? On la règle maintenant, avec ressources/setup-poste.md : sans clé SSH, impossible de faire un git push au TP 1
• SSH ici sert seulement à prouver à GitHub qui vous êtes, sans taper de mot de passe

Pourquoi Git ?

  rapport.docx
  rapport_v2.docx
  rapport_v2_corrigé.docx
  rapport_final.docx
  rapport_final_VRAI.docx
  rapport_final_VRAI_relu_par_Karim.docx       ← lequel est le bon ?

Git est un système de gestion de versions : il garde l'historique de chaque modification, avec qui, quand et pourquoi.

Analogie : un jeu vidéo avec des points de sauvegarde. Chaque commit est une sauvegarde à laquelle vous pouvez revenir.

Le modèle mental : 4 zones

   Répertoire de travail     Index (staging)        Dépôt local           Dépôt distant
   (vos fichiers)            (le « panier »)         (.git, historique)    (GitHub, origin)
  ┌──────────────────┐     ┌──────────────────┐    ┌──────────────────┐   ┌──────────────────┐
  │ index.html  (M)  │     │                  │    │  a1b2c3 feat: …  │   │  a1b2c3 feat: …  │
  │ style.css   (M)  │     │                  │    │  9f8e7d init     │   │  9f8e7d init     │
  └──────────────────┘     └──────────────────┘    └──────────────────┘   └──────────────────┘
          │  git add ───────────▶ │  git commit ──────────▶ │  git push ──────────▶ │
          │ ◀──────────────────── git restore               │ ◀────────────── git pull / fetch

• Index = le panier : vous choisissez ce qui part dans la prochaine sauvegarde
• Commit = la sauvegarde, identifiée par un SHA (empreinte unique, ex. a1b2c3d)

git status : où en suis-je ?

$ git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   index.html

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
        modified:   style.css

Untracked files:
        notes.txt

Ajouter, sauvegarder, envoyer

$ git add style.css
$ git commit -m "style: agrandit le titre de la page d'accueil"
[main 4c5d6e7] style: agrandit le titre de la page d'accueil
 2 files changed, 5 insertions(+), 2 deletions(-)
$ git push
To github.com:promo-dwwm/site-promo.git
   a1b2c3d..4c5d6e7  main -> main

• git add . ajoute tout : pratique, mais vérifiez avec git status avant
• git push envoie vos commits sur origin (le dépôt distant, en général GitHub)
• a1b2c3d..4c5d6e7 : la branche distante est passée de l'ancien commit au nouveau

Lire l'historique : git log --oneline --graph

$ git log --oneline --graph --all
* 4c5d6e7 (HEAD -> main, origin/main) style: agrandit le titre
* a1b2c3d feat: ajoute la page d'accueil
* 9f8e7d1 chore: initialise le projet

Astuce : créez un alias → git config --global alias.lg "log --oneline --graph --all" puis git lg

Bien écrire ses messages : Conventional Commits

Format : type: description à l'impératif, en minuscules

Pourquoi ? Un historique lisible, et des outils capables de générer le CHANGELOG automatiquement (demain).

Bons et mauvais messages

À éviter	Préférer
modif	fix: affiche un message si le titre est vide
wip	feat: ajoute le formulaire de création (sans validation)
correction bug Karim	fix: empêche la double soumission du formulaire
aaaa	chore: met à jour Vite en 5.4
plein de trucs	Plusieurs commits, un sujet par commit

Règle : votre message doit permettre à un collègue de comprendre le commit dans six mois, sans ouvrir le code.

.gitignore : ce qui ne doit jamais être versionné

# Dépendances : se réinstallent avec npm ci
node_modules/
# Fichiers générés par le build
dist/
# Secrets et configuration locale
.env
# Fichiers de l'éditeur et du système
.vscode/
.DS_Store

Vérifier qu'un fichier est bien ignoré :

$ git check-ignore -v .env
.gitignore:6:.env       .env

Un .env poussé sur GitHub = un mot de passe public. Supprimer le fichier ensuite ne suffit pas : il reste dans l'historique. Il faut changer le mot de passe.

Pourquoi des branches ?

Analogie : une branche est un brouillon parallèle. Vous essayez une idée sur une copie, sans abîmer la version officielle. Si l'idée est bonne, vous la recopiez au propre (merge). Sinon, vous jetez le brouillon.

  main (version officielle, toujours fonctionnelle)
  ──●────────●────────────────────●──────▶
             │                    ▲
             └──●────●────●───────┘  feature/formulaire (votre brouillon)

• Plusieurs personnes travaillent en même temps sans se marcher dessus
• main reste déployable à tout moment
• Chaque branche porte un seul sujet → revue plus simple

Une branche = un simple pointeur

                                  main
                                   │
                                   ▼
        ●  9f8e7d ◀──── ●  a1b2c3 ◀──── ●  4c5d6e
                                   ▲
                                   │
                                  HEAD  (« vous êtes ici »)

• Une branche n'est pas une copie des fichiers : c'est une étiquette posée sur un commit
• À chaque nouveau commit, l'étiquette de la branche courante avance toute seule
• Créer une branche coûte presque rien : un fichier de 41 octets dans .git/refs/heads/

Créer une branche et y travailler

$ git switch -c feature/formulaire
Switched to a new branch 'feature/formulaire'
$ git branch
* feature/formulaire
  main
$ git commit -am "feat: ajoute le formulaire de création"
[feature/formulaire 7a8b9c0] feat: ajoute le formulaire de création
 1 file changed, 12 insertions(+)

• switch -c = créer et se placer sur la branche (-c pour create)
• git switch main pour revenir sur main ; l'étoile * indique la branche courante
• Convention de nommage : feature/…, fix/…, docs/… + un nom court en minuscules

Merge « fast-forward » (avance rapide)

Cas : main n'a pas bougé depuis la création de la branche.

  AVANT                                    APRÈS  git merge feature/formulaire
                  main                                                   main
                   ▼                                                      ▼
  ●──────●──────●                          ●──────●──────●──────●──────●
                 \                                               feature/formulaire
                  ●──────●
                         ▲ feature/formulaire

$ git switch main
$ git merge feature/formulaire
Updating 4c5d6e7..8d9e0f1
Fast-forward
 index.html | 12 ++++++++++++

Git se contente d'avancer l'étiquette main : aucun nouveau commit.

Merge avec commit de fusion

Cas : main a avancé pendant que vous travailliez (un collègue a fusionné).

  AVANT                                    APRÈS  git merge feature/formulaire
          ●──────●  main                           ●──────●───────M  main
         /                                        /               /
  ●─────●                                  ●─────●               /
         \                                        \             /
          ●──────●  feature/formulaire             ●──────●────┘

$ git merge feature/formulaire
Merge made by the 'ort' strategy.
 index.html | 12 ++++++++++++

Git crée un commit de fusion M qui a deux parents. L'historique garde la trace de la branche.

Fast-forward ou commit de fusion ?

Ensuite, faites le ménage :

$ git branch -d feature/formulaire
Deleted branch feature/formulaire (was 8d9e0f1).

Sur GitHub, le bouton Merge pull request crée par défaut un commit de fusion.

Partager une branche sur GitHub

$ git push -u origin feature/formulaire
Enumerating objects: 5, done.
Writing objects: 100% (3/3), 412 bytes | 412.00 KiB/s, done.
remote: Create a pull request for 'feature/formulaire' on GitHub by visiting:
remote:      https://github.com/promo-dwwm/site-promo/pull/new/feature/formulaire
 * [new branch]      feature/formulaire -> feature/formulaire
branch 'feature/formulaire' set up to track 'origin/feature/formulaire'.

• -u (upstream) relie votre branche locale à la branche distante, une seule fois
• Ensuite, un simple git push suffit
• GitHub vous propose directement le lien pour ouvrir une Pull Request

Démo — Branches et merge

demos/demo-git-branches/

1. Créer deux branches depuis main, un commit sur chacune
2. Observer le graphe avec git log --oneline --graph --all
3. Merge fast-forward de la première
4. Merge avec commit de fusion de la seconde
5. Observer le commit M et ses deux parents : git show --format=raw HEAD

Suivez sur votre poste : les commandes sont dans le README.md de la démo.

GitHub Flow : simple et efficace

Pourquoi des règles communes ? Comme le code de la route : sans règles partagées, même de bons conducteurs se percutent.

  main  ──●──────────●───────────────●──────────────●──▶   toujours déployable
           \        ▲ \             ▲ \            ▲
            ●──●──●┘   ●──●────────┘   ●──●──●────┘
            feature/a  fix/b           feature/c
             (PR #1)   (PR #2)          (PR #3)

1. On crée une branche depuis main
2. On commite, on pousse, on ouvre une Pull Request
3. Revue + tests automatiques verts → merge dans main
4. main est déployée (souvent automatiquement)

Git Flow (simplifié)

Pour les projets avec des versions planifiées (application mobile, logiciel livré au client).

  main     ──●───────────────────────────●────────────●──▶   versions livrées (v1.0, v1.1)
              \                         ▲ \          ▲
  hotfix/*     \                        │  ●────────┤        correctif urgent
                \                       │            ▼
  develop        ●──────●─────────●─────●────────────●──▶   intégration
                  \    ▲ \       ▲
  feature/*        ●──●┘  ●──●──●┘                            fonctionnalités

• main : uniquement les versions livrées · develop : le travail en cours
• feature/* partent de develop · hotfix/* partent de main et reviennent dans les deux

Lequel choisir ?

	GitHub Flow	Git Flow simplifié
Branches longues	main seule	main + develop
Idéal pour	Applications web déployées souvent	Versions planifiées, plusieurs versions maintenues
Complexité	Faible	Moyenne
Compatible déploiement continu	Oui	Plus difficile

Cette semaine : GitHub Flow. main toujours déployable, une branche par sujet, tout passe par une Pull Request. C'est le choix le plus courant pour une application web.

La Pull Request (PR)

Une PR (Pull Request, « demande de fusion ») = « voici mes changements, pouvez-vous les relire avant de les fusionner dans main ? »

  push de la branche ──▶ ouverture de la PR ──▶ tests automatiques (CI) ──▶ revue d'un pair
                                                        │                        │
                                                        ▼                        ▼
                                               corriger, re-pousser     commentaires
                                                        │                        │
                                                        └──────────┬─────────────┘
                                                                   ▼
                                                   approuvée + verte ──▶ Merge

Une bonne PR : un titre clair, une description (quoi et pourquoi), une capture d'écran si visuel, petite (< 300 lignes).

La revue de code : quoi regarder ?

La revue n'est pas un examen : c'est une conversation pour améliorer le code et partager la connaissance.

Commenter avec bienveillance

À éviter	Préférer
« C'est faux. »	« Je crois que si la liste est vide, on a une erreur ici. Qu'en penses-tu ? »
« Pourquoi tu as fait ça ?? »	« Peux-tu m'expliquer ce choix ? Je ne suis pas sûr de comprendre. »
« Code illisible. »	« Suggestion : découper cette fonction en deux pour la rendre plus lisible. »
Ne rien dire de positif	« Bien vu pour la gestion d'erreur ! »

• Parlez du code, pas de la personne
• Distinguez bloquant et suggestion (préfixe nit: = détail facultatif)
• Sur GitHub : Comment, Approve ou Request changes

Protéger la branche main

Sans protection, n'importe qui peut pousser directement sur main… et casser la prod.

GitHub → Settings → Branches → Add branch protection rule (main) :

• ☑ Require a pull request before merging (+ 1 approbation)
• ☑ Require status checks to pass (dès que la CI existera, jour 3)

$ git push origin main
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: - Changes must be made through a pull request.
 ! [remote rejected] main -> main (protected branch hook declined)

Avec un compte GitHub gratuit, la protection de branche n'est disponible que sur les dépôts publics.

Pourquoi un conflit ?

Deux personnes modifient la même ligne du même fichier, sur deux branches différentes. Git ne sait pas laquelle garder : il vous demande de choisir.

                        index.html, ligne 12
  main          ──●──── <li>Alice</li>          ──●   (déjà fusionné)
                   \
  feature/bob       ●── <li>Bob</li>              ──▶ merge ?  même ligne !

• Ce n'est pas une erreur ni un bug : c'est Git qui refuse de deviner à votre place
• Deux modifications sur des lignes différentes → Git fusionne tout seul
• Plus une branche vit longtemps, plus le risque de conflit augmente

Le message de Git

$ git merge main
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
$ git status
On branch feature/bob
You have unmerged paths.
  (fix conflicts and run "git commit")
Unmerged paths:
        both modified:   index.html

Pas de panique : rien n'est perdu. Le fichier contient les deux versions, encadrées par des marqueurs.

Lire les marqueurs de conflit

<ul>
<<<<<<< HEAD
  <li>Bob</li>
=======
  <li>Alice</li>
>>>>>>> main
</ul>

Résoudre dans VS Code

VS Code affiche des boutons au-dessus du conflit :

Ou éditez à la main. Résultat attendu, sans aucun marqueur :

<ul>
  <li>Alice</li>
  <li>Bob</li>
</ul>

Terminer (ou abandonner) la fusion

$ git add index.html
$ git commit -m "merge: intègre main dans feature/bob"
[feature/bob 2e3f4a5] merge: intègre main dans feature/bob
$ git push

Vous êtes perdu ? Revenez à l'état d'avant la fusion :

$ git merge --abort

Éviter les conflits :

• Branches courtes (quelques heures à 2 jours), PR petites
• Récupérer main souvent dans sa branche
• Se parler : « je modifie le header cet après-midi »

Démo — Un conflit, de A à Z

demos/demo-git-conflit/

1. Deux branches modifient la même ligne de index.html
2. La première est fusionnée sans souci
3. La seconde déclenche un conflit : lecture du message et des marqueurs
4. Résolution dans VS Code (Accept Both), git add, git commit
5. Vérification : git log --oneline --graph montre le commit de fusion

À vous : exercices/jour1/ contient un kata conflit à faire seul.

TP 1 — Déroulé (1h aujourd'hui, suite demain)

Par groupes de 3-4 : un repo partagé, le site « Promo DWWM », une carte HTML par apprenant.

TP 1 — Le conflit volontaire

Tout le monde ajoute sa ligne dans la même liste de index.html :

<ul class="promo">
  <li><a href="cartes/alice.html">Alice</a></li>
  <!-- chacun ajoute sa ligne ICI -->
</ul>

• La première PR passe ; les suivantes affichent This branch has conflicts
• Résolvez en local : git switch main && git pull, git switch feature/carte-<prenom>, git merge main, résoudre, git push

Critères de réussite : chaque membre a une PR revue et fusionnée, au moins un conflit résolu, aucun marqueur <<<<<<< dans main.

Si ça ne marche pas : git status d'abord, puis appelez le formateur. Exercices en solo : exercices/jour1/

Récap de la journée

Quiz — 5 questions

1. Citez les 5 piliers de CALMS.
2. Quelle est la différence entre livraison continue et déploiement continu ?
3. Que fait git add exactement ?
4. Dans quel cas un merge est-il fast-forward ?
5. Dans un conflit, que représente la partie entre <<<<<<< HEAD et ======= ?

Réfléchissez 2 minutes, notez vos réponses, puis passez à la slide suivante.

Quiz — Réponses

1. Culture, Automatisation, Lean, Mesure, partage (Sharing)
2. Livraison continue : prêt à déployer, un humain déclenche. Déploiement continu : en prod sans humain
3. Il place les modifications dans l'index (le « panier ») pour le prochain commit
4. Quand la branche cible (main) n'a pas avancé depuis la création de la branche : Git avance juste l'étiquette
5. Votre version, celle de la branche courante (HEAD)

Glossaire du jour (1/2)

Glossaire du jour (2/2)