Le CLI GitButler : Scott Chacon, GitButler

GGitButler
Computing/SoftwareSmall Business/StartupsInternet Technology

Transcript

00:00:00Bienvenue. Je vais vous faire une démo rapide de GitButler, au cas où vous ne connaissiez pas.
00:00:07C'est un nouvel outil de gestion de version sur lequel on travaille depuis deux ans. On a piqué pas mal de trucs à JJ.
00:00:10Alors si vous utilisez Jujutsu, on vous a emprunté beaucoup de choses.
00:00:16Bref, pour ceux qui ne connaissent pas GitButler, c'est un outil de gestion de version.
00:00:19C'est principalement une interface graphique,
00:00:21mais on développe une interface en ligne de commande (CLI), et je voulais vous montrer ça puisque vous travaillez tous sur Git.
00:00:26Git a une CLI intéressante, et...
00:00:29On a aussi repris certains concepts de Jujutsu.
00:00:33Mais il y a aussi des nouveautés que je trouve vraiment sympas.
00:00:36Je voulais vous les montrer pour avoir vos retours et des idées sur ce qui serait génial d'ajouter.
00:00:40Donc voilà, je vais passer ces points en revue.
00:00:43Alors...
00:00:46Il y a plusieurs choses. L'outil en ligne de commande s'appelle "but".
00:00:49Comme je raconte souvent des blagues de papa, je trouve ça plutôt approprié.
00:00:52On peut lancer "but status". C'est un peu comme un journal court (short log).
00:00:57Si vous avez utilisé Sapling ou Jujutsu et que vous regardez le log,
00:01:00on affiche les fichiers modifiés sur le disque
00:01:05dans votre répertoire de travail par rapport à la branche cible.
00:01:08Mais on affiche aussi les commits que vous avez, d'accord ?
00:01:11On peut aussi faire "but status -F", et ça montre les fichiers modifiés dans chaque commit.
00:01:18Si vous utilisez l'interface graphique de GitButler, vous pouvez voir vos "lanes" (couloirs) et tout ça.
00:01:23Mais GitButler permet de faire plein de choses cool que Git ne peut pas faire, comme ce type de log court.
00:01:29Mais...
00:01:30Et, vous savez,
00:01:32on a un log général qui indique si les commits sont locaux ou non. C'est similaire à un log court
00:01:39dans d'autres outils. Et on peut créer de nouvelles branches.
00:01:40Si je fais un "status", je vois que... là, je travaille sur un clone de Twitter.
00:01:44J'ai plusieurs branches, l'une empilée sur l'autre.
00:01:50C'est quelque chose que Git peut faire si vous utilisez "update-ref",
00:01:52qui réécrit vos références lors d'un rebase par exemple.
00:01:56Mais chez nous, c'est plus naturel.
00:02:00On met à jour vos références automatiquement, et si vous changez des trucs, le rebase le suivra.
00:02:03Mais on peut aussi faire
00:02:09des branches parallèles. On peut avoir plus d'une branche appliquée à la fois. Ce que je vais faire ici...
00:02:11C'est créer une nouvelle branche.
00:02:23Je relance la commande, et j'ai cette nouvelle branche qui est parallèle aux autres sur lesquelles je bosse.
00:02:26Et ce que je peux faire, c'est aller dans cette branche et commencer à assigner ou commiter des choses.
00:02:33On va voir ça juste après.
00:02:39L'autre truc cool, c'est qu'on a plusieurs zones de transit (staging areas).
00:02:41Chaque pile possède sa propre zone de transit, donc vous pouvez utiliser
00:02:45"rub". C'est la commande. Vous pouvez dire "rub [code]" pour ce fichier ici, et l'envoyer dans "ZA".
00:02:51Ça l'assigne à cette zone de transit spécifique. Si je veux assigner quelque chose à celle-là,
00:02:58ça vous donne ces petits codes courts.
00:03:04On peut dire : "Ok, celui-là va ici, et celui-là va là".
00:03:12Et si je commite, je peux les envoyer dans l'une ou l'autre de ces branches en même temps.
00:03:15Regardons ça. On voit que c'est assigné ici, donc je peux faire :
00:03:21"but commit -o".
00:03:27Et ça le valide ici.
00:03:30Désormais, ce fichier est dans ce commit. Et le plus beau, c'est que ça reste du Git pur.
00:03:40Je peux dire...
00:03:48Voilà, ça crée un vrai commit Git. Je peux pousser la branche, etc.
00:03:50Mais...
00:03:57Oui, je peux assigner à des branches spécifiques, ou juste faire "but commit" pour tout ce qui n'est pas assigné vers la cible.
00:03:59Je peux choisir dans quelle branche je veux commiter les nouveautés.
00:04:07On a inventé ce terme : "rubbing" (frictionner/frotter).
00:04:11J'en ai parlé à Caleb, qui a bu toute la nuit et qui n'est pas là.
00:04:14S'il arrive, on devrait tous se lever et l'applaudir.
00:04:18C'est lui qui a trouvé ce terme, "rubbing", qui consiste à prendre deux choses, les frotter ensemble pour voir ce qu'il en sort.
00:04:21Si vous avez joué à Minecraft, avec la table de craft,
00:04:28vous connaissez le concept.
00:04:32On prend ceci et cela, on les assemble et ça crée quelque chose de nouveau et de plus intéressant.
00:04:34Il y a plein de choses qu'on peut faire avec la CLI pour "frotter" des éléments via "but rub".
00:04:38Je vais vous montrer quelques exemples. On peut assigner des choses, comme je l'ai montré,
00:04:45un fichier non validé ou modifié vers une branche. Mais on peut aussi "désassigner".
00:04:52Il y a ce mode spécial "00".
00:05:01Où je peux dire "but rub"...
00:05:05...tout ce commit, par exemple,
00:05:07vers "00".
00:05:11Et ça annule le commit. En gros, ça fait un "reset soft"
00:05:17de ce commit. Je peux aussi amender des choses en faisant "rub le r"...
00:05:24...y.
00:05:27RV... j'ai besoin de mes lunettes, je me fais vieux.
00:05:32SW... qui est... pardon, vers
00:05:3511W. Essayons celui-là.
00:05:38C'est IW ? Merci.
00:05:41Oups.
00:05:44C'est bien un I ?
00:05:48Pardon.
00:06:02Et...
00:06:04...ça le valide là-dedans. Je peux faire...
00:06:10...rub I.
00:06:14Je peux annuler des commits.
00:06:16Je peux aussi écraser (squash) des commits. Si je veux fusionner ce commit et celui-là, je fais "but rub J e GE".
00:06:22Et ça fusionne les commits. Je peux annuler, déplacer des trucs...
00:06:25En gros, tout ce que vous imaginez qu'il se passerait en combinant deux choses.
00:06:32Ça le fera. Si vous combinez un élément avec les changements non assignés, ça l'annulera, tout simplement.
00:06:37Je ne sais plus si ça marche déjà parfaitement...
00:06:42Mais on peut aussi déplacer des fichiers.
00:06:48J 8 2...
00:06:53Et...
00:07:02...ça prend le fichier de ce commit,
00:07:03l'enlève de ce commit et le déplace dans le commit juste en dessous.
00:07:07Ce qui est intéressant, ce n'est pas que c'est impossible avec Git, c'est que c'est difficile.
00:07:11Annuler des commits individuels ou déplacer des fichiers entre commits, ou amender un fichier dans un commit situé trois niveaux plus bas...
00:07:19C'est faisable dans Git, par exemple avec un
00:07:27commit temporaire de type "fixup" et un "autosquash".
00:07:31Mais c'est plus agréable de pouvoir juste "frotter" les éléments pour déplacer le contenu là où on veut,
00:07:34tout en ayant plusieurs branches simultanément.
00:07:40On peut aussi diviser des commits très facilement. On a aussi la commande "but new".
00:07:43Si je veux faire
00:07:51"but new H e",
00:07:54ça va...
00:07:56...créer un nouveau commit vide à cet endroit.
00:07:59C'est le style Jujutsu : créer un commit vide
00:08:03et ensuite y injecter (rub) des fichiers. Je pourrais dire :
00:08:08"Prends ce fichier".
00:08:12Zéro.
00:08:15Je prends...
00:08:23...ça déplace ce fichier dans le nouveau commit. Ensuite je peux faire "describe".
00:08:29C'était quoi ? X u c.
00:08:32Comment pourrais-je...
00:08:45"Status -F", status files. Ça montre les fichiers dans chaque commit au lieu de...
00:08:56Le "but status" classique montre juste les commits,
00:09:02mais "but status -F" montre les fichiers à l'intérieur, donc on peut les déplacer par friction (rubbing).
00:09:04Il y a donc "new" et "describe". Enfin, il y a le marquage, là aussi très proche de JJ.
00:09:11Pour ceux qui utilisent Jujutsu, on peut marquer un commit comme cible.
00:09:16Tout ce que l'outil verra ensuite sera placé dans ce commit. On peut marquer...
00:09:21C'est assez intéressant. Je peux faire
00:09:25"but new -M" ou utiliser "but mark ZA".
00:09:29Ça va marquer ça, et vous voyez qu'il a déjà pris ce qui n'était pas validé pour le mettre
00:09:33dans ce couloir (lane).
00:09:35Ensuite je peux valider des trucs, ou marquer
00:09:42un commit spécifique.
00:09:44Oh, c'est une branche, pardon.
00:09:47Ça marque un commit précis, et si je fais un "echo new"
00:09:56vers un fichier, il l'intègre et le valide automatiquement dans ce commit.
00:09:58C'est intéressant parce qu'on a une pile de branches avec plusieurs commits, et tout ce que je fais maintenant
00:10:07vient amender automatiquement un commit situé trois rangs plus bas dans la pile.
00:10:15C'est un peu comme JJ : vous faites "jj new", vous travaillez,
00:10:21et ça amende automatiquement le dernier commit.
00:10:26Sauf qu'ici, vous pouvez marquer n'importe quel commit,
00:10:31continuer à bosser dessus, puis le démarquer quand vous avez fini.
00:10:33C'est ça.
00:10:36Bref, voilà une partie des trucs amusants sur lesquels on travaille.
00:10:41Je trouve ça vraiment plaisant à utiliser.
00:10:44L'autre chose qu'on a aussi reprise de JJ, c'est l'oplog (journal des opérations).
00:10:48C'est quelque chose qu'on a depuis longtemps.
00:10:52Dans l'interface GitButler, il y a un onglet qui liste toutes les opérations effectuées.
00:10:56Chaque fois que je lance une commande, ça crée
00:10:59un historique des opérations. Je peux voir tout ce que GitButler a fait et revenir à n'importe quel état via "restore" ou...
00:11:03..."undo".
00:11:06Si je l'écris correctement, "undo" annule l'opération et remet mon répertoire de travail et mon statut
00:11:12exactement comme avant. Ou je peux faire
00:11:13"restore"
00:11:14vers n'importe lequel de ces hashs (SHA).
00:11:20Oups.
00:11:22Et...
00:11:24...ça réinitialise mon répertoire, mes branches et tout le reste à l'état précédent.
00:11:26C'est pratique pour une démo car je peux créer un scénario
00:11:29qui fonctionne bien, puis restaurer l'état initial pour recommencer la présentation.
00:11:33Mais c'est surtout utile pour se dire : "En fait, je ne voulais pas faire ça" ou "Je suis tombé sur un conflit".
00:11:38On annule, et on continue de travailler.
00:11:44Voilà, c'est tout. Ah, un dernier truc : toutes les commandes ont une sortie JSON. On peut faire "but -J"
00:11:50ou "--json" avec n'importe quelle commande pour obtenir les mêmes données en format JSON.
00:11:54Pour scripter des trucs, c'est bien plus propre que de parser la sortie "porcelain" de Git.
00:11:58On peut passer ça dans "jq" pour trouver une entrée spécifique
00:12:06et rendre l'automatisation de la CLI beaucoup plus simple.
00:12:11Voilà, c'est tout. Merci beaucoup.
00:12:15on peut simplement l'importer ou le passer dans jq pour trouver une entrée spécifique ou quelque chose comme ça, et
00:12:21pouvoir ainsi scripter la CLI de manière un peu plus élégante.
00:12:24Voilà, c'est tout. Merci beaucoup.

Key Takeaway

GitButler CLI introduit une approche fluide et concurrente de la gestion de versions, permettant de manipuler le contenu des commits et des branches avec une flexibilité bien supérieure à celle du Git traditionnel.

Highlights

Présentation de l'interface en ligne de commande (CLI) de GitButler

Timeline

Introduction et philosophie de GitButler

Scott Chacon introduit GitButler comme un nouvel outil de gestion de version en développement depuis deux ans. Bien qu'il soit principalement connu pour son interface graphique, l'accent est mis ici sur la nouvelle interface en ligne de commande (CLI). Le conférencier admet ouvertement avoir emprunté des concepts à d'autres outils modernes comme Jujutsu (JJ) pour améliorer l'expérience Git. L'objectif de cette présentation est de recueillir des retours sur ces nouvelles fonctionnalités auprès de la communauté des développeurs. Cette section établit le contexte d'un outil qui cherche à simplifier les flux de travail complexes.

La commande "but" et le statut visuel

L'outil CLI est officiellement nommé "but", un choix humoristique assumé par Chacon. La commande "but status" fonctionne comme un journal court amélioré, affichant les fichiers modifiés par rapport à la branche cible tout en listant les commits existants. Une option "-F" permet de visualiser précisément quels fichiers se trouvent dans chaque commit, offrant une clarté immédiate sur l'état du répertoire. Contrairement à Git, GitButler met à jour les références de manière plus naturelle, facilitant les opérations comme le rebase. Cette approche visuelle aide le développeur à mieux comprendre la structure de son travail en cours.

Branches parallèles et zones de transit multiples

L'une des fonctionnalités phares présentées est la capacité de travailler sur plusieurs branches en parallèle dans le même répertoire de travail. Chaque branche possède sa propre zone de transit (staging area) identifiée par des codes courts uniques. L'utilisateur peut assigner des modifications à une branche spécifique en utilisant ces codes, permettant de séparer les tâches sans changer de contexte. Scott démontre comment valider des fichiers dans différentes branches simultanément avec la commande "but commit -o". Ce système repose toujours sur du Git pur, garantissant la compatibilité avec les flux de travail standards tout en offrant une flexibilité accrue.

Le concept de "Rubbing" (Friction)

Chacon introduit le terme "rubbing", inspiré de la table de craft de Minecraft, pour décrire la fusion d'éléments. La commande "but rub" permet de prendre deux entités, comme un fichier et un commit, et de les combiner pour créer quelque chose de nouveau. Cette méthode facilite le "soft reset" de commits individuels ou le déplacement de fichiers entre différents commits dans la pile. Bien que ces actions soient possibles dans Git via des commandes complexes comme "fixup" ou "autosquash", GitButler les rend triviales et intuitives. Le "rubbing" devient ainsi l'outil principal pour réorganiser l'historique de manière dynamique et sans friction.

Gestion avancée des commits et marquage

La présentation explore ensuite les commandes "but new" et "but describe" pour manipuler la structure des commits. Inspiré de Jujutsu, l'outil permet de créer des commits vides puis d'y injecter du contenu ultérieurement via le système de friction. Une fonctionnalité puissante appelée "mark" permet de cibler un commit spécifique dans la pile pour que toutes les modifications ultérieures y soient automatiquement intégrées. Cela permet de travailler sur une modification située plusieurs niveaux plus bas dans l'historique sans interrompre le flux actuel. Une fois le travail terminé, l'utilisateur peut simplement démarquer le commit pour revenir à un état normal.

Journal des opérations, restauration et sortie JSON

Pour conclure, Scott présente l'oplog (journal des opérations), qui enregistre chaque action effectuée avec GitButler. Cette fonctionnalité permet d'utiliser la commande "undo" pour annuler une erreur ou "restore" pour revenir à un état précis via un identifiant SHA. C'est un filet de sécurité crucial qui permet d'expérimenter sans crainte de corrompre le travail en cours. Enfin, l'auteur souligne que toutes les commandes peuvent générer une sortie JSON via l'option "-J". Cela rend l'outil extrêmement puissant pour les développeurs souhaitant créer des scripts d'automatisation propres sans avoir à analyser du texte brut.

Community Posts

View all posts