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 :
- Open source, libre et communs : contribuer ne nécessite pas de développer
- Apprenez à utiliser Git : les bases pour l'évolution d'un document
- Git remote : comment héberger vos documents et codes source sur un serveur
- Git : comment travailler avec plusieurs remotes
- Fork et pull request : la participation open source par l'exemple
- GitHub CLI 1.0 est disponible : comment l'installer et l'utiliser
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.
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) :
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.
Commentaires (17)
#1
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
#2
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.
#2.1
Ils détaillent leur position ici
#2.2
Je n’avais pas vu cette FAQ, merci pour l’info c’est plus clair
#3
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é.
#3.1
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.
#4
C’est vrai.
Ç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.
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.
#5
Très chouette article. J’ai juste une récrimination sur le paragraphe suivant :
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, …).
#6
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.
Quelle est la différence avec Gitlab ? ou Bitbucket ?
EEE c’est valable que parce qu’il y a le démon Microsoft ?
#6.1
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.
#7
Oui, surtout que rien n’indique que ça va dans ce sens. Et une fois de plus, c’est un outil open source, en licence MIT. Si jamais ça va dans un sens que la communauté ne veut pas… Mais ils n’ont de toutes façons même pas intérêt à ça. Compléter Git leur suffit.
Oui mais comme dit, ce n’est qu’une grille de lecture. Et on est ici dans un tuto sur un outil, pas dans une analyse stratégique. Ce n’est pas mentionné parce que ce n’est pas le sujet.
Et à mon avis la grille de lecture EEE est assez datée. Là aussi, MS a montré qu’il avait compris que son intérêt était dans une cohabitation avec l’OSS en sachant l’utiliser, le renforcer, mais ne pas le systématiser. Et ils sont plus forts que jamais sans avoir à chercher à tuer l’OSS.
A mon avis, on a bien plus à craindre des rapprochements nombreux et peu discret avec Canonical que de la sortie d’une CLI pour GitHub.
Je l’ai déjà dit mais la recherche d’une opposition constante GitLab/GitHub me fatigue. Les deux sont des sociétés privées de droit US. L’une produit son service en OSS, pas l’autre, soit. Mais ce sont des différentes stratégiques, pas celui de la petite asso contre le gros méchant.
On parle des deux services (encore récemment des évolutions de GitLab). Chacun est libre de ses préférences. Ne cherchez pas à tout ramener à une opposition entre deux services. Sur le fond, si le fait d’être un superset de Git est la force de GitHub. Historiquement et encore actuellement.
Le fait que GitLab fasse un produit similaire n’enlève rien à ce fait. Pas plus que ça n’empêche GitHub d’avoir d’autres avantages et ses défauts
#7.1
Ok, je comprends la volonté de proposer un tuto sans s’embarquer dans ce genre de questionnements. Quand à savoir si MS est dans une stratégie EEE, je suis plus méfiant que toi mais on va dire wait and see…
Pour rester dans le thème des tutos git, est-ce que tu envisagerais de tester sourcehut ? C’est une forge avec une approche assez différente de github/gitlab/gitea, et accessoirement des partis pris assez forts (interface web légère et rapide, sans js, complètement FLOSS sans “version entreprise”…).
#7.2
Je regarderai, mais ça semble surtout différent sur le modèle éco plutôt que les fonctionnalités, mais ça peut être intéressant, merci de la proposition
#8
Ils auraient pu en faire un (/des) plugin git. L’intention de complementarité aurait été beaucoup plus claire je trouve.
#9
Sans doute mais tu casses l’aspect simple/tout-en-un que tu cherches avec ce genre d’outil. Puis bon, c’est OSS/MIT, chacun est libre d’en faire un plugin git s’il le souhaite
(mais ça doit déjà exister pour certains éléments, sans doute).
#10
Perso je trouve cette méthode plus cohérente et autonome pour pouvoir utiliser les fonctionnalités purement GitHub (Issues, PR, etc) dans le cadre de process automatisés. C’est pour ça que j’avais bien aimé hub justement.
#11
Les Actions et le runner de Github s’améliorent mais sont encore à la traine par rapport à Gitlab CI/CD. Par contre, j’expérimente actuellement 2 cours de programmation où on a passé tous les travaux pratiques sous Github Classroom et c’est un grand succès: vraiment pratique pour tout automatiser les tests grâce aux actions et facile d’accès car les étudiants en informatique connaissent déjà Github.