Si vous utilisez GitHub et préférez la ligne de commande comme moi pour tout faire sans aucune complication sur l'interface graphique, vous avez peut-être remarqué comment GitHub a commencé à utiliser son outil pas si nouveau appelé « gh ». J'ai décidé de tenter le coup, car cela avait l'air prometteur après tout. Et personnellement, je l’ai beaucoup aimé – à tel point que j’ai eu envie d’en faire un article !
Avant de commencer, je dois expliquer plusieurs termes que j'utiliserai dans cet article.
« GH » signifie «GitHub”. C'est également de là que vient le nom de l'outil, il ne peut donc pas être confondu avec Git lui-même. Pour expliquer ce qu'il fait en général, vous pouvez créer, créer, supprimer, parcourir les dépôts ; créer des demandes de tirage ; et beaucoup plus. Si vous ne trouvez pas une fonctionnalité mais que vous ne souhaitez pas non plus quitter le terminal, il fournit également un navigateur textuel vous permettant de parcourir les pages de GitHub.
« CLI » signifie «Ccommande LINE Iinterface ». Ce terminal (ou sous Windows, invite de commande) en fait partie. S'il y a un « CLI » ajouté à côté du nom d'une application (« Git CLI » pour cet article), cela signifie que l'application s'exécute uniquement via le terminal. Et « Git CLI » dans ce contexte est, eh bien, le Git que nous connaissons. Comme la commande avec laquelle nous effectuons des validations ou des rebases.
GUI signifie «Graphique Uvoir Interface » et c’est l’interface sur laquelle nous « naviguons ». Mieux dit, un environnement de bureau en général est une interface graphique.
Une « clé API » est une sorte de chaîne/fichier secret que vous utilisez pour vous authentifier auprès des services. Attention, il contourne l'authentification à 2 facteurs, etc. lorsque vous vous authentifiez avec lui. Assurez-vous donc de les garder en sécurité et dans un endroit hors de portée par d’autres moyens.
Tout d’abord, quel est cet outil ? Comment gère-t-il les opérations que nous effectuerions via Git CLI ?
« gh » peut être considéré comme open source (Code source) wrapper utilisant Git CLI lui-même et les API GitHub pour faire avancer les choses. En fait, vous pouvez même transmettre des paramètres aux commandes Git qu’il utilise ! J'y reviendrai plus tard.
Installation et configuration
Gardez à l'esprit que je vais procéder à l'installation en utilisant Termux. Mais la procédure devrait être à peu près la même que celle que vous pourriez avoir sur une distribution basée sur Debian – Ubuntu l'a sur ses dépôts officiels par exemple. Pour Windows, eh bien, vous avez besoin de CygWin ou de WSL, je suppose. ¯\_(ツ)_/¯
# Installons d'abord l'outil. Installez également Git car c'est le backend # pour gh. $ pkg install git gh -y # Ensuite, avant tout, nous devons nous authentifier. Cela enregistrera une # nouvelle clé API dans la base de données de l'outil afin que vous n'ayez pas besoin de vous authentifier # à nouveau. Si vous avez déjà défini GITHUB_TOKEN, cela ne fonctionnera pas, alors désactivez-le d'abord. :) $ gh connexion authentifiée
Maintenant, avant de continuer ici, je dois souligner plusieurs choses.
- Tout d'abord, ne choisissez pas « GitHub Enterprise Server » si vous n'avez pas une sorte de GitHub auto-hébergé.
- D'autre part, utilisez SSH au lieu de HTTPS si votre clé publique est ajoutée sur votre compte GitHub. Si vous perdez la clé API, vous ne perdrez au moins pas votre clé SSH, cela peut donc également constituer une bonne méthode de secours.
- Troisièmement, choisissez de vous connecter avec le navigateur seulement si vous n'avez pas de clé API sous la main ! En réalité, cela n’aurait aucun sens d’avoir une autre clé alors que vous en avez déjà une.
Une fois que vous avez terminé la configuration, parlons-en à Git CLI.
$ gh auth setup-git
Cela effectuera les configurations Git CLI nécessaires au cas où vos réflexes feraient irruption et vous obligeraient à utiliser Git au lieu de GH.
Quelques commandes de base
Maintenant que vous avez configuré GH, laissez-moi vous apprendre plusieurs commandes de base sous forme d'histoire.
Tout d'abord, disons que vous souhaitez créer une pull request vers mon dépôt de manifestes local. Vous voulez d'abord le débourser.
$ gh repo fork windowz414/platform_manifest ! windowz414/platform_manifest existe déjà ? Souhaitez-vous cloner le fork ? Oui Clonage dans 'platform_manifest'... distant : Énumération des objets : 136, terminé. à distance : Comptage d'objets : 100 % (136/136), terminé. à distance : compression des objets : 100 % (81/81), terminé. distant : Total 136 (delta 46), réutilisé 89 (delta 12), pack-réutilisé 0 Objets de réception : 100 % (136/136), 30.70 Ko | 166.00 KiB/s, c'est fait. Résolution des deltas : 100 % (46/46), terminé. Mise à jour en amont depuis github.com:windowz414/platform_manifest * [nouvelle branche] amyrom/rosie -> amont/amyrom/rosie * [nouvelle branche] aosp-eleven -> amont/aosp-eleven * [nouvelle branche] aosp-ten -> amont/aosp-ten * [nouvelle branche] arrow-11.0 -> amont/arrow-11.0 * [nouvelle branche] cm-14.1 -> amont/cm-14.1 * [nouvelle branche] dot11 -> amont/dot11 * [nouvelle branche ] e/os/v1-nougat -> amont/e/os/v1-nougat * [nouvelle branche] fluid-11 -> amont/fluid-11 * [nouvelle branche] fox_7.1 -> amont/fox_7.1 * [nouvelle branche] hentai-rika -> amont/hentai-rika * [nouvelle branche] ion-pie -> amont/ion-pie * [nouvelle branche] lignée-15.1 -> amont/lineage-15.1 * [nouvelle branche] lignée -17.1 -> amont/lineage-17.1 * [nouvelle branche] lineage-18.1 -> amont/lineage-18.1 * [nouvelle branche] lineage-18.1_teos -> amont/lineage-18.1_teos * [nouvelle branche] lineage-19.0 - > amont/lineage-19.0 * [nouvelle branche] main -> amont/main * [nouvelle branche] mkn-mr1 -> amont/mkn-mr1 * [nouvelle branche] vengeanceos-r11.0 -> amont/revengeos-r11.0. 1 * [nouvelle branche] stellar-S1 -> amont/stellar-S11 * [nouvelle branche] teos-n -> amont/teos-n * [nouvelle branche] weebprojekt-11 -> amont/weebprojekt-XNUMX ✓ Fork cloné
Supposons ensuite que vous ayez une organisation distincte pour vos expériences appelée « wz414-labs », que vous n'avez pas encore créée sur votre profil personnel et que vous souhaitez y cloner, puis ouvrir une pull request à la place. Vous souhaitez également cloner la branche « cm-14.1 » afin de ne plus avoir besoin de refaire git-checkout.
$ gh repo fork windowz414/platform_manifest --org="wz414-labs" -- --branch="cm-14.1" ✓ Création d'un fork wz414-labs/platform_manifest ? Souhaitez-vous cloner le fork ? Oui Clonage dans 'platform_manifest'... distant : Énumération des objets : 136, terminé. à distance : Comptage d'objets : 100 % (136/136), terminé. à distance : compression des objets : 100 % (81/81), terminé. distant : Total 136 (delta 46), réutilisé 89 (delta 12), pack-réutilisé 0 Objets de réception : 100 % (136/136), 30.70 Ko | 120.00 KiB/s, c'est fait. Résolution des deltas : 100 % (46/46), terminé. Mise à jour en amont depuis github.com:windowz414/platform_manifest * [nouvelle branche] amyrom/rosie -> amont/amyrom/rosie * [nouvelle branche] aosp-eleven -> amont/aosp-eleven * [nouvelle branche] aosp-ten -> amont/aosp-ten * [nouvelle branche] arrow-11.0 -> amont/arrow-11.0 * [nouvelle branche] cm-14.1 -> amont/cm-14.1 * [nouvelle branche] dot11 -> amont/dot11 * [nouvelle branche ] e/os/v1-nougat -> amont/e/os/v1-nougat * [nouvelle branche] fluid-11 -> amont/fluid-11 * [nouvelle branche] fox_7.1 -> amont/fox_7.1 * [nouvelle branche] hentai-rika -> amont/hentai-rika * [nouvelle branche] ion-pie -> amont/ion-pie * [nouvelle branche] lignée-15.1 -> amont/lineage-15.1 * [nouvelle branche] lignée -17.1 -> amont/lineage-17.1 * [nouvelle branche] lineage-18.1 -> amont/lineage-18.1 * [nouvelle branche] lineage-18.1_teos -> amont/lineage-18.1_teos * [nouvelle branche] lineage-19.0 - > amont/lineage-19.0 * [nouvelle branche] main -> amont/main * [nouvelle branche] mkn-mr1 -> amont/mkn-mr1 * [nouvelle branche] vengeanceos-r11.0 -> amont/revengeos-r11.0. 1 * [nouvelle branche] stellar-S1 -> amont/stellar-S11 * [nouvelle branche] teos-n -> amont/teos-n * [nouvelle branche] weebprojekt-11 -> amont/weebprojekt-XNUMX ✓ Fork cloné
Vous voyez, je n'ai pas utilisé « -b cm-14.1 » et j'ai plutôt utilisé l'argument long. À la date de cet article, le 16 février 2022, GH a un bug qui ne transmet pas correctement les arguments courts à Git CLI et doit donc être fait sous forme d'arguments longs à la place.
Une fois que cela est fait, vous êtes régulièrement entré dans le dossier, avez effectué vos modifications, validé puis poussé, et êtes prêt à faire une pull request. Pour cela, il vous suffit d'un simple
$ gh pr create --branch="cm-14.1" Création d'une pull request pour wz414-labs:cm-14.1 dans cm-14.1 dans windowz414/platform_manifest ? Titre teos : Passer à Git-Polycule ? Corps ? Et après? Soumettre https://github.com/windowz414/platform_manifest/pull/1
Si vous n'ajoutez pas « –branch=cm-14.1 », vous créeriez un PR vers la branche « principale », ce qui bien sûr causera des problèmes si elle n'est pas gérée correctement.
Et maintenant, je dois fusionner ce PR, n'est-ce pas ? Je clone donc d'abord le dépôt, je passe à la succursale assignée et je liste d'abord les PR.
# Clonage d'abord. $ git clone https://github.com/windowz414/platform_manifest Clonage dans 'platform_manifest'... distant : Énumération des objets : 136, terminé. à distance : Comptage d'objets : 100 % (136/136), terminé. à distance : compression des objets : 100 % (81/81), terminé. distant : Total 136 (delta 46), réutilisé 89 (delta 12), pack-réutilisé 0 Objets de réception : 100 % (136/136), 30.70 Ko | 137.00 KiB/s, c'est fait. Résolution des deltas : 100 % (46/46), terminé. # Puis vérification à la succursale. $ git checkout cm-14.1 branche 'cm-14.1' configurée pour suivre 'origin/cm-14.1'. Passé à une nouvelle branche 'cm-14.1' # Et maintenant la liste des PR. $ gh pr list Affichage de 1 sur 1 demande d'extraction ouverte dans windowz414/platform_manifest #1 teos : passage à Git-Polycule wz414-labs:cm-14.1
Maintenant que nous voyons qu'il existe un PR pour changer la télécommande en « Git-Polycule », voyons ce qui a changé avec cela.
$ gh pr diff 1 diff --git a/teos.xml b/teos.xml index b145fc0..3aadeb6 100644 --- a/teos.xml +++ b/teos.xml @@ -2,7 +2,7, 414 @@
Cela semble prometteur ! Il est temps de fusionner !
$ gh pr fusionner 1 ? Quelle méthode de fusion souhaitez-vous utiliser ? Rebaser et fusionner ? Et après? Soumettre ✓ Pull request n°1 rebasée et fusionnée (teos : changement vers Git-Polycule)
Maintenant que je l'ai fusionné, vous pouvez supprimer votre fork.
$ gh repo delete --confirm wz414-labs/platform_manifest ✓ Dépôt supprimé wz414-labs/platform_manifest
Vous voyez que le dépôt a été directement supprimé sans demande de confirmation car j'y ai passé le paramètre « –confirm ». Si vous ne le réussissez pas, vous obtiendrez ceci :
$ gh repo supprimer windowz414/systemd ? Tapez windowz414/systemd pour confirmer la suppression :
Et vous devrez taper le nom complet du dépôt. Perte de temps…
Résumé
En termes simples, `gh` est un wrapper Git CLI/Curl assez simplifié unifiant les opérations Git simples et les éléments de l'API GitHub sous le même toit. Comment l’utilisez-vous ? Cela vous semble-t-il prometteur comme à moi ? J'ai hâte d'avoir de vos nouvelles!
