La magie des Pull Requests

1. Du merge à la proposition : pourquoi les Pull Requests ?

Dans la leçon précédente on a appris à merger des branches sur sa machine locale. Ça marche bien quand on bosse seul. Mais si toute une équipe travaille sur le projet ? Si chacun merge directement ses changements dans la branche principale main, rapidement c'est le chaos : quelqu'un peut ajouter par erreur du code buggy, casser la build ou supprimer une partie importante du travail d'un collègue.

Pour éviter ça, en développement d'équipe on utilise une autre approche. Au lieu de merger tout de suite, on crée une proposition de fusion. Cette proposition s'appelle un Pull Request (PR) ou, sur certaines plateformes, Merge Request.

Pull Request — c'est une demande officielle : "S'il te plaît, pull mes changements depuis ma branche et merge-les dans la branche principale". Mais ce n'est pas juste une demande, c'est tout un espace pour discuter, vérifier et améliorer le code avant qu'il n'arrive dans main.

2. Workflow standard avec un Pull Request

Décomposons étape par étape le workflow typique pour créer une nouvelle fonctionnalité.

Avant de créer une branche pour une nouvelle tâche, assurez-vous d'avoir pushé tous vos commits terminés (push) et d'avoir mis à jour (Update Project) la branche principale main.

Sinon tous vos commits locaux "oubliés" depuis main risquent de se retrouver dans le nouveau Pull Request et de créer de la confusion pour vos collègues.

Étape 1. Créez une branche pour la nouvelle tâche.

Comme d'habitude, tout nouveau travail commence par la création d'une branche séparée. Supposons qu'on veuille ajouter un fichier de règles pour les contributeurs. Créons la branche feature/add-contribution-guide.

Étape 2. Faites des changements et push votre branche sur GitHub.

Dans la nouvelle branche créez le fichier CONTRIBUTING.md (après création cliquez sur Add) et écrivez-y un message pour les autres devs. Puis faites un Commit and Push avec un message clair, par exemple : docs: Add contribution guide.

C'est une étape clé ! Le Pull Request se crée à partir d'une branche qui existe déjà sur le remote. Donc, avant de créer le PR, il faut push votre nouvelle branche sur GitHub.

3. Créer un Pull Request depuis IntelliJ IDEA

Maintenant que votre branche est sur GitHub, vous pouvez créer le Pull Request.

Étape 1. Ouvrez l'onglet Pull Requests.

Sur la gauche de l'IDE il y a l'onglet Pull Requests. Ouvrez-le et cliquez sur l'icône + pour créer un nouveau PR.

Étape 2. Remplissez les infos du PR.

L'IDE ouvrira automatiquement une interface pratique pour créer le Pull Request. À vous de la remplir correctement. Voyons les champs principaux :

1. Titre : l'IDE met souvent le nom de la branche, mais c'est une mauvaise pratique. Le titre doit être court, clair et refléter l'essentiel des changements, comme un bon message de commit.
2. Description : ici vous expliquez quoi et pourquoi vous avez fait ces changements.
3. Reviewers : ici vous choisissez un ou plusieurs collègues qui doivent relire votre code. Dans un projet d'apprentissage on peut sauter cette étape, mais dans la vraie vie elle est obligatoire.
4. Assignees : en général vous vous indiquez vous-même. Ça signifie que vous êtes l'auteur et le principal responsable de la tâche et des corrections après revue.

Quand tous les champs sont remplis, cliquez sans hésiter sur Create Pull Request.

4. Code-review : vérification et discussion

Après la création du PR commence l'étape la plus importante — le code-review (code review). Vos collègues peuvent ouvrir le PR, regarder tous les changements et laisser des commentaires.

Vous pouvez voir toutes les discussions directement dans l'IDE, dans l'onglet Pull Requests. Si quelqu'un laisse un commentaire, vous recevrez une notification.

Que faire si on vous demande des modifications ?

Très simple ! Pas besoin de créer un nouveau PR. Faites les modifications nécessaires dans la même branche, faites un nouveau commit et push. Le Pull Request sur GitHub se mettra à jour automatiquement en ajoutant vos nouveaux commits.

5. Fin de travail : merge et suppression de la branche

Quand toutes les remarques sont corrigées et que l'équipe approuve vos changements, on peut merger le Pull Request. En général c'est fait par un développeur senior ou par vous si vous avez les droits.

Étape 1. Merge

Le merge se fait le plus souvent sur le site GitHub. Sous votre PR il y a un gros bouton vert Merge pull request. Après l'avoir cliqué votre code devient partie de la branche principale main.

Étape 2. Suppression de la branche.

Après le merge votre branche `feature` n'est plus utile et il vaut mieux la supprimer pour ne pas polluer le repo. GitHub proposera de le faire en affichant le bouton Delete branch.

N'oubliez pas aussi de supprimer la copie locale de la branche dans votre IDE pour garder l'ordre. Ça se fait depuis le même menu de gestion des branches.

6. Trois règles pour les commits

Un bon commit, c'est pas seulement un message correct, c'est aussi un contenu pertinent. Pour que l'historique soit propre, utile et professionnel, suivez trois règles simples.

Règle 1 : écrivez des messages clairs selon une norme

Vos commits sont des messages que vous envoyez à votre équipe et à vous-même dans le futur. Une histoire pleine de messages "fix" ou "update" ne sert à rien. La norme la plus populaire s'appelle Conventional Commits. Elle propose cette structure :

<type>: <description courte>

Type — un mot court décrivant la catégorie du changement :

• feat: (feature) — pour une nouvelle fonctionnalité.
• fix: — pour une correction de bug.
• docs: — pour des changements dans la documentation.
• style: — pour des corrections de formatage sans impact sur la logique.
• refactor: — pour des changements dans le code qui n'ajoutent pas de nouvelle fonctionnalité et ne corrigent pas de bug.
• test: — pour l'ajout ou la correction de tests.
• chore: — pour des tâches routinières non liées au code (mise à jour de dépendances, configuration de build).

Exemples :

• Mauvais : fixed bug
• Bon : fix: Correct user login validation

• Mauvais : readme
• Bon : docs: Update installation instructions

Règle 2 : un commit = un changement logique (Atomicité)

Ne mettez pas la correction d'un bug, l'ajout d'une fonctionnalité et le refactor d'un ancien code dans le même commit. Un tel commit est difficile à reviewer, et presque impossible à revert proprement si quelque chose casse.

Chaque commit doit résoudre une seule tâche spécifique.

• Mauvais : un commit avec le message "Update user page" qui ajoute le champ avatar, corrige la validation du nom et change la couleur des boutons.
• Bon : trois commits séparés :
  1. feat: Add avatar upload to user profile
  2. fix: Correct username validation logic
  3. style: Update button colors on user page

Les petits commits focalisés sont bien plus faciles à comprendre et à gérer.

Règle 3 : le commit ne doit pas casser le projet

Chaque commit sur la branche principale doit laisser le projet dans un état fonctionnel. Avant de le créer vous devez au minimum vérifier que le code compile. Mais comment être sûr que vous n'avez pas cassé autre chose ? Se fier uniquement aux vérifs manuelles, c'est risqué.

Ici l'automatisation intervient. Dans ce cours on ne va pas configurer des pipelines, mais vous devez savoir comment ça marche dans les vrais projets. Les équipes modernes utilisent des systèmes d'intégration continue (Continuous Integration, CI) comme GitHub Actions.

Comment ça marche ?

Vous écrivez du code et des tests. Ensuite vous configurez un workflow directement sur GitHub. Dès que vous push dans votre Pull Request, la magie opère :

1. GitHub Actions détecte l'événement et lance votre workflow.
2. Il "build" automatiquement le projet et lance tous les tests.
3. Si tous les tests passent, une case verte apparaît à côté de votre commit sur GitHub. C'est un signal pour toute l'équipe que vos changements sont sûrs.
4. Si au moins un test échoue, vous verrez un croix rouge. Merge d'un tel PR vers la branche principale est strictement interdit.

            graph LR
            subgraph GitHub
            A[Développeur] -- "push" --> B(Répository)
            B -- "Événement: push" --> C{GitHub Actions}
            end

            subgraph Workflow
            C -- "Lancement" --> D[Run_tests]
            D --> E[Succès]
            D --> F[Échec]
            end

            subgraph Notifications
            F --> G((Email))
            G --> H[Développeur]
            G --> I[Équipe]
            end

            style F fill:#f99,stroke:#333,stroke-width:2px
            style G fill:#ccf,stroke:#333,stroke-width:2px
        

On peut configurer des notifications. Si les tests échouent, GitHub Actions peut envoyer un mail à vous ou à toute l'équipe. Cette approche installe une culture où les tests ne sont pas une formalité, mais une part intégrante du développement, et chacun est responsable de la qualité de son code.