Flux des demandes de fusion sur GitHub

Une demande de fusion (PR) est une proposition visant à fusionner une branche avec une autre. Sur GitHub, elle crée un fil de discussion où vos coéquipiers examinent le code, laissent des commentaires, demandent des modifications et approuvent finalement la fusion.

Après avoir envoyé une branche de fonctionnalité vers GitHub, une bannière jaune apparaît et vous propose de comparer les branches et de créer une PR. Cliquez dessus, ou accédez à Demandes de fusion → Nouvelle demande de fusion et sélectionnez vos branches.

Une bonne description de PR explique : ce qui a changé et pourquoi. Ajoutez une capture d'écran pour les modifications de l'interface utilisateur. Ajoutez un lien vers le problème associé. Décrivez comment vous avez validé la modification. Le lecteur ne devrait pas avoir besoin de lire le code pour comprendre l'intention.

Désignez des coéquipiers précis comme réviseurs. Ils reçoivent une notification et peuvent approuver, demander des modifications ou commenter. La plupart des équipes exigent au moins une approbation avant la fusion.

Les commentaires apparaissent directement sur les lignes modifiées. Les réviseurs peuvent demander des éclaircissements, proposer une autre approche ou approuver. Répondez à chaque commentaire, soit en modifiant le code, soit en expliquant pourquoi vous ne le modifiez pas.

Lorsqu'un réviseur demande des modifications, envoyez de nouveaux commits vers la même branche. La PR est automatiquement mise à jour. Résolvez chaque conversation en cliquant sur « Résoudre la conversation » après l'avoir traitée.

Ouvrez une PR en tant que brouillon pour signaler qu'il s'agit d'un travail en cours. Les PR en brouillon permettent toujours la revue et les discussions, mais ne peuvent pas être fusionnées accidentellement. Passez-la à l'état Prête lorsqu'elle est terminée.

Lorsque main avance pendant la revue, rebasez votre branche sur la dernière version de main afin d'éviter les conflits et de garantir que vos modifications fonctionnent avec le nouveau code.

GitHub propose trois stratégies de fusion : Commit de fusion (préserve tous les commits), Écraser et fusionner (un commit par PR, avec un historique propre pour main), Rebaser et fusionner (historique linéaire, sans commit de fusion). Les équipes choisissent généralement une stratégie unique pour rester cohérentes.

Protégez main en exigeant une revue de PR, en exigeant que les vérifications d'état réussissent et en interdisant les envois directs. Configurez ces règles dans GitHub → Paramètres → Branches.

Gardez les PR petites et ciblées. Une PR par fonctionnalité ou correction. Les PR volumineuses sont difficiles à réviser. Répondez aux commentaires de revue dans la journée. Remerciez les réviseurs. Soyez bienveillant : la revue de code est une occasion d'enseigner, pas un audit.

Que doit contenir une bonne description de PR ?

Envoyez la branche de fonctionnalité → ouvrez une PR avec une description claire → demandez des réviseurs → traitez leurs commentaires avec de nouveaux commits → gardez la branche à jour avec un rebase → obtenez l'approbation → fusionnez. Gardez vos PR petites, ciblées et bien décrites. Les règles de protection des branches garantissent la qualité de main.