Composants du flux GitHub

  • 8 minutes

Dans cette unité, nous examinons les composants suivants du flux GitHub :

  • Branches
  • Commits
  • Demandes de tirage
  • Le flux GitHub
  • Flux Git

Composants de GitHub Flow

Avant d’accéder aux flux de travail spécifiques à GitHub, il est utile de comprendre que GitHub Flow s’appuie directement sur les concepts fondamentaux de Git.

Git fournit des outils pour suivre et gérer les modifications dans votre code au fil du temps. GitHub s’appuie sur cela en facilitant l’utilisation de ces outils avec des fonctionnalités telles que des branches, des validations, des demandes de tirage et des interfaces visuelles pour la collaboration. Commençons par examiner le fonctionnement de ces concepts dans GitHub.

Qu’est-ce qu’une branche ?

Dans la dernière section, nous avons créé un fichier et une nouvelle branche dans votre référentiel.

Les branches font partie intégrante de l’expérience GitHub. Ils vous permettent d’apporter des modifications sans affecter la branche par défaut.

Votre branche est un endroit sûr où expérimenter de nouvelles fonctionnalités ou correctifs. Si vous faites une erreur, vous pouvez revenir sur vos modifications ou pousser (push) davantage de modifications afin de la corriger. Vos modifications ne seront pas mises à jour sur la branche par défaut tant que vous ne fusionnerez pas votre branche.

Remarque

Vous pouvez également créer une nouvelle branche et la vérifier en utilisant git dans un terminal. La commande serait git checkout -b newBranchName

Qu’est-ce qu’un commit ?

Dans l’unité précédente, vous avez ajouté un nouveau fichier dans le référentiel en envoyant une validation. Examinons brièvement ce qu’est un commit.

Un commit est un changement apporté à un ou plusieurs fichiers d’une branche. Chaque validation est suivie par un ID unique, un horodatage et un contributeur, qu’il soit effectué via la ligne de commande ou directement dans l’interface web de GitHub. Les commits fournissent une piste d’audit claire pour toute personne qui examine l’historique d’un fichier ou d’un élément lié, comme un problème ou une demande de tirage.

Vous pouvez créer une validation à l’aide de Git dans votre terminal avec :

git commit -m "Add a helpful commit message"

Capture d’écran de la liste de validations GitHub vers une branche principale.

Dans un dépôt Git, un fichier peut exister dans plusieurs états valides durant le processus de gestion de version. Les états principaux d’un fichier dans un dépôt Git sont Non suivi et Suivi.

Non suivi : État initial d’un fichier lorsqu’il ne fait pas encore partie du dépôt Git. Git n’a pas connaissance de son existence.

Suivi : Un fichier suivi est un fichier que Git surveille activement. Il peut se trouver dans l’un des sous-états suivants :

  • Non modifié : Le fichier est suivi, mais il n’a pas été modifié depuis le dernier commit.
  • Modifié : Le fichier a été modifié depuis le dernier commit, mais ces modifications ne sont pas encore indexées pour le prochain commit.
  • Indexé : Le fichier a été modifié et les modifications ont été ajoutées dans la zone d’indexation (également appelée index). Ces modifications sont prêtes à être commitées.
  • Commité : Le fichier se trouve dans la base de données du dépôt. Il s’agit de la dernière version commitée du fichier.

Ces états aident votre équipe à comprendre l’état de chaque fichier et où il se trouve dans le processus de contrôle de version.

Qu’est-ce que les demandes de tirage ?

Une demande de tirage (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 demande de tirage demande à un ou plusieurs réviseurs de vérifier le code et d’approuver la fusion. Ces réviseurs ont la possibilité de commenter les changements, d’ajouter leurs propres changements ou d’utiliser la demande de tirage elle-même pour obtenir plus d’informations.

GitHub prend également en charge le brouillon de demandes de tirage, ce qui vous permet d’ouvrir une demande de tirage qui n’est pas encore prête à être examinée.

Une fois les modifications approuvées (si nécessaire), la branche source (branche de comparaison) de la demande de tirage est fusionnée avec la branche de base.

Capture d’écran d’une demande de tirage et d’un commentaire dans la demande de tirage.

Maintenant que vous avez vu comment les branches, les validations et les demandes de tirage fonctionnent, voyons comment elles se rassemblent dans GitHub Flow.

Flux GitHub

Capture d’écran montrant une représentation visuelle du flux GitHub dans un format linéaire qui inclut une nouvelle branche, des validations, une demande de tirage et la fusion des modifications apportées à l’ordre principal.

Le flux GitHub est un flux de travail simple qui vous aide à apporter et partager des modifications en toute sécurité. Il est idéal pour essayer des idées et collaborer avec votre équipe à l’aide de branches, de demandes de tirage et de fusions.

Remarque

Le flux GitHub est l’un des flux de travail populaires. D’autres incluent le flux Git et le développement basé sur les jonctions.

Maintenant que nous connaissons les bases de GitHub, nous pouvons parcourir le flux GitHub et ses composants.

  1. Commencez par créer une branche afin que vos modifications, fonctionnalités ou correctifs n’affectent pas la branche principale.
  2. Ensuite, effectuez vos mises à jour dans la branche. Si votre flux de travail le prend en charge, vous pouvez déployer des modifications de cette branche pour les tester avant de fusionner.
  3. À présent, ouvrez une demande de tirage pour inviter des commentaires et commencer une révision.
  4. Ensuite, passez en revue les commentaires et apportez les mises à jour nécessaires en fonction des commentaires de votre équipe.
  5. Enfin, une fois que vous êtes confiant dans vos modifications, obtenez l’approbation et fusionnez la demande de tirage dans la branche principale.
  6. Ensuite, supprimez la branche pour nettoyer votre dépôt et éviter d’utiliser des branches obsolètes.

Flux Git

Diagramme illustrant le workflow de flux Git avec des voies parallèles pour les branches de fonctionnalités, développer, mettre en production des branches, correctifs logiciels et master. Il montre comment les fonctionnalités sont fusionnées dans le développement, les branches de mise en production sont créées à partir du développement, les correctifs logiciels sont regroupés à partir de master et toutes les modifications sont finalement fusionnées dans master et développer avec des versions marquées.

Bien que GitHub Flow soit un flux de travail léger conçu pour la livraison continue, le flux Git est un modèle de branchement plus structuré souvent utilisé dans les environnements pilotés par la mise en production. Le flux Git a été plus long que GitHub Flow et vous pouvez toujours voir le terme master utilisé au lieu de main la branche par défaut.

Types de branche de flux Git

Le flux Git utilise plusieurs branches de longue durée et temporaires :

  • master : reflète toujours le code prêt pour la production.
  • développer : contient le dernier travail de développement pour la prochaine version.
  • feature/* : Utilisé pour créer de nouvelles fonctionnalités ; branched from develop and merged back when complete.
  • release/* : Prépare une nouvelle version de production à partir de develop; autorise les tests finaux et les correctifs de bogues mineurs.
  • correctif logiciel/* : Utilisé pour corriger rapidement les problèmes de production ; branched à partir de master.

Fonctionnement du processus de flux Git

  1. Les développeurs créent des branches de fonctionnalités pour develop créer de nouvelles fonctionnalités.
  2. Quand il est temps pour une version, une branche de mise en production est créée à partir de develop. Cela isole le travail de préparation des mises en production afin que le développement puisse continuer sans interruption.
  3. Les correctifs de bogues peuvent être ajoutés à la branche de mise en production, mais les principales fonctionnalités doivent attendre une prochaine version.
  4. Une fois prête, la branche de mise en master production est fusionnée et étiquetée avec un numéro de version. GitHub peut utiliser ces balises pour vous aider à générer des notes de publication.
  5. La même branche de mise en production doit être fusionnée develop pour la conserver synchronisée.
  6. Si un bogue de production critique survient, une branche de correctif logiciel est créée à partir de master. Une fois résolu, il est fusionné dans les deux master et develop.

Quand utiliser le flux Git

  • Idéal pour les projets avec des versions planifiées ou avec version
  • Utile si vous gérez plusieurs versions de production (par exemple, des branches de support à long terme)
  • Idéal pour les cycles de développement plus lents et plus structurés (par exemple, les environnements d’entreprise ou réglementés)
  • Considéré comme plus « lourd » que GitHub Flow en raison d’une gestion de branche supplémentaire

Remarque

Le flux Git suppose des validations de fusion pour l’intégration de branches. L’utilisation de fusions de base ou de squash peut interférer avec sa structure de branche et son suivi de l’historique.

Pour de nombreuses équipes utilisant GitHub, GitHub Flow est plus simple et plus rapide. Toutefois, si votre équipe estime la prévisibilité et a besoin d’une planification de mise en production plus grande, le flux Git peut être mieux adapté.

Félicitations! Vous venez de parcourir le flux GitHub complet et vous avez exploré la façon dont le flux Git offre une alternative structurée pour les projets pilotés par les versions.

Passons maintenant à la section suivante, où nous aborderons les différences entre les problèmes et les discussions.