Guide de préparation à l'examen de certification GitHub Foundations

Par Chris Williams

En 2024, savoir utiliser Git et GitHub efficacement est un ensemble de compétences indispensable et vital pour presque tous les rôles.

Que vous soyez développeur, ingénieur DevOps, chef de projet, scientifique des données ou même architecte, une solide compréhension de Git et GitHub n'est plus un plus, mais une nécessité.

Ces outils constituent l'épine dorsale du développement logiciel collaboratif, permettant un contrôle de version efficace, le partage de code et le suivi de projet.

La certification GitHub Foundations sert de référence pour valider vos compétences dans l'utilisation de cette plateforme largement adoptée.

Ce manuel vous préparera à passer et à réussir l'examen de certification. Les domaines objectifs listés ci-dessous sont tirés du Guide d'étude de la certification GitHub Foundations.

Mon objectif ici est de fournir aux professionnels du secteur technologique les connaissances et les informations nécessaires pour maîtriser ces outils cruciaux et, ainsi, renforcer leur compétence et leur polyvalence dans un monde axé sur la technologie.

Domaines objectifs

1. Domaine 1 : Introduction à Git et GitHub
2. Domaine 2 : Travailler avec les dépôts GitHub
3. Domaine 3 : Fonctionnalités de collaboration
4. Domaine 4 : Développement moderne
5. Domaine 5 : Gestion de projet
6. Domaine 6 : Vie privée, sécurité et administration
7. Domaine 7 : Avantages de la communauté GitHub
8. Prochaines étapes et conclusion

Domaine 1 : Introduction à Git et GitHub

Notions de base sur Git et GitHub

Décrire le contrôle de version :

Un système de contrôle de version (VCS) est un programme ou un ensemble de programmes qui suit les modifications apportées à une collection de fichiers.

Un objectif d'un VCS est de rappeler facilement les versions antérieures de fichiers individuels ou de l'ensemble du projet. Un autre objectif est de permettre à plusieurs membres de l'équipe de travailler sur un projet, même sur les mêmes fichiers, en même temps sans affecter le travail des autres.

Définir le contrôle de version distribué

Git est distribué, ce qui signifie que l'historique complet d'un projet est stocké à la fois sur le client et sur le serveur.

Vous pouvez modifier des fichiers sans connexion réseau, les valider localement et les synchroniser avec le serveur lorsqu'une connexion devient disponible. Si un serveur tombe en panne, vous avez toujours une copie locale du projet. Techniquement, vous n'avez même pas besoin d'avoir un serveur.

Décrire Git

Git est un système de contrôle de version distribué qui permet aux développeurs de suivre et de gérer les modifications apportées au code ou aux documents. Sa fonctionnalité principale repose sur la création d'une série d'instantanés, appelés commits, qui enregistrent l'état d'un dépôt à un moment donné.

Contrairement aux systèmes de contrôle de version centralisés, la nature distribuée de Git permet à chaque développeur d'avoir un historique complet des modifications, leur permettant de travailler hors ligne et de créer plusieurs branches pour des fonctionnalités ou des versions séparées.

Git prend en charge la collaboration grâce à des fonctionnalités telles que le branchement, la fusion et les dépôts distants, facilitant ainsi la gestion des modifications et des contributions provenant de plusieurs sources.

Son efficacité, sa flexibilité et ses capacités de branchement robustes font de Git un outil incontournable dans le développement logiciel moderne, en particulier dans les projets open source.

Décrire GitHub

GitHub est une plateforme basée sur le web largement utilisée pour le contrôle de version et le développement logiciel. Elle utilise Git, un système de contrôle de version distribué, pour permettre à plusieurs développeurs de travailler de manière collaborative sur des projets sans interférer avec le travail des autres.

GitHub facilite la gestion des modifications de code, prend en charge le branchement et la fusion de code, et fournit une plateforme pour le suivi des problèmes et la révision de code.

De plus, GitHub intègre l'intégration continue/livraison continue (CI/CD) via GitHub Actions, permettant l'automatisation des flux de travail logiciels.

L'aspect réseau social de GitHub permet aux utilisateurs de suivre le travail des autres, de contribuer à des projets open source et d'obtenir des informations sur diverses méthodologies de développement.

Les fonctionnalités étendues de GitHub, combinées à sa facilité d'utilisation et à son solide soutien communautaire, en ont fait un outil indispensable pour le développement logiciel moderne, que ce soit pour les programmeurs individuels ou les projets d'entreprise à grande échelle.

Expliquer la différence entre Git et GitHub :

Git est un système de contrôle de version distribué (DVCS) que plusieurs développeurs et autres contributeurs peuvent utiliser pour travailler sur un projet. Il fournit un moyen de travailler avec une ou plusieurs branches locales, puis de les pousser vers un dépôt distant.

GitHub est une plateforme cloud qui utilise Git comme technologie centrale. GitHub simplifie le processus de collaboration sur les projets et fournit un site web, plus d'outils en ligne de commande et un flux global que les développeurs et les utilisateurs peuvent utiliser pour travailler ensemble. GitHub agit comme le dépôt distant.

Les principales fonctionnalités fournies par GitHub incluent : Problèmes, Discussions, Demandes de tirage, Notifications, Étiquettes, Actions, Forks, & Projets

Décrire un dépôt GitHub

Un dépôt est un élément fondamental dans l'écosystème GitHub, servant d'espace de stockage pour les projets de développement logiciel. Il contient tous les fichiers du projet (y compris la documentation), et stocke l'historique des révisions de chaque fichier.

Les dépôts peuvent être publics, les rendant accessibles à tous, ou privés, restreints à des collaborateurs spécifiques. Ils servent de point focal pour le développement collaboratif, permettant aux développeurs de suivre les changements, de revenir à des états précédents et de travailler sur différentes branches d'un projet sans affecter la base de code principale.

Les dépôts GitHub prennent également en charge des fonctionnalités telles que les problèmes et les demandes de tirage, facilitant la discussion, les commentaires et les contributions au projet.

De plus, GitHub fournit une intégration avec divers outils et services, permettant des flux de travail automatisés, une intégration continue et un déploiement. Cela fait d'un dépôt GitHub non seulement un espace de stockage, mais une plateforme complète pour gérer l'ensemble du cycle de vie d'un projet logiciel.

Décrire un commit

Dans Git, un commit est une opération fondamentale qui capture l'état actuel des fichiers d'un projet. Il sert d'instantané, enregistrant les modifications apportées aux fichiers d'un dépôt depuis le dernier commit.

Chaque commit contient un identifiant unique, des informations sur l'auteur, un horodatage et un message décrivant les modifications. Ce processus permet de suivre l'historique des modifications, permettant aux développeurs de revenir à des versions précédentes si nécessaire et de comprendre l'évolution du projet au fil du temps.

Les commits sont essentiels pour le travail collaboratif, car ils fournissent un moyen de fusionner les modifications de différents contributeurs de manière fluide et de maintenir un historique de projet cohérent.

Décrire le branchement

Le branchement est une méthode de divergence de la ligne principale de développement et de continuation du travail de manière indépendante sans affecter cette ligne principale.

Chaque branche représente une ligne de développement indépendante, permettant à plusieurs tâches telles que le travail sur des fonctionnalités, la correction de bugs ou des expériences de procéder en parallèle.

La branche par défaut dans Git est généralement appelée main, mais les branches peuvent être nommées n'importe comment.

Le branchement est un concept central dans Git, car il permet aux développeurs de travailler dans un environnement isolé sans impacter le reste du projet.

Il est particulièrement utile dans les environnements collaboratifs, où il permet aux équipes de travailler simultanément sur différentes fonctionnalités ou versions d'un produit. Les modifications apportées dans une branche n'affectent pas les autres branches jusqu'à ce qu'elles soient fusionnées dans la branche principale, facilitant ainsi un développement contrôlé et organisé.

Définir un dépôt distant dans la terminologie Git

Dans la terminologie Git, un "dépôt distant" fait référence à une version distante de votre dépôt. C'est un dépôt commun que tous les membres de l'équipe utilisent pour échanger leurs modifications.

Dans la plupart des cas, le dépôt distant est stocké sur un serveur, souvent un service d'hébergement basé sur le web comme GitHub, GitLab ou Bitbucket. Les principales utilisations d'un dépôt distant sont la sauvegarde, la collaboration et la synchronisation :

1. Sauvegarde : Il sert de sauvegarde fiable de votre dépôt local.
2. Collaboration : Un dépôt distant est généralement l'endroit central où les membres de l'équipe peuvent pousser leurs modifications locales et tirer les mises à jour des autres, facilitant ainsi le travail collaboratif.
3. Synchronisation : Il aide à maintenir les dépôts locaux synchronisés avec le travail des autres membres de l'équipe.

Dans Git, le terme origin est un nom par défaut donné au dépôt distant à partir duquel votre dépôt local a été initialement cloné, mais vous pouvez travailler avec plusieurs dépôts distants et les nommer différemment.

La gestion des dépôts distants implique des commandes comme git remote add pour ajouter un nouveau dépôt distant, git fetch pour récupérer les mises à jour d'un dépôt distant, git push pour envoyer les mises à jour locales à un dépôt distant, et git pull pour obtenir les mises à jour distantes dans votre dépôt local.

Décrire le flux GitHub

1. La première étape du flux GitHub consiste à créer une branche afin que les modifications, fonctionnalités et corrections que vous créez n'affectent pas la branche principale.
2. La deuxième étape consiste à apporter vos modifications. Je recommande de déployer les modifications sur votre branche de fonctionnalité avant de les fusionner dans la branche principale. Cela garantit que les modifications sont valides dans un environnement de production.
3. La troisième étape consiste à créer une demande de tirage pour demander des commentaires aux collaborateurs. La révision des demandes de tirage est si précieuse que certains dépôts nécessitent une révision approuvée avant que les demandes de tirage puissent être fusionnées.
4. Ensuite, vient la révision et la mise en œuvre de vos commentaires de la part de vos collaborateurs.
5. Une fois que vous êtes satisfait de vos modifications, il est temps de faire approuver votre demande de tirage et de la fusionner dans la branche principale.
6. La dernière étape consiste à supprimer votre branche. La suppression de votre branche signale que votre travail sur la branche est terminé et empêche vous ou d'autres d'utiliser accidentellement d'anciennes branches.

Entités GitHub

Décrire les différents comptes GitHub (personnel, organisation, entreprise)

Compte Personnel : Chaque personne qui utilise GitHub.com se connecte à un compte personnel. Votre compte personnel/utilisateur est votre identité sur GitHub.com et dispose d'un nom d'utilisateur et d'un profil.

Votre compte personnel/utilisateur peut posséder des ressources telles que des dépôts, des packages et des projets ainsi que gérer vos permissions. Chaque fois que vous effectuez une action sur GitHub.com, comme la création d'un problème ou la révision d'une demande de tirage, l'action est attribuée à votre compte personnel.

Chaque compte personnel utilise soit GitHub Free soit GitHub Pro. Tous les comptes personnels peuvent posséder un nombre illimité de dépôts publics et privés, avec un nombre illimité de collaborateurs sur ces dépôts. Si vous utilisez GitHub Free, les dépôts privés détenus par votre compte personnel ont un ensemble de fonctionnalités limité.

Comptes d'organisation : il s'agit de comptes partagés où un nombre illimité de personnes peuvent collaborer sur de nombreux projets à la fois. Contrairement aux comptes personnels/utilisateurs, les permissions avec les comptes d'organisation sont effectuées selon une approche hiérarchisée.

De manière similaire aux comptes personnels, les organisations peuvent posséder des ressources telles que des dépôts, des packages et des projets. Mais vous ne pouvez pas vous connecter à une organisation. Au lieu de cela, chaque personne se connecte à son propre compte personnel, et toute action que la personne effectue sur les ressources de l'organisation est attribuée à son compte personnel. Chaque compte personnel peut être membre de plusieurs organisations.

Les comptes personnels au sein d'une organisation peuvent se voir attribuer différents rôles dans l'organisation pour accorder différents niveaux d'accès à l'organisation et à ses données. Tous les membres peuvent collaborer entre eux dans les dépôts et les projets. Mais seuls les propriétaires de l'organisation et les gestionnaires de sécurité peuvent gérer les paramètres de l'organisation et contrôler l'accès aux données de l'organisation avec des fonctionnalités de sécurité et d'administration.

Comptes d'entreprise : ces comptes permettent aux administrateurs de gérer centralement les politiques et la facturation pour plusieurs organisations et de permettre le sourcing interne entre leurs organisations. Un compte d'entreprise doit avoir un identifiant, comme un compte d'organisation ou d'utilisateur sur GitHub.

Les organisations sont des comptes partagés pour les membres de l'entreprise afin de collaborer sur de nombreux projets à la fois. Dans les paramètres de l'entreprise, les propriétaires de l'entreprise peuvent inviter des organisations existantes à rejoindre votre compte d'entreprise, transférer des organisations entre des comptes d'entreprise, ou créer de nouvelles organisations.

Les comptes d'entreprise vous permettent de gérer et de faire respecter les politiques pour toutes les organisations détenues par l'entreprise. Chaque politique d'entreprise contrôle les options disponibles pour une politique au niveau de l'organisation.

Décrire les produits GitHub pour les comptes personnels (gratuit, pro)

GitHub Free pour les comptes personnels inclut :

• Support de la communauté GitHub
• Alertes Dependabot
• Application de l'authentification à deux facteurs
• 500 Mo de stockage GitHub Packages
• 120 heures de cœur GitHub Codespaces par mois
• 15 Go de stockage GitHub Codespaces par mois
• GitHub Actions :
  • 2 000 minutes par mois
  • Règles de protection de déploiement pour les dépôts publics

GitHub Pro pour les comptes personnels inclut les fonctionnalités de GitHub Free plus :

• Support GitHub par e-mail
• 3 000 minutes GitHub Actions par mois
• 2 Go de stockage GitHub Packages
• 180 heures de cœur GitHub Codespaces par mois
• 20 Go de stockage GitHub Codespaces par mois
• Outils et informations avancés dans les dépôts privés :
  • Réviseurs de demande de tirage requis
  • Plusieurs réviseurs de demande de tirage
  • Branches protégées
  • Propriétaires de code
  • Références auto-liées
  • GitHub Pages
  • Wikis
  • Graphiques d'informations de dépôt pour le pouls, les contributeurs, le trafic, les commits, la fréquence de code, le réseau et les forks

Décrire les produits GitHub pour les comptes d'organisation (gratuit pour les organisations, équipes)

GitHub Free pour les organisations inclut GitHub Free pour les comptes personnels plus :

• Contrôles d'accès d'équipe pour la gestion de groupes

GitHub Team est "GitHub Pro pour les organisations" et inclut :

• Support GitHub par e-mail
• 3 000 minutes GitHub Actions par mois
• 2 Go de stockage GitHub Packages
• Outils et informations avancés dans les dépôts privés :
  • Réviseurs de demande de tirage requis
  • Plusieurs réviseurs de demande de tirage
  • Demandes de tirage en brouillon
  • Réviseurs de demande de tirage d'équipe
  • Branches protégées
  • Propriétaires de code
  • Rappels planifiés
  • GitHub Pages
  • Wikis
• Graphiques d'informations de dépôt pour le pouls, les contributeurs, le trafic, les commits, la fréquence de code, le réseau et les forks
• L'option d'activer ou de désactiver GitHub Codespaces

Décrire les différentes options de déploiement pour GitHub Enterprise

Il existe deux options GitHub Enterprise : GitHub Enterprise Server (GHES) et GitHub Enterprise Cloud.

La différence significative entre elles est que GHES est une solution auto-hébergée qui permet aux organisations de contrôler leur infrastructure.

L'autre différence entre elles est que GitHub Enterprise Cloud inclut des augmentations des minutes GitHub Actions et du stockage GitHub Packages :

• 50 000 minutes GitHub Actions par mois
• 50 Go de stockage GitHub Packages
• Un SLA pour un temps de fonctionnement mensuel de 99,9 %
• Option de gérer centralement les politiques et la facturation pour plusieurs organisations GitHub.com avec un compte d'entreprise
• Option de provisionner et de gérer les comptes utilisateurs pour vos développeurs, en utilisant Enterprise Managed Users

Décrire les fonctionnalités du profil utilisateur (métadonnées, réalisations, readme de profil, dépôts, dépôts épinglés, étoiles, etc.)

Les personnes qui visitent un profil voient une chronologie de l'activité de contribution de l'utilisateur, comme les problèmes et les demandes de tirage ouverts, les commits effectués et les demandes de tirage révisées.

Vous pouvez choisir d'afficher uniquement les contributions publiques ou d'inclure également les contributions privées anonymisées.

Les personnes qui visitent le profil d'un utilisateur peuvent également voir les informations suivantes :

• Dépôts et gists possédés ou contribués. Le travail peut être mis en avant en épinglant des dépôts et des gists au profil.
• Les dépôts peuvent être étoilés et organisés en listes.
• Un aperçu de l'activité dans les organisations, les dépôts et les équipes actifs.
• Badges et réalisations qui mettent en avant l'activité et montrent si un utilisateur utilise GitHub Pro ou participe à des programmes comme l'Arctic Code Vault, GitHub Sponsors ou le programme GitHub Developer.
• Pronoms si définis.
• Connexions mutuelles partagées avec quelqu'un qui consulte votre profil. La personne qui consulte votre profil peut voir quelles sont les personnes qu'elle suit et qui sont également suivies par vous.

Vous pouvez également définir un statut sur votre profil pour fournir des informations sur votre disponibilité.

Markdown GitHub

Identifier la barre d'outils de mise en forme de texte dans les commentaires des problèmes et des demandes de tirage

Chaque champ de commentaire sur GitHub contient une barre d'outils de mise en forme de texte, qui vous permet de formater votre texte sans apprendre la syntaxe Markdown. En plus de la mise en forme Markdown comme les styles gras et italique et la création d'en-têtes, de liens et de listes, la barre d'outils inclut des fonctionnalités spécifiques à GitHub telles que les @-mentions, les listes de tâches et les liens vers les problèmes et les demandes de tirage :

Décrire Markdown

Markdown est un langage de balisage léger avec une syntaxe de formatage en texte brut souvent utilisé pour écrire de la documentation, en particulier dans des contextes en ligne. Il permet aux utilisateurs d'écrire en utilisant un format de texte brut facile à lire et à écrire, qui se convertit ensuite en HTML (ou XHTML) structurellement valide pour être visualisé dans un navigateur web ou d'autres plateformes.

Les principales caractéristiques de Markdown incluent la simplicité et la facilité d'utilisation. Il prend en charge diverses fonctionnalités de formatage comme les en-têtes, les listes, l'emphase, les liens, les citations, le code en ligne, les images et les tableaux.

Initialement créé par John Gruber et Aaron Swartz, Markdown a gagné une immense popularité, en particulier sur des plateformes comme GitHub, car il permet une documentation efficace et efficiente sans le surcoût de coder directement en HTML.

Identifier la syntaxe de formatage de base (en-têtes, liens, listes de tâches, commentaires, etc.)

Lien vers le guide Markdown

GitHub Flavored Markdown (GFM) prend en charge divers formats de raccourcis pour faciliter la liaison aux problèmes et aux demandes de tirage. La manière la plus simple de le faire est d'utiliser le format #ID

Expliquer où trouver et utiliser les commandes slash

Les commandes slash peuvent vous faire gagner du temps en réduisant la saisie nécessaire pour créer un Markdown complexe.

Vous pouvez utiliser des commandes slash dans n'importe quel champ de description ou de commentaire dans les problèmes, les demandes de tirage ou les discussions où cette commande slash est prise en charge. Commande|Référence brute -|- /code|Insère un bloc de code Markdown. Vous choisissez le langage. /details|Insère une zone de détails pliable. Vous choisissez le titre et le contenu. /saved-replies|Insère une réponse enregistrée. Vous choisissez parmi les réponses enregistrées pour votre compte utilisateur. Si vous ajoutez %cursor% à votre réponse enregistrée, la commande slash place le curseur à cet endroit. /table|Insère un tableau Markdown. Vous choisissez le nombre de colonnes et de lignes. /tasklist|Insère une liste de tâches. Cette commande slash ne fonctionne que dans une description de problème. /template|Affiche tous les modèles du dépôt. Vous choisissez le modèle à insérer. Cette commande slash fonctionne pour les modèles de problème et un modèle de demande de tirage.

GitHub Desktop

Expliquer la différence entre GitHub Desktop et github.com

GitHub Desktop est une application autonome qui permet aux utilisateurs d'interagir avec les dépôts GitHub via une interface graphique. Il prend en charge les opérations courantes de Git et GitHub sans avoir besoin d'un navigateur ou d'une ligne de commande, et il est compatible avec macOS, Windows et Linux.

Vous pouvez utiliser GitHub Desktop pour gérer une copie locale d'un dépôt. Vous ne pouvez pas effectuer de fonctionnalités basées sur le site web GitHub comme fork, star, watch, collaborer, créer des problèmes/PRs, ou intégrer avec des outils CI/CD en ligne.

Décrire les fonctionnalités disponibles avec GitHub Desktop

• Ajouter et cloner des dépôts.
• Ajouter des modifications à votre commit de manière interactive.
• Ajouter rapidement des co-auteurs à votre commit.
• Vérifier les branches avec les demandes de tirage et voir les statuts CI.
• Comparer les images modifiées.

GitHub Mobile

Décrire les fonctionnalités disponibles avec GitHub Mobile

• Gérer, trier et effacer les notifications de github.com.
• Lire, réviser et collaborer sur les problèmes et les demandes de tirage.
• Modifier des fichiers dans les demandes de tirage.
• Rechercher, parcourir et interagir avec les utilisateurs, les dépôts et les organisations.
• Recevoir une notification push lorsque quelqu'un mentionne votre nom d'utilisateur.
• Planifier des notifications push pour des heures personnalisées spécifiques.
• Sécuriser votre compte GitHub.com avec l'authentification à deux facteurs.
• Vérifier vos tentatives de connexion sur des appareils non reconnus.

Expliquer comment gérer les notifications via l'application GitHub Mobile

Définir les notifications push pour :

• DMs
• Demandes de révision
• Assigné
• Révision de déploiement
• Révision de demande de tirage
• Exécutions de workflow

Définir les heures de travail pour ne les recevoir que pendant certaines périodes.

Domaine 2 : Travailler avec les dépôts GitHub

Comprendre les dépôts GitHub

Terminologie des dépôts Terme|Définition -|- Branche|Une version parallèle de votre code qui est contenue dans le dépôt, mais qui n'affecte pas la branche principale ou principale. Cloner|Télécharger une copie complète des données d'un dépôt depuis GitHub.com, y compris toutes les versions de chaque fichier et dossier. Fork|Un nouveau dépôt qui partage le code et les paramètres de visibilité avec le dépôt "amont" original. Fusionner|Prendre les modifications d'une branche et les appliquer à une autre. Demande de tirage (PR)|Une demande pour fusionner les modifications d'une branche dans une autre. Distant|Un dépôt stocké sur GitHub, pas sur votre ordinateur. Amont|La branche sur un dépôt original qui a été forkée ou clonée. La branche correspondante sur la branche clonée ou forkée est appelée "aval".

Décrire les composants d'un bon README et les fichiers de dépôt recommandés (LICENSE, CONTRIBUTING, CODEOWNERS)

Vous pouvez ajouter un fichier README à un dépôt pour communiquer des informations importantes sur votre projet. Un README, ainsi qu'une licence de dépôt, un fichier de citation, des directives de contribution et un code de conduite, communique les attentes pour votre projet et vous aide à gérer les contributions.

Un README est souvent le premier élément qu'un visiteur verra lorsqu'il visitera votre dépôt.

Les fichiers README incluent généralement des informations sur :

• Ce que fait le projet
• Pourquoi le projet est utile
• Comment les utilisateurs peuvent commencer avec le projet
• Où les utilisateurs peuvent obtenir de l'aide avec votre projet
• Qui maintient et contribue au projet

Si vous placez votre fichier README dans le répertoire caché .github, root, ou docs de votre dépôt, GitHub le reconnaîtra et affichera automatiquement votre README aux visiteurs du dépôt.

Si un dépôt contient plus d'un fichier README, alors le fichier affiché est choisi parmi les emplacements dans l'ordre suivant :

1. le répertoire .github
2. le répertoire root du dépôt
3. le répertoire docs

Si vous ajoutez un fichier README à la racine d'un dépôt public avec le même nom que votre nom d'utilisateur, ce README s'affichera automatiquement sur votre page de profil.

Vous pouvez éditer votre README de profil avec GitHub Flavored Markdown (GFM) pour créer une section personnalisée sur votre profil.

GitHub a créé https://choosealicense.com, pour vous aider à comprendre comment licencier votre code. Une licence logicielle informe les autres de ce qu'ils peuvent et ne peuvent pas faire avec votre code source, il est donc important de prendre une décision éclairée.

Le texte de la licence doit figurer dans un fichier nommé LICENSE.txt (ou LICENSE.md ou LICENSE.rst) à la racine du dépôt.

Vous pouvez utiliser un fichier CODEOWNERS pour définir les individus ou les équipes responsables du code dans un dépôt.

Expliquer la navigation de base dans un dépôt

Lire Créer & Gérer des dépôts 🥰

Expliquer comment créer un nouveau dépôt

1. Dans le coin supérieur droit de n'importe quelle page, sélectionnez le menu déroulant , puis cliquez sur Nouveau dépôt :

2. Utilisez le menu déroulant Propriétaire pour sélectionner le compte auquel vous souhaitez que le dépôt appartienne.
3. Saisissez un nom pour votre dépôt, et une description facultative.
4. Choisissez une visibilité de dépôt. Pour plus d'informations, voir "À propos des dépôts."
5. Vous pouvez créer un README, qui est un document décrivant votre projet.
6. Vous pouvez créer un fichier .gitignore, qui est un ensemble de règles d'ignorance.
7. Vous pouvez choisir d'ajouter une licence logicielle pour votre projet.
8. Cliquez sur Créer un dépôt :

Décrire les modèles de dépôt

Pour créer un dépôt de modèle, vous devez créer un dépôt, puis faire de ce dépôt un modèle.

Après avoir fait de votre dépôt un modèle, toute personne ayant accès au dépôt peut générer un nouveau dépôt avec la même structure de répertoires et les mêmes fichiers que votre branche par défaut. Ils peuvent également choisir d'inclure toutes les autres branches de votre dépôt.

Les branches créées à partir d'un modèle ont des historiques non liés, vous ne pouvez donc pas créer de demandes de tirage ou fusionner entre les branches.

Voici les étapes à suivre pour cela :

1. Sur GitHub.com, accédez à la page principale du dépôt.
2. Sous le nom de votre dépôt, cliquez sur Paramètres :

3. Sélectionnez Dépôt de modèle :

Décrire comment cloner un dépôt

Cloner un dépôt télécharge une copie complète de toutes les données du dépôt que GitHub.com possède à ce moment-là, y compris toutes les versions de chaque fichier et dossier du projet.

Pour cloner un dépôt, suivez ces étapes :

1. Sur GitHub.com, accédez à la page principale du dépôt.
2. Au-dessus de la liste des fichiers, cliquez sur Code.
3. Copiez l'URL du dépôt :

CleanShot-2024-03-09-at-11.48.38

4. Ouvrez le Terminal
5. Changez le répertoire de travail actuel pour l'emplacement où vous souhaitez que le répertoire cloné soit placé.
6. Tapez git clone, puis collez l'URL que vous avez copiée précédemment :

Décrire comment créer une nouvelle branche

Vous pouvez créer une nouvelle branche de plusieurs manières, à la fois dans l'interface web et depuis le terminal.

1. Sur GitHub.com, accédez à la page principale du dépôt.
2. À partir de la vue de l'arborescence des fichiers sur la gauche, sélectionnez le menu déroulant des branches, puis cliquez sur Voir toutes les branches.
3. Cliquez sur Nouvelle branche :

4. Sous "Nom de la branche", tapez un nom pour la branche.
5. Sous "Source de la branche", choisissez une source pour votre branche.
6. Sélectionnez le menu déroulant des branches et cliquez sur une branche.
7. Cliquez sur Créer une branche :

Expliquer comment ajouter des fichiers à un dépôt

Vous pouvez ajouter des fichiers jusqu'à 25 Mo à un dépôt via un navigateur. Vous pouvez ajouter des fichiers jusqu'à 100 Mo (chacun) via l'interface de ligne de commande. Vous ne pouvez pas ajouter/télécharger de fichiers vers des branches protégées.

1. Sur GitHub.com, accédez à la page principale du dépôt.
2. Au-dessus de la liste des fichiers, sélectionnez le menu déroulant Ajouter un fichier et cliquez sur Télécharger des fichiers. Vous pouvez également glisser-déposer des fichiers dans votre navigateur :

3. Dans le champ "Message de commit", tapez un message de commit court et significatif qui décrit la modification que vous avez apportée au fichier. S'il y a plusieurs auteurs, vous pouvez leur attribuer le commit ici.
4. Sous les champs de message de commit, décidez si vous souhaitez ajouter votre commit à la branche actuelle ou à une nouvelle branche (la meilleure pratique est de NE PAS commiter sur main, mais plutôt de faire une PR et de fusionner).
5. Cliquez sur Proposer des modifications :

Identifier comment afficher les insights du dépôt

Vous pouvez afficher les statistiques de votre dépôt à partir de l'onglet insights :

• Pulse - Activité récente (PRs, problèmes, etc.).
• Contributeurs - qui contribue et leurs statistiques.
• Normes communautaires - Vérifie les fichiers de directives de contribution que les mainteneurs de dépôt peuvent définir pour aider les collaborateurs à apporter des contributions utiles à un projet.
• Commits - Graphique des commits au fil du temps.
• Fréquence du code - Ajouts/suppressions au fil de l'historique du dépôt.
• Graphe des dépendances - Une liste des dépendances et des dépendants du dépôt.
• Réseau - Chronologie des commits les plus récents dans ce dépôt et son réseau, classés par les plus récemment poussés.
• Forks - Liste des forks du dépôt.

Expliquer comment sauvegarder un dépôt avec des étoiles

Vous pouvez étoiler des dépôts et des sujets pour suivre les projets que vous trouvez intéressants et découvrir du contenu connexe dans votre fil d'actualité :

Expliquer les aperçus de fonctionnalités

Vous pouvez voir une liste des fonctionnalités disponibles en version bêta et une brève description pour chaque fonctionnalité. Chaque fonctionnalité inclut un lien pour donner des commentaires.

1. Dans le coin supérieur droit, cliquez sur votre photo de profil, puis cliquez sur Aperçu des fonctionnalités :

2. Pour afficher les détails d'une fonctionnalité, dans la barre latérale de gauche, cliquez sur le nom de la fonctionnalité (où vous pouvez également activer/désactiver cette fonctionnalité) :

Domaine 3 : Fonctionnalités de collaboration

Problèmes

Décrire comment lier une PR à un problème

Vous pouvez lier une demande de tirage à un problème en utilisant un mot-clé pris en charge dans la description de la demande de tirage ou dans un message de commit. La demande de tirage doit être sur la branche par défaut. Les mots-clés sont : close closes closed fix fixes fixed resolve resolves et resolved.

La syntaxe pour les mots-clés de fermeture dépend du fait que le problème se trouve dans le même dépôt que la demande de tirage.

Décrire comment créer un problème

Il existe plusieurs façons de créer un problème

• À partir d'un dépôt :
• Avec GitHub CLI
• À partir d'un commentaire :
• À partir du code
• À partir d'une discussion
• À partir d'un projet
• À partir d'une liste d'éléments de tâche
• À partir d'une requête URL
• À partir d'une alerte de balayage de code

Décrire la différence entre un problème, une discussion et une demande de tirage

Un problème sur GitHub est un moyen de suivre les améliorations, les tâches ou les bugs pour le travail sur GitHub. C'est un outil principal pour la résolution collaborative de problèmes au sein d'un dépôt.

Lorsque quelqu'un identifie un bug dans votre code ou souhaite demander une nouvelle fonctionnalité, il peut ouvrir un problème. C'est un moyen d'avoir une conversation sur le code sans le modifier directement. Les problèmes peuvent être assignés, étiquetés et référencés dans les demandes de tirage.

Les discussions GitHub sont une fonctionnalité qui fournit un espace pour que les membres de la communauté s'engagent dans des conversations et partagent des idées, des questions ou des commentaires. Il s'agit davantage d'avoir une conversation ouverte plutôt que de suivre des tâches ou de signaler des problèmes comme les problèmes.

Les discussions sont plus adaptées aux Q&A, au partage de mises à jour, au brainstorming ou aux conversations générales sur un projet.

Une demande de tirage est un moyen de proposer des modifications à la base de code. Lorsque vous ouvrez une demande de tirage, vous suggérez que vos modifications doivent être fusionnées dans le code principal.

Les PR sont utilisées pour la révision de code, où d'autres peuvent réviser, discuter et demander des modifications supplémentaires avant de fusionner les modifications proposées.

Une demande de tirage inclut les modifications de code, une comparaison avec le code existant et un fil de discussion.

Expliquer comment créer une branche à partir d'un problème

À partir d'un problème, vous pouvez créer une branche associée :

Cela crée une branche qui est numérotée avec le même numéro que le problème, permettant un suivi plus facile du problème :

Identifier comment assigner des problèmes

1. Accédez au problème : Allez dans votre dépôt sur GitHub et trouvez le problème que vous souhaitez assigner. Vous pouvez le faire en cliquant sur l'onglet 'Problèmes' dans votre dépôt.
2. Ouvrez le problème : Cliquez sur le titre du problème pour l'ouvrir.
3. Assignez le problème : Sur le côté droit du problème, vous verrez une section intitulée 'Assignés'. Cliquez sur l'icône d'engrenage à côté de 'Assignés'.
4. Sélectionnez un utilisateur : Un menu déroulant apparaîtra avec une liste d'utilisateurs. Ce sont les personnes à qui vous pouvez assigner le problème. Il s'agit généralement des contributeurs et collaborateurs de votre dépôt. Sélectionnez l'utilisateur ou les utilisateurs à qui vous souhaitez assigner le problème.
5. Confirmez l'assignation : Les utilisateurs sélectionnés seront maintenant listés sous 'Assignés' pour le problème. GitHub sauvegarde automatiquement vos modifications, il n'est donc pas nécessaire d'avoir un bouton de confirmation :

Décrire comment rechercher et filtrer les problèmes

Vous pouvez filtrer les problèmes et les demandes de tirage pour trouver :

• Tous les problèmes et demandes de tirage ouverts
• Les problèmes et demandes de tirage que vous avez créés
• Les problèmes et demandes de tirage qui vous sont assignés
• Les problèmes et demandes de tirage où vous êtes @mentionné

Voici comment vous pouvez rechercher/filtrer les problèmes :

1. Accédez à la section Problèmes : Allez dans le dépôt GitHub où vous souhaitez rechercher ou filtrer les problèmes. Cliquez sur les onglets 'Problèmes' ou 'Demandes de tirage'.
2. Utilisez la barre de recherche : En haut de la liste des problèmes, il y a une barre de recherche. Vous pouvez taper des mots-clés liés au problème que vous recherchez. Cela peut inclure des termes spécifiques mentionnés dans le titre ou le corps du problème.
3. Filtrer par étiquettes : GitHub vous permet d'ajouter des étiquettes aux problèmes pour les catégoriser. Vous pouvez filtrer les problèmes en fonction de ces étiquettes. Cliquez sur 'Étiquettes' et sélectionnez celle par laquelle vous souhaitez filtrer.
4. Filtrer par assigné : Pour voir les problèmes assignés à une personne spécifique, cliquez sur le menu déroulant 'Assigné' et sélectionnez un utilisateur.
5. Filtrer par auteur : Si vous souhaitez voir les problèmes créés par un utilisateur spécifique, utilisez le filtre 'Auteur'.
6. Filtrer par jalons : Si votre projet utilise des jalons, vous pouvez filtrer les problèmes en fonction du jalon auquel ils sont associés.
7. Filtres avancés : GitHub prend également en charge des filtres plus avancés comme le filtrage par statut ouvert/fermé, des mentions spécifiques, des commentaires, ou même des plages de temps spécifiques. Ceux-ci peuvent généralement être accessibles en cliquant sur un menu déroulant ou en entrant des commandes de filtre spécifiques dans la barre de recherche.

Décrire comment épingler un problème

Vous pouvez épingler jusqu'à trois problèmes importants dans la liste des problèmes d'un dépôt.

Dans l'onglet problèmes, cliquez sur le problème à épingler, puis dans la barre latérale de droite, cliquez sur 'Épingler le problème' :

Expliquer la gestion de base des problèmes

Création de problèmes : Les problèmes peuvent être créés par tout utilisateur ayant accès au dépôt. Ils sont généralement utilisés pour signaler des bugs, demander des fonctionnalités ou discuter d'autres tâches.

Pour créer un problème, cliquez sur l'onglet 'Problèmes' dans le dépôt, puis sur 'Nouveau problème'. Vous pouvez ensuite remplir le titre et la description, ajouter des étiquettes et assigner le problème à un utilisateur.

Étiquetage des problèmes : Les étiquettes sont un moyen utile de catégoriser les problèmes. Les étiquettes courantes incluent 'bug', 'demande de fonctionnalité' et 'aide souhaitée'. Elles peuvent être personnalisées pour répondre aux besoins du projet. Les étiquettes aident à organiser et à prioriser les problèmes.

Assignation des problèmes : Les problèmes peuvent être assignés à des utilisateurs spécifiques. Cela est généralement fait pour indiquer qui est responsable de travailler sur le problème. Cela aide à distribuer les tâches parmi les membres de l'équipe.

Jalons : Les jalons peuvent être utilisés pour regrouper les problèmes ensemble, souvent pour une version spécifique ou une phase de projet. Cela aide à suivre les progrès vers un objectif particulier.

Commentaires sur les problèmes : Les membres de l'équipe peuvent commenter les problèmes pour les discuter plus en détail. Cela fait partie intégrante de la résolution collaborative de problèmes et peut inclure des suggestions, des questions ou des mises à jour sur les progrès.

Fermeture des problèmes : Une fois qu'un problème a été résolu, il doit être fermé. Cela aide à garder le suivi des problèmes propre et concentré sur les problèmes en suspens.

Recherche et filtrage des problèmes : GitHub fournit des outils pour rechercher et filtrer les problèmes. Cela peut être fait en utilisant des mots-clés, des étiquettes, des assignés ou d'autres critères. Cela aide à trouver des problèmes spécifiques rapidement.

Liaison des demandes de tirage aux problèmes : Souvent, les demandes de tirage sont liées aux problèmes. Cela indique que les modifications de code dans la demande de tirage traitent le problème. GitHub fournit un lien automatique dans la demande de tirage vers le problème correspondant lorsqu'il est mentionné.

Expliquer la différence entre les modèles de problème et les formulaires de problème

Les modèles de problème sont des fichiers markdown qui créent une structure prédéfinie pour que les utilisateurs remplissent lorsqu'ils ouvrent un nouveau problème. Le modèle peut inclure des en-têtes, des listes de contrôle et des zones de texte avec des instructions comme "Décrivez le bug" ou "Étapes pour reproduire". Ils aident à guider l'utilisateur pour fournir les détails nécessaires.

Les modèles de problème sont flexibles et peuvent être édités en tant que texte brut. Si vous souhaitez que les contributeurs fournissent des informations spécifiques et structurées lorsqu'ils ouvrent des problèmes, les formulaires de problème aident à garantir que vous recevez les informations souhaitées.

Les formulaires de problème, en revanche, ont été introduits comme une alternative plus structurée aux modèles de problème. Ils permettent aux mainteneurs de dépôt de créer des formulaires plus interactifs et conviviaux en utilisant des fichiers de configuration YAML.

Les formulaires de problème peuvent inclure des champs obligatoires, des menus déroulants, des cases à cocher, des validations, des assignés par défaut, des étiquettes par défaut, et plus encore, garantissant que les utilisateurs fournissent toutes les informations essentielles lors de la soumission d'un problème. Cela réduit les chances de recevoir des rapports incomplets ou vagues.

Expliquer comment utiliser les mots-clés dans les problèmes

Les mots-clés sont utilisés dans les demandes de tirage et les messages de commit pour lier la demande de tirage ou le commit à un problème, et éventuellement pour fermer le problème lorsque la demande de tirage est fusionnée.

• Pour lier une demande de tirage ou un commit à un problème sans le fermer, vous pouvez utiliser des mots-clés comme "refers to", "addresses", ou "re:", suivis du numéro du problème. Par exemple, "Refers to #123".

• Pour fermer un problème automatiquement lorsqu'une demande de tirage est fusionnée, utilisez des mots-clés tels que "close", "closes", "closed", "fix", "fixes", "fixed", "resolve", "resolves", ou "resolved", suivis du numéro du problème. Par exemple, "Fixes #123" dans la description de la demande de tirage ou un message de commit fermera le problème 123 lors de la fusion de la demande de tirage.

• Lors de la création d'une demande de tirage ou d'un commit, incluez le mot-clé choisi suivi du numéro du problème dans la description de la demande de tirage ou le message de commit. Par exemple : "Ce commit fixe #123 en ajoutant de nouvelles règles de validation".

• Si votre demande de tirage ou commit traite plusieurs problèmes, vous pouvez utiliser plusieurs mots-clés. Par exemple : "Ce commit ferme #123, résout #124, et se réfère à #125".

Demandes de tirage

Décrire une demande de tirage

Une demande de tirage (communément appelée PR) est une manière de proposer des modifications à une base de code dans un environnement collaboratif. Elle permet une révision de code, une discussion et des modifications avant d'intégrer les changements dans le projet principal.

Une PR est un pilier du développement logiciel collaboratif et un excellent moyen d'assurer la qualité et de partager les connaissances au sein de l'équipe.

Expliquer comment créer une nouvelle demande de tirage

• Étape 1 : Branche - Vous commencez avec une branche, qui est comme votre espace de travail personnel dans le dépôt d'un projet.
• Étape 2 : Faire des modifications - Vous faites votre magie ici (écrivez du code, corrigez des bugs, ajoutez des fonctionnalités, etc.).
• Étape 3 : Commit - Une fois que vous êtes satisfait de votre travail, vous le commitez dans votre branche.
• Étape 4 : Créer la demande de tirage - Maintenant, vous créez une demande de tirage vers la branche principale.
• Étape 5 : Révision & Discussion - Un mainteneur du dépôt vérifie votre travail. Il peut suggérer des modifications ou poser des questions.
• Étape 6 : Fusion - Si tout semble bon, vos modifications sont fusionnées dans la branche principale.

Décrire les branches base et compare dans une demande de tirage

La branche compare est la branche du développeur où le nouveau travail est effectué.

La branche base est celle où vous souhaitez fusionner les modifications. Elle est souvent appelée main ou (dans le passé) master.

Expliquer la relation des commits sur une demande de tirage

Lorsque vous créez une nouvelle branche pour effectuer un travail, vous commitez vos modifications dans cette branche. Une fois que vous avez terminé vos commits dans cette branche, GitHub vous invitera à 'Comparer & demander une fusion' dans main.

Décrire les demandes de tirage en brouillon

Les demandes de tirage en brouillon dans GitHub sont une fonctionnalité qui permet aux développeurs de créer des demandes de tirage incomplètes ou en cours de travail (WIP).

Cette fonctionnalité est particulièrement utile lorsque vous souhaitez obtenir des commentaires sur du code qui n'est pas encore prêt à être fusionné dans la base de code principale.

Une demande de tirage en brouillon ne peut pas être fusionnée et les propriétaires du dépôt ne sont pas automatiquement notifiés pour les réviser.

Lors de la création d'une demande de tirage, vous avez la possibilité de la marquer comme brouillon. Vous pouvez le faire en sélectionnant la case à cocher "Créer comme brouillon" dans l'interface de création de la demande de tirage.

Une fois marquée comme brouillon, la demande de tirage est clairement étiquetée comme telle, indiquant aux autres membres de l'équipe qu'elle n'est pas prête pour une révision finale ou une fusion.

Décrire l'objectif des onglets de demande de tirage (conversation, commits, vérifications, fichiers modifiés)

Conversation : C'est le hub social de la PR. C'est là que l'équipe discute des modifications proposées. Vous y trouverez des commentaires généraux sur la PR, des retours, des suggestions et souvent un peu de discussion amicale. C'est aussi là que les messages automatisés, comme ceux des outils d'intégration continue (CI), apparaissent. Considérez-le comme la salle de réunion où tout le monde discute de la PR.

Commits : Cet onglet est comme un journal de toutes les modifications apportées. Chaque entrée (commit) dans ce journal contient un message expliquant ce qui a été modifié et par qui. En parcourant cela, vous pouvez voir l'évolution de la PR, chaque commit représentant une étape dans le processus de développement.

Vérifications : C'est le centre de contrôle qualité. Il montre l'état des vérifications automatisées qui ont été exécutées sur le code. Cela peut inclure des tests, des vérifications de style de code (linting), des analyses de sécurité et d'autres revues automatisées. Les cocottes vertes signifient que tout va bien, tandis que les X rouges sont comme des panneaux d'arrêt indiquant que quelque chose nécessite de l'attention.

Fichiers modifiés : La loupe de la PR, cet onglet vous montre exactement ce qui a été modifié dans chaque fichier. C'est là que vous pouvez effectuer une révision ligne par ligne des modifications, faire des suggestions ou demander des modifications supplémentaires. C'est un outil crucial pour s'assurer que seul le meilleur code, le plus poli, est intégré au projet.

Identifier comment lier l'activité au sein d'une demande de tirage

Lier l'activité au sein d'une demande de tirage, c'est comme créer un réseau de miettes de pain qui relient différentes parties de l'histoire de votre projet. Cela aide tout le monde à comprendre comment votre demande de tirage s'intègre dans le tableau d'ensemble.

Voici comment vous pouvez tisser ce réseau de connexions :

• Référencer des problèmes : Si votre demande de tirage traite un problème spécifique, vous pouvez y faire un lien. Il suffit d'inclure des phrases comme fixes #numéro_du_problème, closes #numéro_du_problème, ou resolves #numéro_du_problème dans la description de votre PR ou dans un message de commit. Cela crée non seulement un lien mais aide également à fermer automatiquement le problème référencé lorsque la PR est fusionnée.

• Mentionner d'autres demandes de tirage ou discussions : Vous pouvez référencer d'autres PR ou discussions en utilisant le # suivi du numéro de PR/discussion (comme #123). Cela est pratique lorsque votre travail est lié ou dépend du travail de quelqu'un d'autre.

• Lier à des commits : Pour référencer un commit spécifique dans votre discussion, utilisez son SHA (l'identifiant unique du commit). C'est comme dire, "Hey, regardez ce moment spécifique dans l'historique de notre projet !"

• Mentionner des membres de l'équipe : Besoin de commentaires spécifiques d'un collègue ? Utilisez @nomdutilisateur pour attirer son attention. C'est comme un petit coup de coude amical pour qu'il regarde quelque chose de spécifique.

• Utiliser Markdown pour un contexte supplémentaire : GitHub prend en charge Markdown, qui vous permet d'ajouter des liens vers des ressources externes, des images ou des documents qui peuvent être pertinents pour votre PR. Cela est utile pour fournir un contexte ou des preuves supplémentaires pour les modifications que vous proposez.

• Liste de contrôle pour suivre les progrès : Dans la description de la PR, vous pouvez inclure une liste de tâches en utilisant - [ ]. Cela aide à suivre les progrès des différents composants de votre PR, surtout dans les mises à jour importantes.

Expliquer les différents statuts des demandes de tirage

• Demande de tirage en brouillon - Lorsque vous créez une demande de tirage, vous pouvez choisir de créer une demande de tirage prête pour la révision ou une demande de tirage en brouillon. Une demande de tirage avec un statut de brouillon ne peut pas être fusionnée, et les propriétaires de code ne sont pas automatiquement invités à réviser les demandes de tirage en brouillon.
• Demande de tirage ouverte - Un statut ouvert signifie que la demande de tirage est active et n'a pas encore été fusionnée dans la branche de base. Vous pouvez encore effectuer des commits et discuter et réviser les modifications potentielles avec les collaborateurs.
• Demande de tirage fermée - Vous pouvez choisir de fermer une demande de tirage sans la fusionner dans la branche de base/principale. Cette option peut être utile si les modifications proposées dans la branche ne sont plus nécessaires, ou si une autre solution est proposée dans une autre branche.
• Demande de tirage fusionnée - Le statut de demande de tirage fusionnée signifie que les mises à jour et les commits de la branche de comparaison ont été combinés avec la branche de base. Toute personne ayant un accès en push au dépôt peut effectuer la fusion.

Reconnaître comment commenter un lien publié vers une ligne ou des lignes de code d'un fichier

Passez la souris sur la ligne de code où vous souhaitez ajouter un commentaire, et cliquez sur l'icône de commentaire bleu.

Pour ajouter un commentaire sur plusieurs lignes, cliquez et faites glisser pour sélectionner la plage de lignes, puis cliquez sur l'icône de commentaire bleu.

Décrire la révision de code avec un fichier codeowners

La révision de code dans GitHub avec un fichier CODEOWNERS est une partie intégrante du flux de travail GitHub. Elle vise à améliorer la qualité et la sécurité du code.

Le fichier CODEOWNERS peut être placé dans le répertoire racine, docs/, ou .github/ d'un dépôt. Il spécifie les individus ou les équipes responsables du code dans certaines parties du dépôt.

Voici un bref aperçu :

• Définir les propriétaires de code : Dans le fichier CODEOWNERS, vous pouvez spécifier les propriétaires pour des fichiers et répertoires spécifiques en utilisant les noms d'utilisateur GitHub ou les noms d'équipe, ainsi que les motifs de chemin de fichier. Voir un exemple de fichier CODEOWNERS ici
• Demandes de révision automatiques : Lorsqu'une demande de tirage (PR) modifie un code dans des zones couvertes par le fichier CODEOWNERS, GitHub demande automatiquement une révision aux propriétaires spécifiés. Cela garantit que les bonnes personnes révisent les modifications du code qu'elles connaissent.
• Révision obligatoire pour les branches protégées : Pour les dépôts avec des règles de protection de branche, vous pouvez imposer que le code modifié soit révisé par ses propriétaires avant d'être fusionné. Cela est particulièrement utile dans les dépôts critiques où la qualité et la sécurité sont primordiales.
• Flexibilité et documentation : Le fichier CODEOWNERS peut être mis à jour à mesure que les équipes et les bases de code évoluent. Il sert également de documentation claire des responsabilités, aidant les nouveaux membres de l'équipe à comprendre qui maintient quelle partie du code.
• Intégration avec GitHub Actions : Vous pouvez intégrer davantage CODEOWNERS avec GitHub Actions pour automatiser divers aspects de votre flux de travail de développement, améliorant ainsi l'efficacité globale du processus.

Expliquer les différentes options pour fournir une révision de code sur une demande de tirage (commentaire, approuver, demander des modifications, modifications suggérées)

• Commentaire : Cela est utilisé lorsque vous souhaitez laisser une remarque ou une observation sur une partie spécifique du code mais que vous ne souhaitez pas nécessairement approuver formellement ou demander des modifications.
• Approuver : Cette option est utilisée lorsque vous avez révisé la PR et que vous pensez qu'elle est prête à être fusionnée sans aucune modification supplémentaire.
• Demander des modifications : Cela est utilisé lorsque vous identifiez des problèmes qui doivent être résolus avant que la PR puisse être fusionnée.
• Modifications suggérées : Cette fonctionnalité vous permet de proposer des modifications spécifiques au code.
• Demandes de tirage en brouillon : créez une demande de tirage mais marquez-la comme brouillon. Cela indique que la PR est un travail en cours et n'est pas encore prête pour la révision. Une fois qu'elle est prête, vous pouvez la marquer comme "Prête pour la révision."

Discussions

Décrire la différence entre les discussions et les problèmes

Problèmes :

• Principalement utilisés pour suivre les tâches, les bugs, les améliorations et autres éléments actionnables.
• Les problèmes sont plus formels et ciblés.
• Ils peuvent être étiquetés, assignés à des individus et sont souvent liés directement aux modifications de code (demandes de tirage).
• Utilisés pour suivre les progrès du travail, discuter des modifications potentielles ou signaler des bugs.
• Peuvent être fermés lorsqu'ils sont résolus, et ils sont intégrés aux flux de travail de gestion de projet et de développement logiciel.

Cas d'utilisation : Si un utilisateur trouve un bug ou a une demande de fonctionnalité, il ouvrirait un problème pour en discuter et suivre les progrès de cet élément spécifique.

Discussions :

• Destinées à des conversations plus larges et à l'engagement communautaire, les discussions portent davantage sur les idées, les Q&A et les conversations générales.
• Plus informelles et ouvertes par rapport aux problèmes.
• Un espace pour les questions, les idées de fonctionnalités ou les conversations générales qui n'ont pas besoin d'une résolution immédiate.
• Prennent en charge un format de discussion, rendant les conversations prolongées plus faciles à suivre. Elles peuvent être catégorisées (par exemple, Q&A, Idées, Général, etc.) pour une meilleure organisation.
• Idéales pour construire une communauté autour du projet, où les utilisateurs et les contributeurs peuvent s'engager sans le formalisme d'un problème.

Cas d'utilisation : Si quelqu'un a une question sur l'utilisation du projet, ou s'il y a un désir d'avoir une conversation sur les meilleures pratiques, les directions futures ou les sujets liés à la communauté, il commencerait ou participerait à une discussion.

Expliquer les options disponibles avec les discussions (annonces, idées, sondages, Q&A, montrer et raconter)

Annonces :

• Objectif : Utilisées pour partager des mises à jour, des nouvelles importantes ou des informations sur le projet. Seuls les mainteneurs ou les membres désignés de la communauté peuvent publier des annonces.
• Cas d'utilisation : Partager des mises à jour de version, des changements de politique, ou toute information critique dont la communauté doit être consciente.

Idées :

• Objectif : Pour proposer de nouvelles fonctionnalités, des améliorations ou des améliorations au projet.
• Cas d'utilisation : Si un membre a une idée pour une nouvelle fonctionnalité ou une amélioration de la fonctionnalité existante, il peut la publier sous cette catégorie. La communauté peut ensuite discuter et itérer sur ces idées.

Sondages :

• Objectif : Permet aux mainteneurs de créer des sondages pour obtenir des commentaires de la communauté.
• Cas d'utilisation : Lorsqu'un mainteneur de projet souhaite recueillir des opinions ou prendre des décisions basées sur les préférences de la communauté, les sondages peuvent être un outil utile. Cela pourrait être pour de nouvelles fonctionnalités, des changements d'interface utilisateur, ou tout autre aspect où l'apport de la communauté est précieux.

Q&A :

• Objectif : Un espace pour poser et répondre à des questions liées au projet.
• Cas d'utilisation : Si quelqu'un a besoin d'aide avec un aspect particulier du projet, ou s'il a des questions sur l'utilisation d'une fonctionnalité, il peut demander sous la catégorie Q&A. D'autres, y compris les mainteneurs et les membres de la communauté, peuvent fournir des réponses.

Montrer et raconter :

• Objectif : Pour que les utilisateurs présentent leur travail lié au projet.
• Cas d'utilisation : Si un membre de la communauté souhaite partager quelque chose qu'il a construit en utilisant le projet, comme une nouvelle intégration, un outil, ou tout cas d'utilisation créatif, il peut le faire sous Montrer et raconter. Cela encourage le partage d'idées et l'innovation au sein de la communauté.

Identifier comment marquer un commentaire comme réponse à une discussion

En tant que mainteneur de dépôt, contributeur ou auteur original de la question, vous verrez une option pour marquer un commentaire comme réponse :

Expliquer comment convertir une discussion en problème

Dans la discussion que vous souhaitez convertir, dans la barre latérale de droite, vous avez l'option de Créer un problème à partir de la discussion :

Reconnaître comment épingler une discussion

Dans la discussion que vous souhaitez épingler, dans la barre latérale de droite, vous avez l'option de Épingler :

discussion**

Notifications

Décrire comment gérer les abonnements aux notifications

Vous pouvez spécifier comment recevoir les notifications, les dépôts qui vous intéressent et les types d'activité dont vous souhaitez être informé.

Dans la barre latérale de gauche en bas, vous pouvez gérer vos notifications

Expliquer comment s'abonner aux fils de notification

Le système de notification de GitHub est flexible, vous permettant d'être impliqué autant que vous le souhaitez dans les dépôts et les discussions :

• Naviguez vers la page du dépôt ou du problème
• Surveillez le dépôt

En cliquant sur ce bouton, vous aurez plusieurs options :

• "Surveiller" : Vous recevrez des notifications pour toutes les conversations.
• "Ne pas surveiller" : Vous ne recevrez plus de notifications, mais vous serez notifié lorsque vous participerez à une conversation ou que quelqu'un vous mentionnera.
• "Ignorer" : Vous ne recevrez aucune notification du dépôt.
• S'abonner à un problème ou une demande de tirage : Pour des problèmes ou des demandes de tirage spécifiques, naviguez vers celui qui vous intéresse. Sur le côté droit, vous trouverez une barre latérale "Notifications". Ici, vous pouvez cliquer sur le bouton "S'abonner" pour obtenir des mises à jour pour ce problème ou cette demande de tirage particulier.
• Configurer vos paramètres de notification : Vous pouvez affiner vos préférences de notification dans les paramètres de votre compte GitHub. Allez dans votre profil, sélectionnez "Paramètres", puis "Notifications". Ici, vous pouvez configurer comment vous recevez les notifications (par exemple, par e-mail ou sur le web) et pour quels types d'activités

Décrire comment trouver les fils où vous êtes mentionné

Sur la page des notifications, vous pouvez filtrer en utilisant l'option 'Mentionné' :

Identifier les options de filtrage des notifications

Tout vs Participation :

• Tout : Cette option montre toutes les notifications des dépôts que vous surveillez.
• Participation : Ce filtre montre les notifications des fils dans lesquels vous avez participé, par exemple via des commentaires ou si vous êtes @mentionné.

Raison de la notification : Vous pouvez filtrer les notifications en fonction de la raison pour laquelle vous les avez reçues, comme être directement mentionné, avoir créé le fil ou faire partie d'une équipe qui est mentionnée.

Dépôt : Vous pouvez filtrer les notifications en fonction de dépôts spécifiques. Cela est particulièrement utile si vous suivez plusieurs dépôts et souhaitez vous concentrer sur les mises à jour d'un seul ou de quelques-uns d'entre eux.

Type d'activité : Cette option vous permet de filtrer les notifications en fonction du type d'activité, comme les problèmes, les demandes de tirage ou les discussions.

Non lues : Ce filtre vous permet de voir uniquement les notifications que vous n'avez pas encore lues, vous aidant ainsi à vous concentrer sur les nouvelles mises à jour.

Filtres personnalisés : GitHub permet également la création de filtres personnalisés basés sur divers critères, qui peuvent être une combinaison des éléments ci-dessus ou des critères plus spécifiques. Vous pouvez sauvegarder ces filtres pour un accès rapide à l'avenir.

Notifications d'une plage de temps spécifique : Vous pouvez filtrer les notifications en fonction de leur date de création, comme dans la dernière journée, semaine ou une plage de temps personnalisée.

Mots-clés : Vous pouvez également utiliser des mots-clés dans la barre de recherche de la page des notifications pour trouver des notifications spécifiques.

Expliquer les différentes options de configuration des notifications

Je pense avoir épuisé la configuration des notifications à ce stade 🤣 Je vous recommande de parcourir https://github.com/settings/notifications et de cliquer sur tout ce qui reste et pour lequel vous pourriez avoir une question.

Gists, Wikis et GitHub Pages

Expliquer comment créer un GitHub gist

Les Gists sont des dépôts Git, ils peuvent donc être forkés et clonés comme n'importe quel autre dépôt Git. Cela en fait un outil polyvalent pour la collaboration et le contrôle de version de petits morceaux de code ou de texte.

Voici comment créer un gist :

1. Allez sur https://gist.github.com/
2. Ajoutez du code
3. Choisissez un gist public ou secret (note : toute personne ayant le lien peut voir un gist secret !)

Décrire comment forker et cloner un gist

Forker un Gist

• Trouver le Gist à Forker
• Forker le Gist : En haut à droite de la page du gist, vous verrez un bouton "Fork". Cliquez sur ce bouton pour créer une copie du gist sous votre compte GitHub.

• Après avoir cliqué sur "Fork", vous serez redirigé vers votre propre copie du gist, que vous pouvez maintenant modifier. Le gist indiquera qu'il est forké depuis le gist original de l'utilisateur.

Cloner un Gist

• Obtenir l'URL de clonage : Sur la page du gist, cherchez le bouton "Embed" en haut à droite. Cliquez dessus pour voir l'URL de clonage. Assurez-vous de copier l'URL (vous pouvez choisir entre SSH ou HTTPS).

• Ouvrez le Terminal ou l'invite de commande et clonez selon le processus habituel.

Expliquer les pages Wiki de GitHub

Les pages Wiki fournissent un espace associé à un dépôt GitHub pour créer et partager une documentation détaillée sur le projet. Elles sont utiles pour des choses comme des descriptions de projet étendues, des manuels utilisateur, de la documentation de conception, des exemples, ou tout autre chose que vous souhaitez partager sur votre projet.

Décrire comment créer, éditer et supprimer des pages Wiki

Créer une page Wiki

Tout d'abord, vous devrez activer le Wiki : cliquez sur "Paramètres" puis cochez la case "Wiki" sous "Fonctionnalités."

Une fois activé, un nouvel onglet "Wiki" apparaît sur la page d'accueil du dépôt. Cliquez dessus pour accéder à la section Wiki.

Vous pouvez créer une nouvelle page Wiki en cliquant sur le bouton "Nouvelle Page". Vous serez invité à lui donner un titre, puis vous pourrez commencer à ajouter du contenu.

Supprimer un wiki

Cliquez sur le bouton Modifier de la page que vous souhaitez supprimer, puis cliquez sur le bouton Supprimer la page :

Expliquer la visibilité des pages Wiki

Si le dépôt est public, le Wiki est également visible publiquement. Cela signifie que n'importe qui sur Internet peut voir les pages Wiki, qu'il ait ou non un compte GitHub.

Pour les dépôts privés, le Wiki n'est visible que par les utilisateurs qui ont accès au dépôt. Cela inclut les collaborateurs avec les permissions appropriées.

Par défaut, toute personne ayant un accès en push au dépôt peut éditer le Wiki.

Les Wikis peuvent être clonés comme n'importe quel autre dépôt Git. La visibilité du clone suit les mêmes règles - public pour les dépôts publics, et restreint pour les dépôts privés.

Si vous changez la visibilité d'un dépôt de public à privé (ou vice versa), la visibilité du Wiki changera également en conséquence.

Contrairement à d'autres aspects des dépôts GitHub, les Wikis ne supportent pas le fork ou les demandes de tirage. Cela signifie que la collaboration et les contributions sont gérées par des éditions directes et dépendent des permissions d'accès définies par le propriétaire du dépôt.

Décrire GitHub Pages

GitHub Pages est un service d'hébergement web proposé par GitHub qui permet aux utilisateurs d'héberger leur site web statique directement depuis un dépôt GitHub. Il est particulièrement populaire parmi les développeurs pour héberger la documentation de projet, les blogs personnels et les sites de portfolio.

Vous pouvez accéder à GitHub Pages depuis le domaine nomdutilisateur.github.com

Domaine 4 : Développement moderne

GitHub Actions

Décrire GitHub Actions (compréhension de base)

GitHub Actions est une plateforme d'intégration continue et de livraison continue (CI/CD) qui est intégrée directement avec vos dépôts GitHub. Elle vous permet d'automatiser votre pipeline de construction, de test et de déploiement.

Vous pouvez créer des workflows qui construisent et testent chaque demande de tirage vers votre dépôt, ou déployer des demandes de tirage fusionnées en production.

Les actions sont définies comme des fichiers YAML situés dans le dossier .github/workflow. Vous pouvez avoir plusieurs workflows dans un dépôt qui sont déclenchés par différents événements.

Expliquer où vous pouvez utiliser GitHub Actions dans GitHub (types d'événements généraux)

• Événements de Push : Déclencher des actions sur tout événement de push vers un dépôt, comme lorsque du code est poussé vers une branche ou qu'une nouvelle balise est créée. Cela est couramment utilisé pour les processus d'intégration continue (CI).
• Événements de Pull Request : Les actions peuvent être déclenchées par différentes étapes des pull requests, comme ouvertes, rouvertes, synchronisées ou fermées. Cela permet des tests automatisés, des vérifications de style de code, ou même le déploiement d'environnements de prévisualisation pour une pull request.
• Événements de Problème : Automatiser les workflows en réponse aux activités de problème comme créées, éditées, étiquetées ou fermées. Cela peut être utilisé pour le triage automatique des problèmes ou les systèmes de notification.
• Événements de Publication : Déclencher des workflows lorsqu'une nouvelle publication est publiée ou qu'une publication de brouillon est créée. Cela est souvent utilisé pour automatiser les processus de déploiement.
• Événements Planifiés : Exécuter des workflows selon un calendrier en utilisant la syntaxe cron. Cela peut être utile pour les builds nocturnes, les tâches de routine ou les travaux de synchronisation de données.
• Événements Manuels : Avec workflow_dispatch, vous pouvez manuellement déclencher un workflow depuis l'interface utilisateur de GitHub. Cela est utile pour les workflows qui doivent être exécutés occasionnellement et ne doivent pas être liés aux modifications de code.
• Événements de Registre : Les actions peuvent répondre aux événements des registres de packages, comme le registre de packages GitHub, lorsque des packages sont publiés ou mis à jour.
• Forking et Starring des Dépôts : Déclencheurs lorsqu'un dépôt est forké ou étoilé, ce qui peut être utile pour recueillir des métriques ou des messages automatisés.
• Événements Gollum : Déclenchés par les modifications apportées au wiki d'un dépôt, ce qui est utile pour les workflows de mise à jour de la documentation.
• Événements Webhook : Si aucun des événements prédéfinis ne correspond à vos besoins, GitHub Actions peut également être déclenché par des événements externes en utilisant des webhooks de dépôt.

Expliquer où trouver des GitHub Actions existantes

Le GitHub Marketplace est l'un des principaux endroits pour trouver des GitHub Actions existantes. Vous pouvez parcourir ou rechercher des actions créées par la communauté GitHub et des vendeurs tiers : GitHub Marketplace - Actions.

GitHub maintient un ensemble officiel d'actions pour les tâches CI/CD courantes, telles que la configuration de différents environnements de programmation, la mise en cache des dépendances ou le déploiement de code. GitHub Actions

Et de nombreux projets open source et entreprises partagent leurs GitHub Actions personnalisées sur des dépôts publics. Vous pouvez rechercher ces dépôts directement sur GitHub. Utilisez des mots-clés comme "GitHub Actions" ainsi que des tâches ou outils spécifiques qui vous intéressent (par exemple, "Docker GitHub Actions").

GitHub Copilot

Décrire GitHub Copilot

Copilot est un service qui vous fournit un programmeur pair IA qui fonctionne avec tous les langages de programmation populaires et accélère la productivité globale des développeurs.

Développé en collaboration avec OpenAI, GitHub Copilot est alimenté par OpenAI Codex, un système IA créé par OpenAI. OpenAI Codex a une connaissance approfondie de la manière dont les gens utilisent le code, en partie parce qu'il a été formé sur un ensemble de données qui inclut une concentration plus élevée de code source public.

GitHub Copilot est disponible en tant qu'extension pour Visual Studio Code, Visual Studio, Vim/Neovim, et la suite d'environnements de développement intégrés (IDE) de JetBrains.

Les fonctionnalités incluent :

• Complétion automatique alimentée par l'IA
• Expérience similaire à ChatGPT dans votre éditeur avec GitHub Copilot Chat
• Copilot pour les demandes de tirage
• Réponses générées par l'IA sur la documentation (GitHub Copilot pour Docs)
• Copilot pour l'interface de ligne de commande (CLI)

Décrire la différence entre GitHub Copilot pour les particuliers et GitHub Copilot pour les entreprises

GitHub Copilot est disponible via les comptes personnels GitHub avec GitHub Copilot Individual, ou via les comptes d'organisation ou d'entreprise avec GitHub Copilot Business et GitHub Copilot Enterprise.

Copilot Business vous permet de contrôler qui peut utiliser GitHub Copilot dans votre entreprise. Une fois que vous avez donné accès à une organisation, ses administrateurs peuvent ensuite donner accès à des individus et des équipes.

Avec Copilot Business, GitHub Copilot est ouvert à chaque développeur, équipe et organisation, et entreprise.

Fonctionnalités de GitHub Copilot Business : complétions de code, chat dans l'IDE et mobile, filtre de vulnérabilités de sécurité, référencement de code, filtre de code public, indemnisation IP, et sécurité, sûreté et confidentialité de niveau entreprise

Note : GitHub Copilot Enterprise dispose d'une couche supplémentaire de personnalisation, permettant aux organisations d'utiliser leur propre base de code pour former l'IA*.

Expliquer comment commencer à utiliser GitHub Copilot

1. Inscrivez-vous pour un essai gratuit ou un abonnement (photo de profil -> Paramètres -> Copilot se trouve dans le menu de gauche sous Code, planification et automatisation) :

2. Installez une extension pour votre IDE préféré (voir les IDE pris en charge ci-dessus)
3. Activez (ou désactivez) l'extension GitHub Copilot dans votre IDE :

GitHub Codespaces

Décrire GitHub Codespaces

GitHub Codespaces est un environnement de développement basé sur le cloud intégré directement dans GitHub. Il vous permet de coder directement dans votre navigateur, offrant un environnement de développement entièrement fonctionnel, personnalisable et conteneurisé que vous pouvez configurer pour correspondre à votre configuration locale. Cela signifie que vous pouvez écrire, exécuter et déboguer votre code sans avoir besoin de configurer quoi que ce soit sur votre propre ordinateur.

Fonctionnalités clés :

1. Environnement instantané : Les Codespaces se lancent rapidement, vous offrant un environnement de développement en quelques secondes, préchargé avec votre code et vos dépendances.
2. Entièrement fonctionnel : Offre une prise en charge des extensions et fonctionnalités de Visual Studio Code (VS Code), y compris une suite complète d'outils de développement et un accès au terminal.
3. Personnalisable et configurable : Vous pouvez définir des configurations dans votre dépôt pour vous assurer que l'environnement répond aux exigences de votre projet, telles que des dépendances spécifiques, des extensions et des paramètres.
4. Développement à distance : Étant basé sur le cloud, il est accessible depuis n'importe quel appareil, ce qui facilite le passage entre les machines ou la collaboration avec d'autres.
5. Intégration avec GitHub : Directement intégré avec les dépôts GitHub, ce qui facilite la création de demandes de tirage, la visualisation des différences et l'exécution des opérations Git directement depuis l'environnement de développement.

Identifier comment démarrer un GitHub codespace

Vous pouvez créer un Codespace sur GitHub.com, dans Visual Studio Code, ou via GitHub CLI.

Il existe quatre façons de créer un Codespace :

• À partir d'un modèle GitHub ou de n'importe quel dépôt de modèle sur GitHub.com pour démarrer un nouveau projet.
• À partir d'une branche dans votre dépôt pour un nouveau travail de fonctionnalité.
• À partir d'une demande de tirage ouverte pour explorer le travail en cours.
• À partir d'un commit dans l'historique d'un dépôt pour investiguer un bug à un moment spécifique.

Décrire le cycle de vie des codespaces

Vous pouvez créer un nouveau Codespace chaque fois que vous développez dans GitHub Codespaces ou conserver un Codespace à long terme pour une fonctionnalité.

Lorsque vous créez un nouveau Codespace chaque fois que vous travaillez sur un projet, vous devez régulièrement pousser vos modifications pour vous assurer que tout nouveau commit est sur GitHub. Après avoir créé un Codespace, le clone est placé dans le répertoire /workspace.

Vous pouvez créer un nombre illimité de Codespaces par dépôt ou branche, en fonction de l'espace disponible. Lorsque vous atteignez une quantité supérieure de ressources, un message s'affiche indiquant qu'un Codespace existant doit être supprimé/supprimé avant qu'un nouveau Codespace ne puisse être créé.

Lors de la création d'un GitHub Codespace, quatre processus se produisent :

1. Une VM et un stockage sont attribués à votre Codespace.
2. Un conteneur est créé.
3. Une connexion au Codespace est établie.
4. Une configuration post-création est effectuée.

Sauvegarde des modifications : l'auto-sauvegarde est activée automatiquement via le web, mais si vous passez par VS Code, vous devez l'activer manuellement. Votre travail est sauvegardé jusqu'à une machine virtuelle. Vous pouvez fermer et arrêter un Codespace et revenir au travail sauvegardé.

Si vous avez des modifications non sauvegardées, vous recevez une invite pour les sauvegarder avant de quitter. Si vous ne sauvegardez pas et que votre Codespace est supprimé, votre travail est perdu. Pour sauvegarder votre travail, vous devez commiter et pousser les modifications vers votre dépôt distant.

Ouverture d'un Codespace existant : Allez dans le dépôt où se trouve le codespace et appuyez sur , sur le clavier -> sélectionnez reprendre ou ouvrez https://github.com/codespaces, sélectionnez le dépôt, & sélectionnez le codespace existant :

Décrire les différentes personnalisations que vous pouvez personnaliser avec GitHub Codespaces

• Synchronisation des paramètres : Vous pouvez synchroniser les paramètres de VS Code entre l'application et le client web.
• Dotfiles : Vous pouvez utiliser un dépôt de dotfiles pour spécifier des scripts, des préférences de shell et d'autres configurations.
• Renommer un Codespace : Lorsque vous créez un Codespace, un nom lui est attribué. Si vous avez plusieurs Codespaces, le nom d'affichage vous aide à les différencier et vous pouvez les renommer.
• Changer votre shell : Ouvrez une nouvelle fenêtre de terminal avec un shell de votre choix, changez votre shell par défaut ou installez un nouveau shell. Vous pouvez utiliser des dotfiles pour configurer votre shell.
• Changer le type de machine.
• Définir l'éditeur par défaut :
  • Visual Studio Code - application de bureau
  • Visual Studio Code - client web
  • JetBrains Gateway - pour ouvrir des Codespaces dans un IDE JetBrains
  • JupyterLab - l'interface web pour Project Jupyter
• Définir la région par défaut.
• Définir le délai d'expiration : Par défaut, cette période est de 30 minutes, mais vous pouvez spécifier une période de délai d'expiration par défaut plus longue ou plus courte dans vos paramètres personnels sur GitHub.
• Configurer la suppression automatique : Choisissez combien de temps vos Codespaces arrêtés sont conservés, jusqu'à un maximum de 30 jours.

Reconnaître comment ajouter et configurer des conteneurs de développement

Vous pouvez configurer le conteneur de développement pour un dépôt afin que tout codespace créé pour ce dépôt vous donne un environnement de développement sur mesure, complet avec tous les outils et runtimes dont vous avez besoin pour travailler sur un projet spécifique.

Qu'est-ce que les conteneurs de développement ? Ce sont des conteneurs Docker qui sont spécifiquement configurés pour fournir un environnement de développement entièrement fonctionnel. Chaque fois que vous travaillez dans un codespace, vous utilisez un conteneur de développement sur une machine virtuelle.

Un fichier de conteneur de développement est un fichier JSON qui vous permet de personnaliser l'image par défaut qui exécute votre codespace, les paramètres de VS code, d'exécuter du code personnalisé, de transférer des ports et bien plus encore !

Le fichier devcontainer.json est attendu à la racine de votre dépôt de projet.

Identifier comment partager un lien profond vers un GitHub codespace

Vous pouvez utiliser ces URL pour lier à la page de création de codespace pour votre dépôt (remplacez le texte en majuscules) :

• Créer un codespace pour la branche par défaut du dépôt : https://codespaces.new/PROPRIÉTAIRE/NOM-DU-DÉPÔT
• Créer un codespace pour une branche spécifique du dépôt : https://codespaces.new/PROPRIÉTAIRE/NOM-DU-DÉPÔT/tree/NOM-DE-LA-BRANCHE
• Créer un codespace pour la branche de sujet d'une demande de tirage : https://codespaces.new/PROPRIÉTAIRE/NOM-DU-DÉPÔT/pull/PR-SHA

Expliquer comment utiliser l'éditeur github.dev et expliquer les différences entre l'éditeur github.dev et un GitHub Codespace

Domaine 5 : Gestion de projet

Gérez votre travail avec GitHub Projects

Décrire GitHub Projects

GitHub Projects est un outil de gestion de projet intégré dans GitHub. Il permet aux utilisateurs et aux équipes d'organiser et de prioriser le travail directement dans GitHub.

Voici ses principales fonctionnalités :

• Tableaux Kanban et Scrum : Similaires à Trello ou Jira, GitHub Projects permet aux utilisateurs de créer des tableaux pour gérer les tâches et les flux de travail. Les tâches sont représentées sous forme de cartes, qui peuvent être déplacées entre différentes colonnes représentant les étapes de progression (comme À faire, En cours, Terminé).
• Intégration avec les dépôts GitHub : Les cartes d'un projet peuvent être liées aux problèmes et aux demandes de tirage GitHub. Cette intégration étroite permet un suivi facile des tâches liées au code directement depuis le tableau de projet.
• Personnalisation : Les utilisateurs peuvent personnaliser les colonnes pour correspondre à leur flux de travail. Par exemple, un projet de développement logiciel pourrait avoir des colonnes pour Backlog, En cours, Revue de code, Test et Terminé.
• Automatisation : GitHub Projects peut automatiser les flux de travail. Par exemple, lorsqu'une demande de tirage est fusionnée, la carte de tâche associée peut automatiquement passer à la colonne Terminé.
• Outils de collaboration : Plusieurs membres de l'équipe peuvent travailler sur un projet, avec des modifications reflétées en temps réel. Cette collaboration s'étend au suivi des problèmes et des demandes de tirage, ce qui en fait un outil idéal pour les équipes de développement logiciel.
• Jalons et suivi des progrès : Les projets peuvent être liés à des jalons spécifiques, et les progrès peuvent être suivis via le tableau. Cela aide à visualiser l'avancement global d'un projet.
• Filtrer et rechercher : Les utilisateurs peuvent filtrer les cartes du tableau par étiquettes, assignés ou jalons, ce qui facilite la recherche de tâches ou de problèmes spécifiques.

Expliquer les options de mise en page pour les projets

• Vue de tableau (style Kanban) : Il s'agit de la mise en page la plus courante dans GitHub Projects. Elle présente les tâches sous forme de cartes disposées en colonnes. Chaque colonne représente une étape du flux de travail, comme "À faire", "En cours", "En revue", "Terminé", etc. Les cartes peuvent être facilement glissées et déposées d'une colonne à l'autre, reflétant la progression des tâches. Idéal pour visualiser le flux de tâches et la charge de travail d'un coup d'œil.
• Vue de liste : Affiche les tâches dans un format de liste simple. Chaque tâche ou problème est un élément de ligne, qui peut être coché ou mis à jour. Convient à ceux qui préfèrent une approche directe et linéaire de la gestion des tâches. Offre un moyen simple et direct de visualiser les tâches sans l'orientation spatiale d'un tableau.
• Vue de tableau : Cette mise en page représente les tâches dans un format de tableau ou de feuille de calcul. Permet une vue plus détaillée, montrant divers attributs (comme l'assigné, le statut, les étiquettes) en colonnes séparées. Utile pour les projets qui nécessitent une vue plus granulaire des tâches et de leurs métadonnées associées. Offre des capacités de tri et de filtrage puissantes.
• Vue de calendrier : Cette mise en page aligne les tâches avec des dates spécifiques, les affichant dans un format de calendrier. Idéal pour gérer les tâches avec des délais ou à des fins de planification. Aide à visualiser comment les tâches sont réparties dans le temps, facilitant ainsi la gestion des plannings et des délais.
• Mises en page personnalisées : GitHub Projects permet souvent la personnalisation de ces vues pour répondre aux besoins spécifiques des équipes. Les équipes peuvent créer un mélange de différentes vues ou adapter celles existantes pour correspondre à leur flux de travail.

Décrire les options de configuration pour les projets

• Personnalisation du flux de travail : Vous pouvez définir des colonnes personnalisées dans les tableaux Kanban ou Scrum, telles que "À faire", "En cours", "Revue" et "Terminé". Vous avez la possibilité de créer, renommer et réorganiser ces colonnes pour correspondre au flux de travail de votre équipe.
• Règles d'automatisation : Automatiser les tâches répétitives comme le déplacement des cartes entre les colonnes lorsque certains déclencheurs se produisent (par exemple, un problème est fermé ou une demande de tirage est fusionnée). Mettre en place des règles pour l'assignation automatique des problèmes ou des demandes à des membres spécifiques de l'équipe.
• Accès et permissions : Configurer qui peut voir, éditer ou gérer le projet. Options pour la visibilité publique ou la restriction de l'accès à certains membres de l'équipe.
• Intégration avec les éléments du dépôt : Lier les cartes du projet aux problèmes, demandes de tirage et jalons du dépôt. Utiliser les étiquettes, les assignés et autres fonctionnalités GitHub directement dans le projet.
• Configuration des cartes : Personnaliser les informations qui apparaissent sur les cartes du projet (comme les étiquettes des problèmes, les assignés, le statut de progression). Options pour ajouter des notes, des listes de contrôle ou des détails supplémentaires aux cartes.
• Suivi des jalons : Associer des parties du projet à des jalons spécifiques pour un meilleur suivi des progrès. Définir des délais et des échéanciers pour les phases du projet ou les tâches individuelles.
• Vues et filtres : Créer différentes vues telles que les vues Liste, Tableau ou Tableau, pour accommoder différents styles de gestion. Options de filtrage pour afficher les tâches par assigné, étiquette, jalon, etc. pour une navigation plus efficace.
• Notifications et mises à jour : Configurer les paramètres de notification pour les mises à jour du projet. S'abonner à des parties spécifiques d'un projet pour recevoir les mises à jour pertinentes.
• Rapports et analyses : Selon l'outil, vous pourriez avoir des options de rapport sur la progression du projet, comme des graphiques de burndown ou des rapports de progression. Afficher les analyses liées aux temps de résolution des problèmes, aux fusions de demandes de tirage, etc.
• Utilisation de modèles : Certains outils offrent des modèles de projet pour les flux de travail courants qui peuvent être utilisés comme point de départ.
• Intégrations externes : Intégrer avec des outils tiers pour des capacités de gestion de projet améliorées, comme le suivi du temps, des analyses améliorées, etc.

Expliquer la différence entre les projets et les projets classiques

GitHub dispose de deux versions de son outil de gestion de projet : "GitHub Projects" (souvent appelé les nouveaux GitHub Projects) et "GitHub Projects Classic."

GitHub Projects est un outil plus avancé et riche en fonctionnalités, répondant aux besoins complexes de gestion de projet et offrant une plus grande personnalisation et automatisation.

En revanche, GitHub Projects Classic est plus simple et convient aux équipes qui nécessitent un suivi de base des tâches et une gestion de projet sans avoir besoin d'une personnalisation extensive.

Expliquer l'utilisation des étiquettes

Vous pouvez gérer le travail en utilisant des étiquettes pour catégoriser les problèmes, les demandes de tirage et les discussions. Une fois qu'une étiquette existe, vous pouvez utiliser l'étiquette sur n'importe quel problème, demande de tirage ou discussion au sein de ce dépôt.

GitHub fournit les étiquettes par défaut suivantes dans chaque nouveau dépôt :

question |Indique qu'un problème, une demande de tirage ou une discussion a besoin de plus d'informations| wontfix |Indique que le travail ne continuera pas sur un problème, une demande de tirage ou une discussion|

Expliquer l'utilisation des jalons

Vous utilisez des jalons pour suivre les progrès sur un groupe de PR ou de problèmes dans un dépôt. Après avoir créé le jalon, vous l'associez aux problèmes et PR pertinents. Utilisez des jalons pour suivre les progrès, fixer des délais et prioriser le travail.

Décrire comment utiliser et créer des dépôts de modèles

Création d'un dépôt de modèle GitHub :

• Créer ou choisir un dépôt : Commencez avec un dépôt existant que vous souhaitez utiliser comme modèle, ou créez un nouveau dépôt pour servir à cette fin.
• Configurer comme dépôt de modèle :
  • Allez dans le dépôt, cliquez sur "Paramètres".
  • Dans la section "Général", trouvez la section "Dépôt de modèle".
  • Cochez la case étiquetée "Dépôt de modèle".

Utilisation d'un dépôt de modèle GitHub :

• Créer un nouveau dépôt à partir du modèle :
  • Naviguez jusqu'au dépôt de modèle sur GitHub.
  • Cliquez sur le bouton "Utiliser ce modèle", situé près du haut du dépôt.

Vous serez invité à créer un nouveau dépôt. Spécifiez le propriétaire, le nom, la description et la visibilité pour le nouveau dépôt.

• Personnaliser le nouveau dépôt :
  • Modifiez, ajoutez ou supprimez des fichiers selon les besoins pour répondre aux exigences spécifiques du nouveau projet. Mettez à jour le README.md et d'autres documentations pour refléter la nature du nouveau projet.

Expliquer comment créer, éditer et supprimer des réponses enregistrées

Les réponses enregistrées sont des réponses préformatées que vous pouvez utiliser pour répondre rapidement aux problèmes, aux demandes de tirage et aux discussions. Elles sont utiles pour les réponses courantes que vous vous trouvez à taper fréquemment.

Créer une réponse enregistrée :

• Cliquez sur votre photo de profil dans le coin supérieur droit de GitHub.
• Sélectionnez "Paramètres" dans le menu déroulant.
• Sur la page des paramètres, trouvez la section "Réponses enregistrées" dans la barre latérale.

• Dans le formulaire qui apparaît, entrez un titre pour votre réponse enregistrée dans le champ "Titre de la réponse". Entrez la réponse que vous souhaitez enregistrer dans le champ "Corps de la réponse". Cliquez sur le bouton "Ajouter une réponse enregistrée" pour l'enregistrer.

Éditer et supprimer une réponse :

• Localisez la réponse enregistrée que vous souhaitez éditer ou supprimer.
• Cliquez sur l'icône du crayon (Éditer) pour modifier, ou sur l'icône 'X' (Supprimer) à côté. (Attention : vous ne serez PAS invité à supprimer)

Décrire les avantages de l'utilisation d'une réponse enregistrée

Les réponses enregistrées vous permettent de créer une réponse réutilisable aux problèmes et aux demandes de tirage. Vous pouvez gagner du temps en créant une réponse enregistrée pour les réponses que vous utilisez le plus fréquemment.

Une fois que vous avez ajouté une réponse enregistrée, vous pouvez l'utiliser dans les problèmes, les demandes de tirage et les discussions. Les réponses enregistrées sont liées à votre compte personnel. Une fois qu'elles sont créées, vous pourrez les utiliser dans tous les dépôts et organisations.

Vous pouvez créer un maximum de 100 réponses enregistrées. Si vous avez atteint la limite maximale, vous pouvez supprimer les réponses enregistrées que vous n'utilisez plus ou modifier les réponses enregistrées existantes.

Vous pouvez également utiliser la réponse enregistrée fournie par GitHub "Problème dupliqué" pour marquer un problème comme dupliqué et le suivre avec un problème similaire.

Reconnaître comment ajouter des assignés aux problèmes et aux demandes de tirage

Vous pouvez assigner plusieurs personnes à chaque problème ou demande de tirage, y compris vous-même, toute personne ayant commenté le problème ou la demande de tirage, toute personne ayant des permissions d'écriture sur le dépôt, et les membres de l'organisation ayant des permissions de lecture sur le dépôt.

Les problèmes et les demandes de tirage dans les dépôts publics (et dans les dépôts privés pour un compte payant), peuvent avoir jusqu'à 10 personnes assignées.

• Dans le dépôt, cliquez sur Problèmes ou Demandes de tirage.
• Ouvrez le Problème ou la PR.
• Dans le menu de droite, cliquez sur Assignés et commencez à taper le nom de l'utilisateur à qui vous souhaitez l'assigner.

Expliquer comment utiliser les workflows de projet

Avec les workflows intégrés, votre projet peut prendre les problèmes ou les demandes de tirage nouvellement créés et les placer automatiquement dans votre Projet avec un statut À faire.

Pour activer l'automatisation, allez d'abord dans le coin supérieur droit de votre Projet et cliquez sur les trois points pour ouvrir le menu.

Ensuite, dans le menu, cliquez sur Workflows.

Dans la colonne de gauche, sous Workflows par défaut, sélectionnez Élément ajouté au projet.

Maintenant, au centre de la page, où il est écrit "Lorsque un élément est ajouté au projet", assurez-vous que les problèmes et les demandes de tirage sont sélectionnés.

En dessous, cliquez sur "Définir la valeur" et cliquez sur Statut:À faire.

Enfin, dans le coin droit de la page, cliquez sur 'éditer' et "enregistrer et activer le workflow".

Décrire les insights de projet

Les insights avec les projets vous permettent de visualiser, créer et personnaliser des graphiques qui utilisent les éléments ajoutés à votre projet comme données sources. Lorsque vous créez un graphique, vous définissez les filtres, le type de graphique, les informations affichées, et le graphique est disponible pour toute personne pouvant visualiser le projet.

Il existe 2 types de graphiques : Actuels et Historiques.

Vous pouvez créer des graphiques actuels pour visualiser les éléments de votre projet. Par exemple, vous pouvez créer des graphiques pour montrer combien d'éléments sont assignés à chaque individu, ou combien de problèmes sont assignés à chaque itération à venir.

Vous pouvez également utiliser des filtres pour manipuler les données utilisées pour construire votre graphique. Par exemple, vous pouvez créer un graphique montrant combien de travail à venir vous avez, mais limiter ces résultats à des étiquettes ou des assignés particuliers.

Les graphiques historiques sont actuellement disponibles en aperçu de fonctionnalité pour les organisations utilisant GitHub Team et sont généralement disponibles pour les organisations utilisant GitHub Enterprise Cloud.

Les graphiques historiques sont des graphiques basés sur le temps qui vous permettent de visualiser les tendances et les progrès de votre projet. Vous pouvez visualiser le nombre d'éléments, regroupés par statut et autres champs, au fil du temps. Le graphique "Burn up" par défaut montre l'état des éléments au fil du temps, vous permettant de visualiser les progrès et de repérer les schémas au fil du temps.

Domaine 6 : Vie privée, sécurité et administration

Authentification et sécurité

Expliquer comment sécuriser votre compte avec 2FA

Il existe deux méthodes d'authentification recommandées que vous pouvez mettre en œuvre lors de l'authentification des utilisateurs sur GitHub : SAML SSO et authentification multifactorielle, également connue sous le nom de 2FA.

Sécuriser votre compte GitHub avec l'authentification à deux facteurs (2FA) ajoute une couche supplémentaire de sécurité pour protéger votre compte contre les accès non autorisés.

Pour activer le 2FA :

• Connectez-vous à votre compte GitHub. Cliquez sur votre photo de profil dans le coin supérieur droit. Dans la section "Accès", cliquez sur "Mot de passe et authentification" :

• Dans la section "Authentification à deux facteurs" de la page, cliquez sur Activer l'authentification à deux facteurs.
• À partir de là, vous pouvez ajouter plusieurs options pour réduire vos chances de verrouillage de compte (et obtenir vos codes de récupération que vous devriez imprimer).

L'authentification SAML SSO est un processus utilisé pour vérifier l'identité et les informations d'identification d'un utilisateur auprès d'un fournisseur d'identité connu.

Si vous êtes dans un environnement d'entreprise, votre entreprise utilise probablement déjà cela. Si c'est le cas, vous pouvez lier votre IdP existant à GitHub pour la gestion de la connexion des utilisateurs.

Voici un aperçu du processus :

• Avant d'activer SAML SSO avec votre GitHub Enterprise, un administrateur doit connecter l'organisation GitHub à un IdP pris en charge. GitHub prend en charge SAML SSO avec les IdP qui utilisent la norme SAML 2.0 : AD FS, Microsoft Entra ID, Okta, OneLogin, PingOne et Shibboleth.
• Ensuite, lorsqu'un membre accède aux ressources au sein d'une organisation qui utilise SAML SSO, GitHub redirige le membre vers l'IdP pour s'authentifier.
• Après une authentification réussie, l'IdP redirige le membre vers GitHub, où les ressources sont accessibles. Même après avoir configuré SAML SSO, les membres de l'organisation GitHub continueront à être invités à se connecter à leurs comptes GitHub utilisateur.

Décrire les différentes permissions d'accès

Permissions de dépôt :

• Lecture : Permet aux utilisateurs de cloner le dépôt et de tirer les mises à jour. Ils peuvent voir les problèmes, les demandes de tirage, les wikis et les paramètres du projet. Idéal pour les utilisateurs qui doivent voir ou discuter du projet mais ne contribuent pas au code.
• Écriture : Inclut toutes les permissions de Lecture. De plus, les utilisateurs peuvent pousser des modifications au dépôt, fusionner des demandes de tirage et gérer les problèmes et les demandes de tirage. Convient aux contributeurs qui développent activement le projet.
• Maintenance : Inclut les permissions de Lecture et d'Écriture. Les utilisateurs peuvent gérer le dépôt sans accès aux actions sensibles ou destructrices. Les capacités incluent la gestion des versions et la gestion des paramètres du dépôt comme les collaborateurs et les webhooks.
• Admin : Contrôle total sur le dépôt. Peut changer les paramètres du dépôt, ajouter des collaborateurs, accéder aux paramètres sensibles comme les changements de visibilité du dépôt, et effectuer des actions destructrices telles que la suppression du dépôt ou le changement de sa visibilité. Destiné aux propriétaires du projet ou aux chefs d'équipe.

Permissions d'organisation :

En plus des permissions spécifiques au dépôt, les organisations GitHub ont leurs propres niveaux de permission :

• Propriétaire : Contrôle total sur l'organisation et ses dépôts et équipes. Peut ajouter/supprimer des membres, créer des équipes, ajouter des dépôts aux équipes et gérer les paramètres de facturation.

• Membre : Permissions de base au sein d'une organisation, y compris la création de nouveaux dépôts et équipes (selon les paramètres de l'organisation).

Permissions des équipes dans les organisations :

• Lecture, Écriture, Maintenance, Admin : Similaires aux permissions de dépôt mais appliquées au niveau de l'équipe au sein de l'organisation. Contrôler ce que les membres d'une équipe peuvent faire au sein des dépôts assignés à cette équipe.

Permissions de collaborateur :

• Pour les dépôts individuels, un utilisateur qui n'est pas membre de l'organisation peut être ajouté en tant que collaborateur et peut se voir accorder un accès en Lecture, Écriture ou Admin à un dépôt spécifique.

Expliquer les EMUs (Enterprise Managed Users)

Les EMUs sont utilisés pour gérer le cycle de vie et l'authentification des utilisateurs sur GitHub.com à partir d'un système de gestion d'identité externe (IdP). Vous pouvez fournir un accès à GitHub Enterprise Cloud aux personnes qui ont des identités et des appartenances à des groupes existants sur votre IdP.

• Rejoindre des équipes : Apporter une modification à l'un des groupes IdP composés d'EMUs peut amener vos EMUs à rejoindre automatiquement une nouvelle équipe dans GitHub.
• Retrait des équipes : Supprimer un groupe IdP d'une équipe dans l'organisation peut affecter l'appartenance à l'équipe GitHub. De plus, si ces EMUs ne sont pas membres d'une autre équipe dans votre organisation, le processus les supprimera automatiquement de l'organisation.
• Gestion de l'accès au dépôt : Vous ne pouvez pas gérer l'accès au dépôt pour les équipes de votre entreprise.
• EMUs ajoutés manuellement précédemment : Les utilisateurs ajoutés à vos groupes et équipes GitHub manuellement avant que vous ne commenciez à utiliser Enterprise Managed Users devront être supprimés et réajoutés.

Administration GitHub

Expliquer comment activer et désactiver les fonctionnalités

Dans les paramètres des dépôts, vous pouvez activer et désactiver les fonctionnalités suivantes : Wikis, Problèmes, Sponsorships, Discussions, Projets, et la capacité de préserver ce dépôt via le programme d'archivage GitHub

Reconnaître les niveaux de permission des dépôts

• Lecture : Permet aux utilisateurs de cloner le dépôt et de tirer les mises à jour. Ils peuvent voir les problèmes, les demandes de tirage, les wikis et les paramètres du projet. Idéal pour les utilisateurs qui doivent voir ou discuter du projet mais ne contribuent pas au code.
• Triage : Recommandé pour les contributeurs qui doivent gérer activement les problèmes et les demandes de tirage sans accès en écriture. Ce niveau pourrait être bon pour certains chefs de projet qui gèrent le suivi des problèmes mais ne font aucune modification.
• Écriture : Inclut toutes les permissions de Lecture. De plus, les utilisateurs peuvent pousser des modifications au dépôt, fusionner des demandes de tirage et gérer les problèmes et les demandes de tirage. Convient aux contributeurs qui développent activement le projet.
• Maintenance : Inclut les permissions d'Écriture. Les utilisateurs peuvent gérer le dépôt sans accès aux actions sensibles ou destructrices. Les capacités incluent la gestion des versions et la gestion des paramètres du dépôt comme les collaborateurs et les webhooks.
• Admin : Contrôle total sur le dépôt. Peut changer les paramètres du dépôt, ajouter des collaborateurs, accéder aux paramètres sensibles comme les changements de visibilité du dépôt, et effectuer des actions destructrices telles que la suppression du dépôt ou le changement de sa visibilité. Destiné aux propriétaires du projet ou aux chefs d'équipe.

Identifier les options de visibilité des dépôts

• Dépôts publics : Accessibles à tous. N'importe qui peut voir, cloner et contribuer à un dépôt public. Utilisés pour les projets open source où la collaboration et la transparence sont importantes.

• Dépôts privés : Restreints à des individus ou équipes spécifiques.

• Dépôts internes : Accessibles à tous les membres au sein d'une organisation mais pas aux personnes extérieures. Les dépôts internes sont le paramètre par défaut pour tous les nouveaux dépôts créés dans une organisation détenue par un compte d'entreprise.

Par défaut, les membres de l'entreprise peuvent forker un dépôt interne dans n'importe quelle organisation où l'utilisateur peut créer des dépôts.

Ils sont utiles pour les projets qui ne sont pas open source mais qui sont destinés à la collaboration au sein d'une entité plus large, comme une entreprise. Cela est ridiculement tenté d'être appelé "innersource".

Expliquer les options de paramétrage de la confidentialité des dépôts (protections de branche, codeowners, réviseurs requis)

• Protections de branche : Utilisées pour protéger les branches importantes. Définissent si les collaborateurs peuvent supprimer ou forcer le push vers la branche et définir les exigences pour tout push vers la branche :

Décrire les principales fonctionnalités et options de l'onglet Sécurité

Dans l'onglet sécurité, vous trouverez des politiques de sécurité qui vous permettent de spécifier comment signaler une vulnérabilité de sécurité dans votre projet en ajoutant un fichier SECURITY.md à votre dépôt.

Il existe également des avis de sécurité que vous pouvez utiliser pour discuter, corriger et publier des informations sur les vulnérabilités de sécurité dans votre dépôt.

Les alertes Dependabot vous notifient lorsque GitHub détecte que votre dépôt utilise une dépendance vulnérable ou un logiciel malveillant.

Et il y a aussi le balayage de code qui vous aide à trouver, trier et corriger les vulnérabilités et les erreurs dans votre code.

Définir les insights du dépôt

Les insights du dépôt GitHub fournissent une gamme de données analytiques et de visualisations sur l'activité et la santé d'un dépôt. Ces insights sont précieux pour les mainteneurs et les contributeurs de dépôt, car ils aident à suivre les progrès, la participation et l'état général du projet.

• Pulse : Fournit un résumé de l'activité dans le dépôt sur une période spécifique (quotidienne, hebdomadaire, mensuelle). Il inclut des informations sur les problèmes ouverts et fermés, les demandes de tirage fusionnées et les contributeurs qui ont été actifs pendant cette période.
• Contributeurs : Affiche le nombre de contributions (commits) de chaque contributeur au fil du temps.
• Communauté : Affiche l'activité de contribution aux Discussions, Problèmes et PR.
• Normes communautaires : Compare le dépôt aux normes communautaires recommandées.
• Trafic : Affiche le nombre de clones et de visiteurs au fil du temps. Affiche également les sites référents et le contenu populaire dans le dépôt.
• Commits : Visualise l'activité des commits au fil du temps.
• Fréquence du code : Affiche la fréquence des ajouts et des suppressions dans la base de code au fil du temps.
• Graphe des dépendances : Affiche les dépendances du dépôt et les projets qui en dépendent.
• Réseau : Chronologie des commits les plus récents dans ce dépôt et son réseau, classés par les plus récemment poussés. Le réseau du dépôt affiche les 100 forks les plus récemment poussés.
• Forks : Qui a forké le dépôt, soit sous forme d'arbre, soit sous forme de liste.

Expliquer comment gérer les collaborateurs

Pour ajouter des collaborateurs : Cliquez sur l'onglet "Paramètres" en haut de la page du dépôt. Cliquez sur "Collaborateurs". Cliquez sur le bouton "Ajouter des personnes".

• Entrez le nom d'utilisateur ou l'e-mail : Entrez le nom d'utilisateur ou l'adresse e-mail GitHub de la personne que vous souhaitez ajouter en tant que collaborateur.

• Définir les permissions : Choisissez le niveau de permission approprié (lecture, écriture ou admin).
• Envoyer l'invitation : Cliquez sur "Ajouter" ou "Envoyer l'invitation." L'utilisateur recevra alors une invitation à rejoindre le dépôt en tant que collaborateur.

Niveaux de permission

• Lecture : Peut cloner et voir le dépôt, ne peut pas pousser de modifications ou gérer les paramètres.
• Écriture : Peut cloner, pousser des modifications et gérer un ensemble limité de paramètres du dépôt.
• Admin : Accès complet au dépôt, y compris les paramètres et la suppression.

Gestion et révision des collaborateurs

• Révision des collaborateurs actuels : Dans la section "Gérer l'accès", vous pouvez voir une liste des collaborateurs actuels et leurs niveaux de permission.
• Changer les permissions : Pour changer les permissions d'un collaborateur, cliquez sur son nom et sélectionnez un niveau de permission différent.
• Supprimer un collaborateur : Pour supprimer un collaborateur, cliquez sur le bouton "Supprimer" à côté de son nom.

Demandes de collaborateur

• Approbation des demandes : Si quelqu'un demande l'accès à votre dépôt, vous recevrez une notification. Vous pouvez approuver ou refuser ces demandes dans la section "Gérer l'accès".

Bonnes pratiques

• Limiter l'accès admin : L'accès admin doit être limité à un petit groupe pour maintenir la sécurité.
• Révision régulière de l'accès : Passez régulièrement en revue qui a accès pour vous assurer que seuls les contributeurs actuels ont les permissions nécessaires.
• Utiliser des équipes pour les organisations : Pour les organisations GitHub, préférez gérer l'accès en utilisant des équipes plutôt que des collaborateurs individuels pour un contrôle d'accès plus facile et plus organisé.

Expliquer comment gérer les paramètres de l'organisation

Pour gérer les paramètres de l'organisation, cliquez sur votre profil :

Allez dans Organisations et choisissez quelle organisation (si vous en avez plusieurs) vous souhaitez gérer les paramètres :

À partir de là, vous pouvez gérer ces domaines clés (et plus) :

• Modifier les détails du profil comme le nom de l'organisation, l'e-mail, l'emplacement et la bio. Vous pouvez également télécharger un avatar d'organisation.
• Définir les permissions de base pour tous les membres (lecture, écriture, admin, aucun). Gérer les privilèges d'invitation (qui peut inviter des utilisateurs à l'organisation). Définir les permissions de création de dépôt (qui peut créer des dépôts).
• Facturation et plans : Voir le plan GitHub actuel et l'utilisation (nombre de collaborateurs, dépôts privés, etc.). Mettre à niveau ou rétrograder votre abonnement GitHub. Mettre à jour les informations de facturation et voir l'historique des paiements.
• Sécurité : Activer ou désactiver les exigences d'authentification à deux facteurs pour l'organisation. Gérer les paramètres de sécurité comme les autorités de certification SSH.
• Dépôts : Gérer les paramètres des dépôts de l'organisation. Mettre en œuvre des politiques de gestion des dépôts comme la visibilité des dépôts et les paramètres des tableaux de projet.
• Accès tiers : Contrôler quelles applications tierces peuvent accéder aux données de l'organisation. Définir des politiques pour l'accès aux applications OAuth.
• Gérer les paramètres pour GitHub Actions comme les actions autorisées, les environnements et les groupes de runners.

Décrire les membres, les équipes et les rôles dans une organisation GitHub

Les membres sont des utilisateurs GitHub individuels qui ont été ajoutés à une organisation. Les membres peuvent être des collaborateurs sur un ou plusieurs dépôts au sein de l'organisation et peuvent se voir accorder divers niveaux d'accès et de permissions en fonction de leur rôle au sein de l'organisation.

Types de membres :

• Propriétaires : Ont un accès administratif complet à l'organisation, y compris la capacité de gérer les paramètres des équipes et des membres, les informations de facturation, et peuvent supprimer l'organisation.
• Membres : Ont généralement un accès en lecture aux dépôts de l'organisation mais peuvent avoir des permissions plus spécifiques en fonction de l'appartenance à une équipe ou des paramètres spécifiques au dépôt.

Les équipes sont des groupes au sein d'une organisation GitHub, créés pour organiser les membres qui travaillent sur des projets similaires ou qui nécessitent des permissions similaires. Les équipes aident à structurer les membres de l'organisation, reflétant souvent la structure réelle de l'entreprise ou les équipes de projet.

Les équipes peuvent se voir attribuer des permissions d'accès spécifiques aux dépôts, ce qui facilite la gestion de grands groupes d'utilisateurs. Les équipes peuvent être mentionnées en utilisant @nom-de-l'équipe dans les discussions, les demandes de tirage et les problèmes, ce qui notifie tous les membres de l'équipe.

GitHub permet la création de sous-équipes au sein d'une équipe, permettant une hiérarchie qui peut refléter la structure interne d'une organisation.

Les rôles définissent les actions qu'un membre ou une équipe peut effectuer au sein d'une organisation et de ses dépôts.

• Membre : Membres réguliers de l'organisation, généralement avec un accès en lecture aux dépôts et des permissions spécifiques basées sur l'appartenance à une équipe ou des paramètres individuels.
• Modérateurs : Membres qui, en plus de leurs permissions en tant que membres, sont autorisés à bloquer et débloquer les contributeurs non-membres, à définir des limites d'interaction et à masquer les commentaires dans les dépôts publics détenus par l'organisation.
• Propriétaire : Peut gérer tous les aspects de l'organisation, y compris l'ajout/suppression de membres, la création d'équipes, la gestion des paramètres de facturation et la suppression de l'organisation.
• Gestionnaires de facturation : Utilisateurs qui peuvent gérer les paramètres de facturation de votre organisation, tels que les informations de paiement.
• Gestionnaires de sécurité : Un rôle au niveau de l'organisation que les propriétaires peuvent attribuer à n'importe quelle équipe dans l'organisation. Il donne à chaque membre de l'équipe des permissions pour voir les alertes de sécurité et gérer les paramètres de sécurité du code dans votre organisation, ainsi que des permissions de lecture pour tous les dépôts de l'organisation.

Domaine 7 : Avantages de la communauté GitHub

Décrire l'open source

L'open source est un terme utilisé pour décrire un logiciel pour lequel le code source original est rendu librement accessible et peut être redistribué et modifié par quiconque.

Il est basé sur le principe du développement collaboratif, où des développeurs du monde entier contribuent à l'amélioration et à l'avancement du logiciel. Ce modèle promeut la transparence, car le code est disponible pour un examen public, conduisant à une fiabilité et une sécurité accrues.

Les logiciels open source sont généralement publiés sous des licences qui permettent la modification et la redistribution, telles que la licence publique générale GNU ou la licence MIT.

Cette approche favorise non seulement l'innovation et la résolution créative de problèmes, mais forme également une communauté de développeurs et d'utilisateurs qui soutiennent et font évoluer le logiciel au fil du temps.

L'open source est devenu fondamental dans le monde de la technologie, avec des exemples notables incluant le système d'exploitation Linux, le serveur web Apache et le navigateur Mozilla Firefox.

Décrire les avantages de la communauté open source

Il y a de nombreux avantages à faire partie de la communauté open source et à contribuer à des projets open source. En voici quelques-uns :

• Collaboration : L'open source favorise un environnement collaboratif où des développeurs du monde entier apportent leur expertise.

• Transparence et sécurité : Les projets open source produisent souvent des logiciels de haute qualité. La transparence du code source permet une révision continue par les pairs, conduisant à des logiciels plus robustes, sécurisés et exempts d'erreurs.

• Décentralisation : Puisque la communauté développe le code - et qu'aucune personne ou entreprise ne possède ce code - l'open source est une forme de développement logiciel intrinsèquement décentralisée qui comporte moins de silos, de goulots d'étranglement et de barrières à l'entrée.

• Flexibilité et personnalisation : Les utilisateurs ont la liberté de personnaliser les logiciels open source pour répondre à leurs besoins spécifiques. Cette flexibilité peut être un avantage significatif par rapport aux logiciels propriétaires, qui peuvent imposer des limitations d'utilisation.

• Économies de coûts : Le code source OSS est gratuit, ce qui entraîne un coût total de possession inférieur par rapport aux solutions propriétaires ou fermées.

• Apprentissage et développement des compétences : Les projets open source offrent une excellente opportunité aux développeurs d'apprendre à partir du code source, de contribuer à des projets réels et de construire un portfolio. Cela peut être particulièrement bénéfique pour les nouveaux développeurs cherchant à améliorer leurs compétences.

• Support communautaire : De nombreux projets open source ont souvent des communautés actives. Ces communautés offrent un support via des forums, des listes de diffusion ou des canaux de chat, ce qui peut être inestimable pour la résolution de problèmes et l'apprentissage.

• Éviter le verrouillage par le fournisseur : L'utilisation de logiciels open source aide à éviter le verrouillage par le fournisseur, où les utilisateurs dépendent d'un fournisseur pour les mises à jour et le support. L'open source offre plus de contrôle et d'indépendance.

Décrire GitHub Sponsors

GitHub Sponsors permet à la communauté des développeurs de soutenir financièrement les personnes et organisations qui conçoivent, construisent et maintiennent les projets open source dont ils dépendent, directement sur GitHub.

GitHub Sponsors ne facture aucun frais pour les parrainages provenant de comptes personnels, donc 100 % de ces parrainages vont au développeur ou à l'organisation parrainée.

Alors que vous envisagez où trouver des contributeurs open source à parrainer, envisagez de commencer ici.

Décrire comment GitHub fait avancer les projets open source

La plateforme GitHub elle-même possède de nombreuses fonctionnalités et avantages qui aident à faire avancer les causes des projets open source :

• Engagement communautaire : GitHub promeut la construction de communautés autour des projets. Les utilisateurs peuvent étoiler et forker des dépôts, montrant leur soutien et créant leurs propres versions d'un projet. Les discussions et les wikis au sein des dépôts fournissent des espaces pour l'interaction communautaire, le partage des connaissances et une documentation extensive.
• Découvrabilité : La fonctionnalité de recherche et la section des projets tendances facilitent la découverte de projets open source par les développeurs. Cette visibilité aide à attirer de nouveaux contributeurs et utilisateurs, élargissant ainsi la communauté du projet.
• Guides et éducation open source : GitHub propose des guides et des ressources éducatives pour aider les nouveaux contributeurs à comprendre la philosophie open source et comment contribuer efficacement, favorisant ainsi la croissance de la communauté open source.
• GitHub Marketplace : Le marketplace offre une multitude d'outils et d'applications qui améliorent et simplifient le développement de projets. Beaucoup de ces outils sont adaptés pour soutenir les flux de travail de développement open source.
• Financement et parrainage : GitHub Sponsors permet à la communauté de soutenir financièrement les mainteneurs de projets open source.

Identifier comment suivre les personnes (recevoir des notifications, découvrir des projets dans leur communauté)

• Allez simplement sur leur page GitHub et cliquez sur "Suivre" : 😂

Expliquer comment suivre les organisations (recevoir des notifications sur leur activité)

• Allez simplement sur leur page GitHub et cliquez sur "Suivre" :

Décrire le GitHub Marketplace et son objectif

Marketplace est une plateforme au sein de GitHub conçue pour fournir une suite complète d'outils qui étendent et améliorent la fonctionnalité des workflows de développement et de DevOps de GitHub.

Vous pouvez lister des outils gratuits et payants pour les développeurs à utiliser dans GitHub Marketplace.

Il offre aux développeurs deux types d'outils : GitHub Actions et Apps, et chaque outil nécessite des étapes différentes pour l'ajouter à GitHub Marketplace.

Décrire comment appliquer les avantages de l'open source

Décrire InnerSource

InnerSource est un concept qui prend les principes et les pratiques du développement de logiciels open source et les applique au sein des limites d'une organisation.

C'est une approche de collaboration et de développement de logiciels qui encourage l'ouverture et le partage au-delà des frontières des équipes internes.

Identifier les différences entre InnerSource et open source

InnerSource et open source sont similaires en philosophie mais diffèrent principalement par leur portée et leur mise en œuvre.

Considérez InnerSource comme un effort open source contraint par une organisation. L'organisation permettra aux employés internes (et aux collaborateurs externes) de visualiser/forker/surveiller les dépôts d'autres équipes, mais ils ne sont pas disponibles en dehors de l'entreprise.

Décrire le forking

Le forking est l'action de créer une copie personnelle du projet de quelqu'un d'autre.

Décrire les composants d'un dépôt découvrable

Pour rendre votre dépôt découvrable, il y a diverses choses que vous voudrez considérer.

Tout d'abord, un README bien conçu est crucial. Il doit fournir un aperçu du projet et de son objectif. Il doit également guider les utilisateurs sur la manière d'installer, de configurer et d'utiliser le logiciel.

Vous devez également ajouter des sujets à votre dépôt liés à l'objectif prévu de votre projet, au domaine, aux groupes d'affinité ou à d'autres qualités importantes. Pour parcourir les sujets les plus utilisés, allez sur topics.

Vous devez également avoir un fichier de licence. Inclure une licence open source est vital. Il informe les utilisateurs de ce qu'ils peuvent et ne peuvent pas faire avec votre code. Les licences courantes incluent MIT, GPL et Apache. GitHub a créé ce guide pour vous aider à décider quelle licence choisir.

Ensuite, vous devez avoir un fichier CONTRIBUTING, qui doit détailler comment les autres peuvent contribuer à votre projet. Il peut inclure des informations sur les types de contributions que vous recherchez, le processus de soumission des modifications et les normes de codage ou les tests que les contributeurs doivent suivre.

Les modèles de problèmes et les modèles de demandes de tirage sont également très utiles. Les modèles guident les contributeurs lorsqu'ils ouvrent des problèmes ou des demandes de tirage.

Vous devez également utiliser des fonctionnalités GitHub utiles comme les jalons, les étiquettes et les projets pour organiser les problèmes et les demandes de tirage. Cela aide à gérer le projet mais montre également aux contributeurs potentiels que le projet est activement maintenu.

Décrire quand utiliser les modèles de problèmes

Les modèles sont utiles lorsque vous souhaitez fournir des directives pour l'ouverture de problèmes tout en permettant aux contributeurs de spécifier le contenu de leurs problèmes. Si vous souhaitez que les contributeurs fournissent des informations spécifiques et structurées lorsqu'ils ouvrent des problèmes, les formulaires de problèmes aident à garantir que vous recevez les informations souhaitées.

Décrire quand utiliser les modèles de demande de tirage

Lorsque vous ajoutez un modèle de demande de tirage à votre dépôt, les contributeurs du projet verront automatiquement le contenu du modèle dans le corps de la demande de tirage.

Vous devez créer des modèles sur la branche par défaut du dépôt. Les modèles créés dans d'autres branches ne sont pas disponibles pour que les collaborateurs les utilisent.

Vous pouvez stocker votre modèle de demande de tirage dans le répertoire racine visible du dépôt, le dossier docs ou le répertoire caché .github.

Les noms de fichiers des modèles de demande de tirage ne sont pas sensibles à la casse et peuvent avoir une extension telle que .md ou .txt.

Prochaines étapes et conclusion

D'accord ! Si vous êtes arrivé jusqu'ici, alors vous devriez être prêt à passer l'examen ! 🥰

Si vous souhaitez vous inscrire immédiatement, voici où vous pouvez le faire

Si vous souhaitez pratiquer un peu plus, consultez GitHub Skills qui vous donnera beaucoup plus d'expérience pratique avec les différents processus.

Si vous avez parcouru cet article (comment avez-vous pu) et souhaitez une ressource directement de Microsoft, le Chemin d'apprentissage des fondations GitHub est excellent, mais il manque certaines sections de domaine.

En conclusion, adopter les pratiques modernes de GitHub est essentiel pour travailler dans le paysage informatique d'aujourd'hui. Ces pratiques favorisent un environnement plus organisé et productif pour les projets open source et privés.

Que ce soit pour les développeurs individuels ou les grandes équipes, tirer parti de GitHub ouvre la voie à des entreprises de développement logiciel plus innovantes, collaboratives et réussies.