La magie des Pull Requests

1. De la fusion à la proposition : pourquoi les Pull Requests sont-elles nécessaires ?

Dans la leçon précédente, nous avons appris à fusionner (merge) des branches sur votre ordinateur local. Cela fonctionne très bien lorsque vous travaillez seul. Mais que se passe-t-il si une équipe entière travaille sur le projet ? Si chacun fusionne ses changements directement dans la branche principale main, le chaos va rapidement s’installer : quelqu’un peut par inadvertance ajouter du code avec des erreurs, casser la build ou supprimer une partie importante du travail d’un collègue.

Pour éviter cela, une autre approche est adoptée dans le développement en équipe. Au lieu de fusionner immédiatement les modifications, vous créez une proposition de fusion. Cette proposition s’appelle une Pull Request (abrégée PR) ou, sur certaines plateformes, une Merge Request.

Pull Request — c’est une demande formelle : « Veuillez récupérer (pull) mes modifications depuis ma branche et les intégrer (merge) dans la branche principale ». Mais ce n’est pas seulement une demande, c’est aussi un espace complet de discussion, de vérification et d’amélioration du code avant qu’il n’arrive dans main.

2. Déroulement standard avec une Pull Request

Passons pas à pas en revue à quoi ressemble le flux de travail typique lors de la création d’une nouvelle fonctionnalité.

Avant de créer une branche pour une nouvelle tâche, assurez-vous d’avoir envoyé 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 se retrouveront par erreur dans la nouvelle Pull Request, ce qui créera de la confusion pour vos collègues.

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

Comme auparavant, tout nouveau travail commence par la création d’une branche séparée. Supposons que nous souhaitions ajouter à notre projet un fichier de règles pour les contributeurs. Créons la branche feature/add-contribution-guide.

Étape 2. Apportez des modifications et poussez votre branche sur GitHub.

Dans la nouvelle branche, créez le fichier CONTRIBUTING.md (après la création, cliquez sur Add) et écrivez-y un message destiné aux autres développeurs. Ensuite, faites un Commit and Push avec un message explicite, par exemple : docs: Add contribution guide.

C’est une étape clé ! Une Pull Request est créée à partir d’une branche qui existe déjà sur le serveur distant. Par conséquent, avant de créer une PR, vous devez pousser (push) votre nouvelle branche sur GitHub.

3. Créer une Pull Request depuis IntelliJ IDEA

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

Étape 1. Ouvrez l’onglet Pull Requests.

Sur la gauche de l’IDE se trouve l’onglet Pull Requests. Ouvrez-le et cliquez sur l’icône + pour créer une nouvelle PR.

Étape 2. Renseignez les informations de la PR.

L’IDE ouvrira automatiquement une interface pratique pour créer une Pull Request. Votre tâche — la remplir correctement. Passons en revue les champs principaux :

1. Titre : l’IDE insère souvent ici le nom de la branche, mais c’est une mauvaise pratique. Le titre doit être court, clair et refléter l’essence des changements, comme un bon message de commit.
2. Description : ici, vous expliquez ce que vous avez fait et pourquoi.
3. Reviewers : ici, vous choisissez un ou plusieurs collègues qui doivent examiner votre code. Dans un projet d’apprentissage, nous pouvons ignorer cette étape, mais dans le travail réel elle est indispensable.
4. Assignees : généralement, vous vous indiquez vous-même. Cela signifie que vous êtes l’auteur et le principal responsable de cette tâche et des corrections après la revue.

Une fois tous les champs remplis, cliquez sans hésiter sur Create Pull Request.

4. Code review : vérification et discussion

Après la création de la PR, commence l’étape la plus importante — le code review. Vos collègues peuvent ouvrir votre PR, voir 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 l’on vous demande d’apporter des modifications ?

Très simple ! Inutile de créer une nouvelle PR. Apportez simplement les modifications nécessaires dans la même branche, faites un nouveau commit et poussez-le (push). La Pull Request sur GitHub se mettra à jour automatiquement en ajoutant vos nouveaux commits.

5. Finalisation : fusion et suppression de la branche

Lorsque toutes les remarques sont corrigées et que l’équipe approuve vos changements, la Pull Request peut être fusionnée. En général, cela est effectué par un développeur senior, ou par vous-même si vous en avez les droits.

Étape 1. Merge

La fusion a le plus souvent lieu sur le site de GitHub. Sous votre PR, un grand bouton vert Merge pull request apparaîtra. Après avoir cliqué dessus, votre code deviendra partie intégrante de la branche principale main.

Étape 2. Suppression de la branche.

Après la fusion, votre branche `feature` n’est plus nécessaire, et il est conseillé de la supprimer pour ne pas encombrer le dépôt. GitHub vous le proposera automatiquement via le bouton Delete branch.

N’oubliez pas non plus de supprimer la copie locale de la branche dans votre IDE, afin de maintenir l’ordre. Vous pouvez le faire via le même menu de gestion des branches.

6. Trois règles du commit

Un bon commit — ce n’est pas seulement un message correct, mais aussi un contenu correct. Pour que votre historique des changements soit clair, utile et professionnel, suivez trois règles simples.

Règle 1 : rédigez des messages clairs selon le standard

Vos commits sont des messages que vous envoyez à votre équipe et à vous-même dans le futur. Un historique rempli de messages « fix » ou « update » est totalement inutile. Le standard le plus populaire est appelé Conventional Commits. Il propose la structure suivante :

<type>: <description courte>

Type — c’est un mot court décrivant la catégorie de vos changements :

• feat : (feature) — pour une nouvelle fonctionnalité.
• fix : — pour une correction de bug.
• docs : — pour les changements de documentation.
• style : — pour des ajustements de formatage qui n’affectent pas la logique du code.
• refactor : — pour des changements de code qui n’ajoutent pas de fonctionnalité et ne corrigent pas d’erreurs.
• test : — pour l’ajout ou la correction de tests.
• chore : — pour les tâches de routine non liées au code (mise à jour des dépendances, configuration de la build).

Exemples :

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

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

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

N’essayez pas de faire tenir dans un seul commit la correction d’un bug, l’ajout d’une nouvelle fonctionnalité et le refactoring d’un ancien code. Un tel commit est très difficile à examiner, et presque impossible à annuler sans douleur si quelque chose se passe mal.

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

• Mauvais : un seul commit avec le message « Update user page », qui ajoute un champ pour l’avatar, corrige une erreur de validation du nom et change la couleur des boutons.
• Bien : trois commits distincts :
  1. feat: Add avatar upload to user profile
  2. fix: Correct username validation logic
  3. style: Update button colors on user page

Des commits petits et ciblés sont bien plus faciles à comprendre et à gérer.

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

Chaque commit dans la branche principale doit laisser le projet en état de fonctionnement. Avant de le créer, vous devez au minimum vous assurer que le code compile. Mais comment être sûr que vous n’avez pas accidentellement cassé quelque chose ailleurs dans le système ? Se fier uniquement à des vérifications manuelles est risqué.

C’est là que l’automatisation entre en jeu. Dans ce cours, nous ne configurerons pas de processus automatiques, mais vous devez savoir comment cela fonctionne dans les projets réels. Les équipes modernes utilisent des systèmes d’intégration continue (Continuous Integration, CI), tels que GitHub Actions.

Comment cela fonctionne-t-il ?

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

1. GitHub Actions voit cet événement et lance votre workflow.
2. Il « build » automatiquement le projet et exécute tous les tests.
3. Si tous les tests réussissent, une coche 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 une croix rouge. Fusionner une telle PR dans la branche principale est strictement interdit.

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

            subgraph Workflow
            C -- "Lancement" --> D[Exécution_des_tests]
            D --> E[Réussite]
            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
        

Vous pouvez configurer des notifications. Si les tests échouent, GitHub Actions peut envoyer un e-mail à vous ou à toute l’équipe. Cette approche crée une culture où les tests ne sont pas une simple formalité, mais une partie intégrante du développement, et où chacun est responsable de la qualité de son code.