Composants du GitHub Flow
Dans cette unité, nous allons passer en revue les composants suivants du GitHub Flow :
- Branches
- Commits
- Pull Requests
🌿 Qu’est-ce qu’une branche ?
Dans la section précédente, nous avons créé un nouveau fichier et une nouvelle branche dans votre dépôt.
Les branches sont une partie essentielle de l’expérience GitHub, car elles permettent de faire des modifications sans affecter l’ensemble du projet.
Une branche est un espace sécurisé pour expérimenter de nouvelles fonctionnalités ou corriger des erreurs.
Si vous faites une erreur, vous pouvez annuler vos modifications ou pousser de nouveaux changements pour la corriger.
Les modifications ne seront pas appliquées à la branche par défaut tant que vous n’aurez pas fusionné votre branche.
Remarque
Vous pouvez aussi créer une nouvelle branche et la consulter via le terminal avec la commande :
git checkout -b newBranchName
📝 Qu’est-ce qu’un commit ?
Dans l’unité précédente, vous avez ajouté un nouveau fichier au dépôt en poussant un commit.
Voyons brièvement ce qu’est un commit.
Un commit est une modification apportée à un ou plusieurs fichiers sur une branche.
Chaque commit reçoit un identifiant unique, est horodaté, et attribué à un contributeur.
Les commits permettent de :
- Suivre l’historique des fichiers,
- Fournir une traçabilité claire pour toute personne examinant les modifications,
- Lier les changements à des éléments comme les issues ou les pull requests.

🗂️ États des fichiers dans un dépôt Git
Dans un dépôt Git, un fichier peut exister dans plusieurs états valides au cours du processus de contrôle de version.
Les états principaux sont : Non suivi (Untracked) et Suivi (Tracked).
🔸 Non suivi (Untracked)
État initial d’un fichier non encore ajouté au dépôt Git.
Git n’a pas connaissance de son existence.
🔹 Suivi (Tracked)
Un fichier suivi est surveillé activement par Git. Il peut être dans l’un des sous-états suivants :
- Non modifié (Unmodified) : le fichier est suivi, mais n’a pas été modifié depuis le dernier commit.
- Modifié (Modified) : le fichier a été modifié, mais les changements ne sont pas encore préparés pour le prochain commit.
- Préparé (Staged) : les modifications ont été ajoutées à la zone de préparation (appelée aussi index). Elles sont prêtes à être validées.
- Validé (Committed) : le fichier est enregistré dans la base de données du dépôt. Il représente la version la plus récente validée.
Ces états sont essentiels pour collaborer efficacement avec votre équipe et savoir où en est chaque commit dans le processus du projet.
🔀 Qu’est-ce qu’une pull request ?
Une pull request est le mécanisme utilisé pour signaler que les commits d’une branche sont prêts à être fusionnés dans une autre branche.
Le membre de l’équipe qui soumet la pull request demande à un ou plusieurs réviseurs de :
- vérifier le code,
- approuver la fusion,
- commenter les modifications,
- ou même ajouter leurs propres changements.
Une fois les modifications approuvées (si nécessaire), la branche source de la pull request (appelée branche de comparaison) est fusionnée dans la branche de base.

Maintenant que nous connaissons tous les éléments, passons en revue le GitHub Flow.
Le GitHub Flow

Le GitHub Flow peut être défini comme un flux de travail léger qui permet une expérimentation en toute sécurité.
Vous pouvez tester de nouvelles idées et collaborer avec votre équipe en utilisant les branches, les pull requests et les fusions (merges).
Maintenant que nous connaissons les bases de GitHub, parcourons ensemble les étapes du GitHub Flow et ses composants.
🔹 Étapes du GitHub Flow :
- Créer une branche
Commencez par créer une branche pour que les modifications, fonctionnalités ou corrections que vous apportez n’affectent pas la branche principale. - Faire vos modifications
Il est recommandé de déployer vos changements sur la branche de fonctionnalité avant de les fusionner dans la branche principale. Cela permet de s’assurer que les modifications sont valides dans un environnement de production. - Créer une pull request
Demandez à vos collaborateurs de donner leur avis.
La revue de pull request est si importante que certains dépôts exigent une validation avant fusion. - Revoir et appliquer les retours
Prenez en compte les commentaires de vos collaborateurs et ajustez votre code si nécessaire. - Fusionner la pull request
Une fois que vous êtes satisfait des modifications, faites approuver la pull request (si requis) et fusionnez-la dans la branche principale. - Supprimer la branche
Supprimer la branche indique que le travail est terminé et évite toute utilisation accidentelle de branches obsolètes.
🎉 Et voilà, vous avez parcouru un cycle complet du GitHub Flow !
Passons maintenant à la section suivante, où nous allons voir la différence entre les issues et les discussions.