Dans cette unité, nous passons 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 un élément essentiel de l’expérience GitHub, car elles permettent d’apporter des modifications sans affecter l’ensemble du projet.

Votre branche est un espace sécurisé pour expérimenter de nouvelles fonctionnalités ou corriger des bugs.
Si vous faites une erreur, vous pouvez annuler vos modifications ou en pousser de nouvelles pour corriger l’erreur.
Vos modifications ne seront pas appliquées à la branche par défaut tant que vous n’aurez pas fusionné votre branche.

Qu’est-ce qu’un commit ?

Dans l’unité précédente, vous avez ajouté un nouveau fichier au dépôt en effectuant 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, et est enregistré avec la date, l’heure et l’auteur.
Les commits fournissent une traçabilité claire pour toute personne consultant l’historique d’un fichier ou d’un élément lié, comme une issue ou une pull request.

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 d’un fichier dans un dépôt Git sont : Non suivi et Suivi.

Non suivi (Untracked): État initial d’un fichier lorsqu’il n’est pas encore intégré au dépôt Git. Git n’a pas connaissance de son existence.

Suivi (Tracked): Un fichier suivi est un fichier que Git surveille activement. 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é depuis le dernier commit, mais ces modifications ne sont pas encore préparées pour le prochain commit.
• Préparé (Staged) : Le fichier a été modifié et les changements ont été ajoutés à la zone de préparation (appelée aussi index). Ces modifications 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 dernière version validée du fichier.

Ces états et sous-états sont importants pour collaborer efficacement avec votre équipe et savoir où en est chaque commit dans le processus de votre 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 relecteurs de vérifier le code et d’approuver la fusion.
Ces relecteurs peuvent commenter les modifications, ajouter leurs propres changements, ou utiliser la pull request pour discuter davantage.

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 ingrédients, passons en revue le GitHub flow.

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 (demandes de tirage) et les fusions.

Maintenant que nous connaissons les bases de GitHub, nous pouvons passer en revue le GitHub flow et ses différentes étapes.

1. Commencez par créer une branche afin que les modifications, les nouvelles fonctionnalités ou les corrections que vous apportez n’affectent pas la branche principale.
2. Ensuite, effectuez vos modifications. Il est recommandé de déployer les changements sur votre 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.
3. Créez maintenant une pull request pour demander des retours à vos collaborateurs. L’examen des pull requests est si précieux que certains dépôts exigent une approbation avant de permettre la fusion.
4. Passez en revue et appliquez les retours de vos collaborateurs.
5. Une fois que vous êtes satisfait de vos modifications, il est temps de faire approuver votre pull request et de la fusionner dans la branche principale.
6. Enfin, vous pouvez supprimer votre branche. Cela indique que le travail sur cette branche est terminé et évite que vous ou d’autres personnes n’utilisiez accidentellement d’anciennes branches.

Et voilà, vous avez parcouru un cycle complet du GitHub flow !

Passons maintenant à la section suivante, où nous allons aborder les différences entre issues (problèmes) et discussions.