Aller au contenu
PROJET WEB DYNAMIQUE

Collaboration avec Git

Workflows de collaboration avancés

Slides du chapitre

Modèles de branchement : Comprendre les stratégies

La collaboration sur un projet Git nécessite une approche structurée de la gestion des branches. Deux modèles principaux émergent : Git Flow et GitHub Flow, chacun avec ses propres forces et cas d'utilisation.

Git Flow : Un modèle complet pour les projets complexes

Git Flow est un modèle de branchement robuste, particulièrement adapté aux projets avec des cycles de release bien définis.

Structure typique des branches :

  • main (ou master) : branche de production
  • develop : branche d'intégration pour le développement
  • feature/* : branches pour les nouvelles fonctionnalités
  • release/* : branches de préparation de release
  • hotfix/* : branches pour les corrections critiques

Exemple de workflow Git Flow :

  1. Créer une branche feature depuis develop
  2. Développer la fonctionnalité
  3. Merger la feature dans develop
  4. Créer une branche release pour les tests
  5. Merger release dans main et develop
  6. Appliquer des tags de version

GitHub Flow : Approche simplifiée et continue

GitHub Flow privilégie la simplicité et le déploiement continu.

Structure des branches :

  • main : branche de production toujours déployable
  • feature/* : branches pour chaque développement

Processus :

  1. Créer une branche à partir de main
  2. Développer et commiter
  3. Ouvrir une Pull Request
  4. Revue et discussion
  5. Déployer depuis la branche
  6. Merger dans main

Comparaison des approches

Critère Git Flow GitHub Flow
Complexité Élevée Faible
Releases planifiées Oui Non
Déploiement continu Difficile Facile
Adapté à Logiciels avec cycles Développement web, startups

Choix du workflow : Considérations pratiques

Le choix entre Git Flow et GitHub Flow dépend de plusieurs facteurs :

  • Nature du projet
  • Fréquence des releases
  • Taille de l'équipe
  • Processus de déploiement

Conseils de sélection :

  • Projets avec versions stables → Git Flow
  • Développement web, MVP → GitHub Flow
  • Projets open-source → Généralement GitHub Flow

Pull Request : Concept et Définition

Qu'est-ce qu'une Pull Request ?

Une Pull Request (PR) est bien plus qu'un simple mécanisme technique de fusion de code. C'est un outil de communication et de collaboration qui permet aux développeurs de proposer des modifications à un projet partagé. Imaginez-la comme une invitation à discuter et à examiner ensemble une série de changements avant de les intégrer définitivement au projet.

Dans le workflow GitHub, une Pull Request signale à l'équipe : "J'ai travaillé sur ces modifications. Pouvez-vous les examiner et me donner votre avis avant que je ne les incorpore au projet principal ?" C'est un moment crucial d'échange et de validation collective.

Processus de base d'une Pull Request

La création d'une Pull Request suit généralement ces étapes :

  1. Créer une nouvelle branche

    • Partez toujours de la branche principale (généralement main ou master)
    • Donnez un nom clair et descriptif à votre branche (ex: feature/login-authentication)

  2. Développer votre fonctionnalité ou correction

    • Travaillez sur votre branche
    • Effectuez des commits réguliers et significatifs
    • Assurez-vous que votre code fonctionne localement

  3. Pousser votre branche sur GitHub

    git push -u origin feature/login-authentication

  4. Ouvrir la Pull Request

    • Sur GitHub, sélectionnez votre branche
    • Cliquez sur "New Pull Request"
    • Décrivez vos modifications
    • Indiquez le contexte et les raisons de ces changements

  5. Revue et discussion

    • Les membres de l'équipe examinent votre code
    • Ils peuvent commenter, suggérer des modifications
    • Vous pouvez répondre, clarifier, modifier votre code

  6. Finalisation

    • Si tout est validé : merger la branche
    • Si des modifications sont nécessaires : les apporter et mettre à jour la PR

Code Review : Concepts et Pratiques

Définition de la Code Review

La code review est un processus collaboratif essentiel dans le développement logiciel moderne. Il s'agit d'un examen systématique du code écrit par un développeur, effectué par ses pairs ou des membres plus expérimentés de l'équipe.

Les objectifs principaux sont multiples :

  • Détecter et corriger les bugs potentiels
  • Partager les connaissances au sein de l'équipe
  • Maintenir une haute qualité de code
  • Garantir la cohérence technique du projet
  • Faciliter l'apprentissage collectif

Risques d'une absence de Code Review

Sans revue de code, une équipe s'expose à plusieurs risques significatifs :

  • Bugs non détectés qui peuvent s'accumuler
  • Code peu lisible et difficilement maintenable
  • Isolation des connaissances techniques
  • Accumulation rapide de dette technique
  • Failles de sécurité potentiellement non identifiées
  • Divergence des pratiques de codage au sein de l'équipe

Bonnes Pratiques de Code Review

Qui peut faire une revue ?

Une revue de code efficace implique généralement :

  • Les développeurs expérimentés du projet
  • Les membres directs de l'équipe
  • Le lead technique ou l'architecte
  • Les contributeurs réguliers ayant une bonne compréhension du projet

L'idéal est de varier les reviewers pour bénéficier de perspectives différentes.

Comment bien faire une revue

Critères d'évaluation :

  • Lisibilité et compréhension du code
  • Respect des conventions du projet
  • Logique et efficacité de l'implémentation
  • Performance et complexité algorithmique
  • Gestion appropriée des erreurs
  • Qualité et pertinence des commentaires
  • Couverture et qualité des tests

Approche constructive :

  • Commenter le code, jamais la personne
  • Être précis et bienveillant
  • Proposer des alternatives concrètes
  • Expliquer le raisonnement derrière chaque suggestion

Exemple de commentaire constructif :

Cette méthode pourrait bénéficier d'une refactorisation. 
Je suggère d'extraire la logique de validation dans une méthode dédiée, 
ce qui améliorerait la lisibilité et permettrait de réutiliser ce comportement.

Intégration Continue avec Laravel et GitHub Actions

Définition

L'intégration continue est une pratique de développement qui consiste à :

  • Automatiser la compilation et les tests du code
  • Détecter rapidement les problèmes
  • Garantir la qualité à chaque modification

Configuration pour un projet Laravel

Voici un exemple de workflow GitHub Actions adapté à Laravel :

name: Laravel Tests
on: [push, pull_request]
jobs:
  tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
      
      - name: Install Dependencies
        run: composer install -q --no-ansi --no-interaction --no-scripts --no-progress --prefer-dist
      
      - name: Generate key
        run: php artisan key:generate
      
      - name: Run Pest
        run: ./vendor/bin/pest
      
      - name: Run PHPStan
        run: ./vendor/bin/phpstan analyse

Installation des outils

# Installation de Pest
composer require pestphp/pest --dev --with-all-dependencies

# Installation de PHPStan
composer require --dev phpstan/phpstan

Exemple de configuration PHPStan (phpstan.neon) :

parameters:
    level: 6
    paths:
        - app
        - tests

Cette configuration garantira que chaque modification passe les tests et respecte les standards de qualité de code.

Techniques de Travail Collaboratif : Résolution des Conflits

Comprendre les Conflits de Fusion

Qu'est-ce qu'un Conflit de Fusion ?

Un conflit de fusion survient lorsque deux développeurs modifient les mêmes parties d'un fichier dans différentes branches. Git, malgré sa sophistication, ne peut pas toujours décider automatiquement quelle version conserver.

Imaginez deux développeurs travaillant simultanément sur le même fichier PHP. L'un modifie une méthode de validation, l'autre change la logique de cette même méthode. Lorsqu'ils tentent de fusionner leurs branches, Git signale un conflit, nécessitant une intervention manuelle.

Types de Conflits

Il existe principalement deux catégories de conflits :

  1. Conflits de Contenu : Ils surviennent quand les mêmes lignes de code sont modifiées différemment. Par exemple :

    // Version sur ma branche
public function validate($data) {
    return $data['email'] !== '';
}

// Version sur la branche principale
public function validate($data) {
    return filter_var($data['email'], FILTER_VALIDATE_EMAIL);
}

  2. Conflits Structurels : Ils concernent des changements plus globaux comme la réorganisation du code, le déplacement de méthodes ou la modification de l'architecture.

Prévention des Conflits

La meilleure stratégie pour gérer les conflits est de les prévenir :

Communication d'Équipe

  • Informez vos collègues de vos développements en cours
  • Utilisez les issues GitHub pour planifier le travail
  • Synchronisez régulièrement votre branche avec la branche principale

Pratiques de Développement

  • Créez des branches courtes et ciblées
  • Mergez fréquemment
  • Évitez de travailler trop longtemps sur des branches isolées

Processus de Résolution de Conflits

Identification des Conflits

Première étape : identifier les fichiers problématiques

git status

Cette commande affichera les fichiers en conflit.

Comprendre la Structure d'un Conflit

Git marque les zones conflictuelles avec des balises spécifiques :

<<<<<<< HEAD
// Votre version actuelle
public function validate($data) {
    return $data['email'] !== '';
}
=======
// Version en cours de fusion
public function validate($data) {
    return filter_var($data['email'], FILTER_VALIDATE_EMAIL);
}
>>>>>>> nouvelle_branche

Résolution Manuelle

Étapes de résolution :

  1. Ouvrez le fichier en conflit
  2. Éditez manuellement pour garder la meilleure implémentation
  3. Supprimez les balises de Git
  4. Choisissez l'implémentation la plus appropriée

Exemple de résolution :

public function validate($data) {
    return !empty($data['email']) && 
           filter_var($data['email'], FILTER_VALIDATE_EMAIL);
}

Validation de la Résolution

Après avoir résolu manuellement :

git add fichier_resolu
git commit -m "Résolution du conflit de fusion"

Outils de Résolution dans Visual Studio Code

VSCode offre des outils visuels puissants pour résoudre les conflits :

  • Boutons interactifs de résolution
  • Vue comparative côte à côte
  • Sélection facilitée des modifications

Stratégies de Choix

Lors de la résolution, considérez :

  • La logique métier
  • La performance du code
  • La cohérence avec l'architecture existante
  • L'intention originale du développement

Conseils Éthiques et Pratiques

Lors d'un Conflit

  • Communiquez toujours avec le développeur concerné
  • Cherchez à comprendre le contexte des modifications
  • Privilégiez la solution technique la plus propre
  • Restez professionnel et constructif

Cette approche transforme un conflit potentiellement frustrant en une opportunité de collaboration et d'amélioration du code.

GitHub Projects : Outil de Suivi et de Planification

Présentation de GitHub Projects

GitHub Projects est un outil intégré de gestion de projet directement dans l'écosystème GitHub. Il permet aux équipes de développement de suivre, organiser et planifier leur travail de manière visuelle et collaborative.

Les projets GitHub peuvent prendre plusieurs formes :

  • Tableau Kanban : colonnes représentant les étapes de progression
  • Liste : vue linéaire des tâches
  • Tableau de bord : vue personnalisée selon les besoins de l'équipe

Création d'un Projet

La création d'un projet suit quelques étapes simples :

  1. Dans votre dépôt GitHub, cliquez sur "Projects"
  2. Choisissez "New Project"
  3. Sélectionnez un modèle de base ou commencez à zéro

Configuration typique des colonnes :

  • "À faire" : Tâches à planifier
  • "En cours" : Développements actifs
  • "Terminé" : Tâches réalisées

Exemple visuel des colonnes :

Modification d’une tâche

Issues GitHub : Gestion des Tâches et Bugs

Qu'est-ce qu'une Issue ?

Une issue GitHub est un outil de communication et de suivi dans un projet. Elle permet de :

  • Signaler un bug
  • Proposer une amélioration
  • Suivre une tâche à réaliser
  • Discuter d'un point technique

Types d'issues courants :

  • Bug : Problème technique à résoudre
  • Amélioration : Nouvelle fonctionnalité
  • Tâche : Travail à accomplir
  • Documentation : Mise à jour de la documentation

Création et Gestion des Issues

Informations importantes lors de la création :

  • Titre clair et concis
  • Description détaillée
  • Contexte du problème
  • Étapes de reproduction (pour les bugs)
  • Résultat attendu

Exemple d'une bonne issue :

Titre: Correction de la validation d'email dans le formulaire d'inscription

Description:
Actuellement, le formulaire accepte des emails invalides.

Étapes de reproduction :
1. Aller sur la page d'inscription
2. Entrer un email sans format valide
3. Soumettre le formulaire

Résultat attendu :
Le formulaire doit rejeter les emails mal formatés

Gestion de l'issue :

  • Assignation à un développeur
  • Définition d'une priorité
  • Suivi de son avancement

Étiquettes (Labels)

Rôle des Labels

Les labels sont des étiquettes colorées qui permettent de :

  • Catégoriser rapidement une issue
  • Communiquer visuellement son statut
  • Organiser les tâches

Types de Labels Courants

Labels de priorité :

  • priorité: haute
  • priorité: moyenne
  • priorité: basse

Labels de type :

  • bug
  • amélioration
  • documentation
  • question

Labels de statut :

  • en cours
  • bloqué
  • nécessite des informations

Création et Utilisation des Labels

Bonnes pratiques :

  • Utilisez des couleurs distinctives
  • Créez des labels personnalisés adaptés à votre projet
  • Soyez cohérent dans leur utilisation
  • Limitez le nombre de labels pour éviter la confusion

Exemple de configuration de labels :

🔴 bug (couleur rouge)
🟡 amélioration (couleur jaune)
🟢 documentation (couleur verte)

Exercice pratique : gestion collaborative de projets avec Git et Laravel

Introduction à l'exercice

Dans cet exercice, vous travaillerez par groupes de deux pour développer une application Laravel utilisant Breeze. Vous apprendrez à gérer des branches Git, à écrire des tests HTTP avec Pest, à créer et résoudre des conflits Git, et à configurer l'intégration continue avec GitHub Actions.

Mise en place du projet

  1. Initialisation du dépôt Git :
    • Un étudiant crée un nouveau projet Laravel
    • Ensuite, il le push sur GitHub
    • L’autre étudiant clone le dépôt localement.

Création des fonctionnalités

  1. Création de branches :

    • Chaque étudiant crée une branche à partir de main, par exemple, feature/about-page et feature/contact-page.

  2. Développement de nouvelles pages et contrôleurs :

    • Étudiant A : Crée une page "About" avec un contrôleur PageController.

      // web.php
Route::get('/about', [PageController::class, 'showAbout']);

// PageController.php
public function showAbout()
{
    return view('about');
}

    • Étudiant B : Crée une page "Contact" avec le même contrôleur PageController.

      // web.php
Route::get('/contact', [PageController::class, 'showContact']);

// PageController.php
public function showContact()
{
    return view('contact');
}

Simulation et résolution de conflits

  1. Création de Pull Requests :

    • Chaque étudiant soumet une Pull Request de sa branche vers main.

  2. Scénarios de conflits :

    • Les deux étudiants ont modifié les fichiers web.php et PageController.php, ce qui crée des conflits lors du merge des Pull Requests.

  3. Processus de résolution de conflits :

    • Ouvrez les fichiers en conflit.
    • Discutez des modifications à conserver et résolvez les conflits en intégrant les routes et méthodes de chaque branche.
    • Validez les modifications et complétez le merge.

Création d’une Pull Request

Créer la première Pull Request

Validez les changements et lancez le Merge

Créez la 2e Pull Request et essayez de Merge

Écriture des tests avec Pest

  1. Installez Breeze avec l’option Pest pour les tests.

  2. Création de tests HTTP :

    • Test de la page About :

      test('la page About se charge correctement', function () {
    $response = $this->get('/about');
    $response->assertStatus(200);
    $response->assertSee('À propos');
});

    • Test de la page Contact :

      test('la page Contact se charge correctement', function () {
    $response = $this->get('/contact');
    $response->assertStatus(200);
    $response->assertSee('Contactez-nous');
});

  3. Lancez les tests avec la commande php artisan test et corrigez votre code si besoin.

Intégration continue avec GitHub Actions

  1. Configuration du workflow :

    • Créez un fichier .github/workflows/laravel.yml avec le contenu suivant :

      name: Run Laravel Tests

on: [push, pull_request]

jobs:
  tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: "8.3"

      - name: Install Dependencies
        run: composer install -q --no-ansi --no-interaction --no-scripts --no-progress --prefer-dist

      - name: Setup Node
        uses: actions/setup-node@v2
        with:
          node-version: "22"

      - name: Install NPM Dependencies
        run: npm install

      - name: Build Assets
        run: npm run build

      - name: Copy .env
        run: php -r "file_exists('.env') || copy('.env.example', '.env');"
      - name: Install Dependencies
        run: composer install -q --no-ansi --no-interaction --no-scripts --no-progress --prefer-dist
      - name: Generate key
        run: php artisan key:generate
      - name: Directory Permissions
        run: chmod -R 777 storage bootstrap/cache
      - name: Create Database
        run: |
          mkdir -p database
          touch database/database.sqlite
          php artisan migrate --force
      - name: Execute tests (Unit and Feature tests) via PHPUnit/Pest
        env:
          DB_CONNECTION: sqlite
          DB_DATABASE: database/database.sqlite
        run: php artisan test

  2. Fonctionnement du workflow :

    • Le workflow s'exécute à chaque push ou pull request, vérifiant que les tests passent correctement.

  3. Pushez votre code et voyez si les tests passent.