Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !

GitHub CLI 1.0 est disponible : comment l'installer et l'utiliser

En ligne de commandes
GitHub CLI 1.0 est disponible : comment l'installer et l'utiliser

Depuis des années, GitHub est l'une des plateformes mettant le plus à l'honneur Git et ses possibilités. Elle le complète par ses fonctionnalités et les outils mis à disposition des développeurs. Sa CLI 1.0 est désormais disponible, mais qu'apporte-t-elle ?

Git est un outil de gestion de versions comme il en existait d'autres avant lui : Bazaar, Mercurial ou encore SVN. Il permet de gérer l'évolution de fichiers et documents de manière efficace. Il est principalement utilisé dans le cadre du développement de logiciels libres, mais peut aussi trouver son intérêt pour de la documentation, la loi, etc.

Git, un succès distribué

Outre le fait qu'il ait été pensé par Linus Torvalds pour le développement du noyau Linux dès 2005, l'un de ses principaux atouts était sa conception distribuée, ne nécessitant pas de serveur central. Assez ironiquement, il doit en partie son succès à celui de la plateforme GitHub, rachetée par Microsoft en juin 2018.

Permettant à chacun d'héberger gratuitement les données des projets open source ou non, elle proposait de faire de même en équipe contre un abonnement payant. Un modèle qui a évolué depuis. Mais GitHub est surtout un service bien pensé, complet, pouvant être vu par certains aspects comme un client Git en ligne, survitaminé.

Il n'est bien sûr pas seul, avec des concurrents comme GitLab. Gérée par une société privée américaine, cette plateforme se distingue par la publication de son code source. Chacun peut ainsi monter son propre GitLab sur un serveur, un NAS, etc. C'est ce que fait Framasoft avec Framagit.

GitHub se distingue particulièrement dans l'étendue de son écosystème et de ses outils qui viennent renforcer Git. C'est le cas de son interface CLI, qui vient de passer en version 1.0.

Notre dossier sur la maîtrise de Git et de ses plateformes :

GitHub : un superset de Git

La principale force de GitHub est aussi, d'une certaine manière, son principal défaut : elle va bien plus loin que ce que propose Git. Outre la consultation de fichiers et leurs versions, on peut y publier de la documentation, un wiki, un site statique, gérer des discussions autour du projet, les remontées d'erreurs et leur correction, les pull-requests, des processus d'intégration et de déploiement continus, héberger les différentes releases de son application, etc.

Son importance est devenue telle qu'il s'agit presque d'un réseau social pour développeurs, chacun y peaufinant son profil comme on le fait avec un CV sur LinkedIn (qui appartient aussi à Microsoft).

Certains services sont plus spécifiques, comme les Gists, des snippets que l'on peut facilement partager et qui sont eux aussi « versionnés ». Ils ne sont pas gérés sous forme de dépôt comme dans le fonctionnement classique de Git. Ils ne peuvent donc pas être utilisés avec son client en ligne de commandes ou autres. Il faut une intégration propre à GitHub, aucun standard n'étant défini pour la gestion de telles portions de code et leur partage en ligne.

On trouve ainsi des clients pour des environnements de développement comme Atom, Notepad++ ou Visual Studio Code. Les développeurs apprécient aussi de pouvoir gérer de tels modules via la ligne de commande ou des scripts. Là aussi il existe différents outils exploitant les API de GitHub. Mais jusqu'à maintenant, aucun officiel.

C'est pour cela que le travail sur GitHub CLI (Command Line Interface) a commencé il y a quelques mois.

GitHub CLI

Un client multiplateforme pour terminal

L'idée est de permettre de profiter des possibilités de GitHub depuis un simple terminal, comme pour Git. Il devient ainsi possible d'automatiser simplement certaines tâches, sans avoir à interagir avec une API.

Il fonctionne aussi bien pour les comptes GitHub.com que ceux de la version Enterprise Server. Disponible pour Linux, macOS et Windows, il s'installe facilement, notamment via différents gestionnaires de paquets. Il est open source, sous licence MIT. Tous les détails sont donnés par ici.

Notez que même si ce n'est pas mentionné, il peut être installé via winget.

La procédure est simple et rapide. Bien entendu, pour profiter de l'ensemble des fonctionnalités de l'outil, il faudra que Git soit installé et configuré sur votre machine. Si vous êtes utilisateur de GitHub, c'est sans doute votre cas.

Une configuration rapide, un outil déjà complet

L'outil s'utilise avec l'exécutable gh, un nom volontairement court comme git. La première étape à suivre est la connexion à votre compte GitHub. Elle peut passer par le partage d'un jeton de sécurité placé en variable d'environnement (GITHUB_TOKEN) ou votre navigateur. Nous avons opté pour la seconde méthode :

gh auth login

Un code de deux fois quatre caractères alphanumériques vous sera donné et une fenêtre du navigateur ouverte. Une fois connecté sur GitHub, vous devrez entrer le code pour que la session soit initiée dans votre terminal. Après avoir choisi le protocole de connexion (HTTPS ou SSH), GitHub CLI sera exploitable.

Par exemple, pour obtenir la liste des Gists de votre compte (gh gist list) :

  • GitHub CLI Configuration
  • GitHub CLI Configuration
  • GitHub CLI Configuration
  • GitHub CLI Configuration

Par défaut, les dix plus récents sont affichés. Vous pouvez modifier ce nombre, n'afficher que ceux publics ou privés. Pour savoir comment faire, il est possible d'afficher l'aide, disponible pour chaque (sous-)commande :

gh gist list --help

Via GitHub CLI, vous pouvez interagir avec différentes sections du site : issue, pull-requests (pr), release ou encore repo (les dépôts), donc créer un projet, le cloner/forker ou simplement le voir. Certaines actions seront ainsi redondantes avec Git, mais fonctionnant de manière simplifiée. Par exemple, pour cloner Kimetrak :

gh clone davlgd/kimetrak

L'URL complète n'est pas nécessaire, il suffit de préciser le nom d'utilisateur et du dépôt GitHub. Rien ne vient par contre remplacer tout ce qui touche au cœur du workflow Git et qui n'est pas spécifique à GitHub, c'est bien normal. Les deux outils doivent se complèter, pas s'opposer.

La finition de l'ensemble est plutôt réussie. Les interactions avec l'utilisateur claires et bien gérées, des icônes rendent le tout agréable à l'œil, même si cela déplaira sans doute à certains puristes. Les possibilités offertes sont nombreuses, même si l'intégration à GitHub pourrait aller plus loin dans de futures versions.

Alias, API et compagnie

Par exemple, la création d'un Gist peut se faire depuis un fichier ou la sortie STDIN via une commande pipe. Ils sont privés par défaut, mais peuvent directement être déclarés comme publics, avec une description. L'édition utilise l'outil par défaut du système et peut concerner un fichier en particulier, etc.

Ceux qui veulent aller plus loin peuvent créer des alias. Pour simplifier par exemple le fait de lister 50 gists exclusivement publics :

gh alias set g50 "gist list --limit 50 --public"

Il vous suffira ensuite de taper :

gh g50 

Et le tour est joué ! Vous pouvez à tout moment voir la liste des alias et en supprimer. Il est aussi possible d'utiliser GitHub CLI pour effectuer des appels API simplifiés. La documentation complète est disponible par ici.

17 commentaires
Avatar de Perfect Slayer Abonné
Avatar de Perfect SlayerPerfect Slayer- 28/09/20 à 16:55:50

Un mot sur ce que deviennent les autres initiatives de CLI pour GitHub ?
Genre hub de GitHub lui-même : https://github.com/github/hub

Avatar de SebGF Abonné
Avatar de SebGFSebGF- 28/09/20 à 17:37:30
Perfect Slayer

Vu que les deux outils ont plus ou moins la même finalité (enrobage de commandes Git + utilisation de fonctions de Github) m'est avis qu'ils finiront par fusionner à terme.

Nous utilisons hub sur certains projets, très pratique pour proposer de la PR automatiquement. Dans notre cas, c'est principalement pour supprimer des ressources inutilisées du genre templates de déploiement obsolètes ou inventaires Ansible d'environnements de tests supprimés.

Avatar de David_L Équipe
Avatar de David_LDavid_L- 28/09/20 à 20:22:28
SebGF

Ils détaillent leur position ici

Avatar de deltadelta Abonné
Avatar de deltadeltadeltadelta- 29/09/20 à 07:50:45

Je trouve un peu dommage que nxi se contente de faire de la promotion pour github, alors qu'il y pourrait y avoir une réflexion critique sur la façon dont la plateforme façonne les pratiques de développement, depuis sa position centrale.

Les actions de github prennent beaucoup de sens si on les lit sous le prisme de la stratégie "Embrace, Extend, Extinguish" classiquement mise en œuvre pour constituer des silos fermés à partir d'écosystèmes ouverts. Github a d'abord été un outil s'intégrant avec git, puis a étendu ses fonctionnalités pour se rendre comparativement plus avantageux (au prix de la centralisation de ce qui est au départ conçu pour un usage décentralisé). La mise en place de la CLI se situe pour moi dans la à la troisième phase, soit le remplacement effectif de l'outil d'origine ouvert par l'outil centralisé.

Avatar de David_L Équipe
Avatar de David_LDavid_L- 29/09/20 à 07:54:56
deltadelta

On peut être critique des pratiques d'un service ou de la centralisation dans les mains de MS mais parler d'un service et de ses possibilités. Je sais que ça en défrise certains pour qui on ne devrait parler que d'open source (mais bon MS en fait massivement désormais). Mais c'est ainsi.

Pour GH, il en faut pas oublier que son côté "superset" de git ne date pas de MS. Il a fait le succès de git en bonne partie. Le fait qu'il aille plus loin aussi (GitLFS, PR en ligne, issues, etc.). Pour la façon dont tu perçois la CLI, elle est erronée à mon sens puisque comme dit les deux outils sont complémentaires.

Bien entendu cela peut évoluer à l'avenir, on surveillera ça aussi. Mais réagir comme tu le fais en partant du principe que comme c'est MS, c'est le mal et ça veut tout annihiler à son profit, ce n'est pas un job de journaliste, mais celui d'un utilisateur qui défend un camp plus que l'autre.

Avatar de SebGF Abonné
Avatar de SebGFSebGF- 29/09/20 à 08:09:48
David_L

Je n'avais pas vu cette FAQ, merci pour l'info c'est plus clair :yes:

Avatar de deltadelta Abonné
Avatar de deltadeltadeltadelta- 29/09/20 à 08:12:17

David_L a écrit :

Pour GH, il en faut pas oublier que son côté "superset" de git ne date pas de MS. Il a fait le succès de git en bonne partie. Le fait qu'il aille plus loin aussi (GitLFS, PR en ligne, issues, etc.).

C'est vrai.

Pour la façon dont tu perçois la CLI, elle est erronée à mon sens puisque comme dit les deux outils sont complémentaires.

Ça se discute. C'est peut-être prématuré à ce stade de le voir comme une tentative de remplacement, mais ça a le potentiel de faire pied dans la porte.

Bien entendu cela peut évoluer à l'avenir, on surveillera ça aussi. Mais réagir comme tu le fais en partant du principe que comme c'est MS, c'est le mal et ça veut tout annihiler à son profit, ce n'est pas un job de journaliste, mais celui d'un utilisateur qui défend un camp plus que l'autre.

Je crois que tu caricatures un peu mes propos (ou bien j'ai échoué à faire transparaître la nuance). Je ne dis pas que NXI devrait prendre position pour dénoncer les plans du vilain MS. Ce que je dis c'est que la grille de lecture selon laquelle ils appliquent la stratégie "EEE" existe, qu'elle est cohérente avec ce qu'on observe même si ce n'est pas la seule interprétation possible, et qu'à ce titre c'est dommage de ne pas la mentionner, sans forcément prendre parti pour.

Autrement dit, il y a un côté ambivalent que vous ne présentez pas, et je trouve ça dommage.

Édité par deltadelta le 29/09/2020 à 08:12
Avatar de Vieux_Coyote Abonné
Avatar de Vieux_CoyoteVieux_Coyote- 29/09/20 à 08:36:45

Très chouette article. J'ai juste une récrimination sur le paragraphe suivant :

La principale force de GitHub est aussi, d'une certaine manière, son principal défaut : elle va bien plus loin que ce que propose Git. Outre la consultation de fichiers et leurs versions, on peut y publier de la documentation, un wiki, un site statique, gérer des discussions autour du projet, les remontées d'erreurs et leur correction, les pull-requests, des processus d'intégration et de déploiement continus, héberger les différentes releases de son application, etc.

GitLab le fait aussi : ce n'est donc pas la principale force de Github. De mon point de vue, si Github est autant utilisé aujourd'hui (par rapport à Gitlab par ex.), c'est pour son côté "social" et "friendly" : son interface est vraiment agréable. Cependant, je trouve les Runner de Gitlab vraiment performants et personnalisables à souhait et, sauf erreur de ma part, il n'y avait pas d'équivalent Github à part utiliser un service tiers (Travis, ...).

Avatar de wpayen Abonné
Avatar de wpayenwpayen- 29/09/20 à 09:10:13

GitLab le fait aussi : ce n'est donc pas la principale force de Github. De mon point de vue, si Github est autant utilisé aujourd'hui (par rapport à Gitlab par ex.), c'est pour son côté "social" et "friendly" : son interface est vraiment agréable. Cependant, je trouve les Runner de Gitlab vraiment performants et personnalisables à souhait et, sauf erreur de ma part, il n'y avait pas d'équivalent Github à part utiliser un service tiers (Travis, ...).

GitHub runner dans Actions ?
Il faut aussi voir qu'à terme, ils vont récupérer dans Action tout le travail de Azure DevOps avec ses pipeline.

deltadelta a écrit :

Je trouve un peu dommage que nxi se contente de faire de la promotion pour github, alors qu'il y pourrait y avoir une réflexion critique sur la façon dont la plateforme façonne les pratiques de développement, depuis sa position centrale.

Les actions de github prennent beaucoup de sens si on les lit sous le prisme de la stratégie "Embrace, Extend, Extinguish" classiquement mise en œuvre pour constituer des silos fermés à partir d'écosystèmes ouverts. Github a d'abord été un outil s'intégrant avec git, puis a étendu ses fonctionnalités pour se rendre comparativement plus avantageux (au prix de la centralisation de ce qui est au départ conçu pour un usage décentralisé). La mise en place de la CLI se situe pour moi dans la à la troisième phase, soit le remplacement effectif de l'outil d'origine ouvert par l'outil centralisé.

Quelle est la différence avec Gitlab ? ou Bitbucket ?

EEE c'est valable que parce qu'il y a le démon Microsoft ?

Avatar de deltadelta Abonné
Avatar de deltadeltadeltadelta- 29/09/20 à 09:28:58
wpayen

La différence c'est simplement que les deux autres ne sont pas en mesure de faire bouger un écosystème entier à eux seuls. Github domine largement le paysage.

Il n'est plus possible de commenter cette actualité.
Page 1 / 2