Présentation de la démo produit GitButler (Été 2025)

GGitButler
Computing/SoftwareSmall Business/StartupsInternet Technology

Transcript

00:00:00Salut tout le monde, ici Scott, le PDG de GitButler.
00:00:02Aujourd'hui, je vais passer en revue quelques fonctionnalités sympas de GitButler
00:00:05et vous donner un aperçu général de ce que ce client Git peut faire.
00:00:07J'ai un projet d'exemple ici : un clone de Twitter, ou X. Je l'appelle Y.
00:00:12Je vais ajouter quelques modifications déjà prêtes et nous allons voir
00:00:16comment créer des commits, des branches, des branches parallèles et
00:00:20des branches empilées (stacked). Si je modifie des fichiers, vous verrez
00:00:25quelque chose de similaire à un "git status" listant les fichiers modifiés
00:00:30dans votre répertoire de travail. On fait quoi avec ? On les commite comment ?
00:00:34Ici, on peut les inspecter : le CSS, la barre latérale, l'index...
00:00:39Ce que je veux, c'est créer une nouvelle branche et y commiter ces changements.
00:00:45Il y a plusieurs façons de faire. Je peux cliquer sur "Commit to new branch"
00:00:49ou créer explicitement une nouvelle branche ici, une branche indépendante
00:00:54plutôt que dépendante. On verra l'empilement (stacking) dans un instant.
00:00:57On lui donne un nom, on crée la branche, et plusieurs options s'offrent à nous.
00:01:03On peut simplement commiter. Par exemple, ce fichier application.css,
00:01:08soit en le faisant glisser dans la colonne pour créer un commit, soit ici.
00:01:15On peut écrire un court message ici ou l'agrandir pour rédiger
00:01:19un message de commit plus détaillé. Restons simples pour l'instant.
00:01:27Je peux aussi choisir ce qui va dans ce commit. J'ai trois fichiers sur le côté.
00:01:34Je peux exclure un fichier entier, ou même sélectionner des lignes précises.
00:01:39Mais commitons tout pour l'instant. Ou plutôt, faisons deux commits séparés.
00:01:44Pas de barre latérale ici : je fais d'abord "front-end fixes"
00:01:48puis un autre commit "sidebar fixes". J'ai maintenant deux commits sur cette branche.
00:01:55Étant un peu paresseux, je vais utiliser Claude pour faire le travail à ma place.
00:01:59Je vais changer le thème du bleu au rouge, puis nous ajouterons une branche
00:02:04séparée pour cela. Voilà, c'est fait. Voici à quoi ressemblait le site avant :
00:02:09un petit air de Twitter. Si j'applique les modifs, j'ai maintenant un beau thème rouge,
00:02:14et mes changements front-end sont faits. Ce sont des branches indépendantes.
00:02:18Si je retire (unapply) les correctifs front-end, c'est toujours rouge.
00:02:25Voilà ce que j'ai fait. Je peux les remettre. Et maintenant c'est parti.
00:02:34Pareil, si j'enlève le thème rouge, il disparaît. Remettons-le.
00:02:43Nous avons donc deux branches distinctes. L'avantage, c'est que si je les
00:02:48pousse sur GitHub, les changements sont séparés mais appliqués simultanément.
00:02:52C'est comme des branches Git, sauf qu'on peut travailler sur plusieurs à la fois.
00:02:57Si je continue à travailler sur la barre latérale, ça apparaîtra ici.
00:03:04Je peux faire glisser l'élément ici pour amender (amend) le commit existant,
00:03:10ou en créer un nouveau sur cette branche. Ces deux branches sont parallèles.
00:03:14Voyons une autre méthode. Imaginons que le thème rouge
00:03:18dépende des changements faits dans le front-end.
00:03:24Je voudrais merger le front-end avant de m'occuper du rouge, ou tout ensemble.
00:03:29Annulons ce commit (uncommit), et faisons-en une branche empilée (stacked).
00:03:37On annule le commit et on retire la pile. Créons une branche dépendante.
00:03:42On clique sur créer une branche, puis on ajoute une branche dépendante.
00:03:47Ou alors : créer une branche dépendante ici et ajouter les correctifs front-end.
00:03:51Appelons-la "sc_red_theme". On voit maintenant que ces branches sont empilées.
00:03:58Je peux commiter ceci ici. Avec les branches empilées, pousser vers GitHub
00:04:06est très simple. Si l'intégration GitHub est active, on peut aussi
00:04:11créer une Pull Request. Si je crée une PR pour le thème rouge ici,
00:04:16comme c'est une branche empilée, GitButler ajoutera un pied de page à la PR
00:04:20indiquant que cette branche dépend d'une autre branche cible.
00:04:25Il faudra soit tout merger ensemble, soit le front-end avant le thème rouge.
00:04:30C'est une gestion très propre. En regardant la PR, elle lie les deux éléments
00:04:34de la pile : ceci est la partie 2, et ceci la partie 1, elles sont dépendantes.
00:04:39Autre chose de génial : l'assignation aux branches.
00:04:43Ici j'ai deux colonnes, trois branches. Deux sont empilées, une est indépendante.
00:04:48Quand je modifie du code, je peux assigner des morceaux (hunks)
00:04:54à une branche précise et continuer de travailler. C'est comme si
00:05:00chaque colonne avait sa propre zone de staging indépendante.
00:05:05C'est l'équivalent de "git add", mais avec plusieurs zones de staging simultanées.
00:05:09Essayons. Je vais ajouter une section à la page d'administration.
00:05:14Je la mets dans sa propre branche, toujours dans le même répertoire,
00:05:19une branche indépendante, et je pourrai ouvrir une PR juste pour ça.
00:05:24Voici le tableau de bord admin avant. J'ai ajouté les inscriptions récentes.
00:05:31J'ai ces deux changements, et je veux les assigner à cette colonne.
00:05:37Si je fais d'autres modifs, GitButler les mettra soit en "non-assigné",
00:05:43soit automatiquement dans la bonne colonne s'il s'agit des mêmes blocs.
00:05:47Modifions le contrôleur admin. Juste un bête commentaire pour voir.
00:05:55Comme le contrôleur admin était déjà assigné à cette colonne,
00:06:00pas besoin de refaire le staging. Il comprend que ça fait partie du même lot.
00:06:05Créons un nouveau commit. Je peux encore une fois l'agrandir pour un
00:06:10long message, ou utiliser l'IA pour générer un message de départ
00:06:15que je pourrai éditer ensuite. L'IA analyse les différences effectuées
00:06:19pour vous proposer une base de rédaction. Voilà.
00:06:23On a un commit pour la page admin, notre branche empilée sur le côté,
00:06:27et je peux créer une PR indépendante. Si je vais voir cette PR,
00:06:31on constate que même si tous ces changements sont présents
00:06:37dans mon répertoire de travail, ils ont été séparés en différentes branches.
00:06:42Je ne vois que la partie admin. Seules les pages admin ont été éditées
00:06:48dans ce commit précis ; ce n'est pas mélangé au reste du travail
00:06:55en cours dans mon répertoire. Tout est bien cloisonné.
00:06:58C'est tout l'intérêt des branches parallèles et empilées dans GitButler.
00:07:02On peut faire beaucoup de choses qui seraient complexes avec Git classique.
00:07:06Par exemple, déplacer des commits d'une branche à l'autre.
00:07:11Pour mettre le commit "admin" dans la branche "red theme",
00:07:15il suffit de le glisser-déposer, puis de supprimer la pile vide.
00:07:20On peut aussi fusionner (squash) des commits en les faisant glisser,
00:07:26pas seulement sur le suivant, mais sur n'importe quel commit de la pile.
00:07:30Je peux descendre ce commit admin vers "sidebar fixes", ou le déplacer.
00:07:36Je peux le mettre plus bas ou le fusionner. Et voilà,
00:07:41la partie admin est maintenant dans "sidebar fixes". On peut aussi diviser
00:07:47un commit en ajoutant un commit vide pour y déplacer des changements.
00:07:52J'ajoute un commit vide n'importe où, ici en dessous. Je peux écrire
00:07:58le message tout de suite ou déplacer les fichiers d'abord. Regardons les fichiers.
00:08:02On a le contrôleur admin et la barre latérale. Je glisse l'index admin
00:08:08dans celui du milieu. Ce commit ne contient plus que l'index admin,
00:08:13et "sidebar fixes" contient toujours le reste des fichiers.
00:08:20On peut aussi déplacer juste des morceaux (hunks). Maintenant,
00:08:30chacun a une partie des correctifs. Et je peux changer le message après coup.
00:08:34Éditer les messages de commit est d'ailleurs ultra simple.
00:08:41En plus de réorganiser, fusionner ou diviser, je peux juste dire :
00:08:46"Finalement, je change ça en Partie 2". Et tout sera rebasé par-dessus.
00:08:53On peut aussi modifier les commits sur place. Plusieurs façons de faire.
00:08:57Imaginons qu'on me demande de changer une marge
00:09:01de 0 à 10 pixels. Comment éditer un commit qui est quatre niveaux
00:09:06plus bas, et dans une autre pile ? Avec GitButler, c'est un jeu d'enfant.
00:09:13Allons faire cette modification.
00:09:16Passons à 10 pixels. Le CSS en ligne, c'est la vie. Voici mon changement.
00:09:23C'est verrouillé car j'édite un bloc déjà modifié, ça doit donc aller
00:09:28dans cette branche. On ne peut pas le mettre dans une branche parallèle.
00:09:32Mais comment l'intégrer ? Le plus simple est de prendre le fichier
00:09:39et de le faire glisser dans le commit visé. Et voilà, le commit
00:09:46contient les 10 pixels, et tout le reste a été rebasé automatiquement.
00:09:51L'autre méthode : faire un commit temporaire,
00:09:55puis le fusionner (squash) dans celui d'origine. C'est exactement
00:10:02le même résultat, on a bien nos 10 pixels de marge. Enfin,
00:10:07il existe le "mode édition". Imaginons qu'on reparte de zéro,
00:10:12on est à 0 pixel et on veut éditer ça. On va directement sur le commit
00:10:20et on sélectionne "Edit commit". C'est là que ça devient intéressant.
00:10:25C'est un peu comme un "detached head checkout" avec Git.
00:10:30L'outil extrait le commit dans cet état précis, vous faites vos modifs,
00:10:36et en quittant, il rebase tout le reste. On refait notre changement,
00:10:39il voit que le fichier est modifié, on sauvegarde et on quitte.
00:10:46Tout est rebasé à nouveau, et notre modification est bien là.
00:10:52On peut donc éditer directement, amender, ou commiter puis fusionner.
00:10:57Les façons de manipuler vos changements dans GitButler sont légion.
00:11:01Dernier point : l'historique des opérations.
00:11:05C'est quelque chose de très difficile avec Git et son "reflog".
00:11:10Tout le monde en a un peu peur. Mais dans GitButler, tout est enregistré
00:11:15dans un journal d'opérations. On peut remonter le temps à tout moment.
00:11:21C'est ce bouton ici. On voit tout ce qu'on a fait durant la session.
00:11:26Et je peux revenir à n'importe quel point précis.
00:11:30Si je veux revenir avant d'avoir commencé mon histoire de 10 pixels,
00:11:37je peux retourner ici et voir l'état exact de mon code avant cela.
00:11:42Je peux même remonter au tout début de cette session.
00:11:47Ce qui n'est pas annulé, c'est ce qui a été poussé sur GitHub.
00:11:52Ici, je vois les commits distants (upstream), mais je reviens
00:11:56avant même mon tout premier commit local. Je peux supprimer
00:12:01cette branche et repartir de zéro. Et même cette annulation,
00:12:05je peux l'annuler ! Je peux rétablir un instantané (revert snapshot)
00:12:11pour revenir là où j'en étais. On peut toujours voyager dans le temps.
00:12:16C'est rassurant : on n'a plus jamais peur de faire une bêtise.
00:12:22Si vous êtes perdu ou voulez retrouver l'état d'il y a 10 minutes,
00:12:26ouvrez la timeline, cliquez sur "revert", et c'est réglé.
00:12:32Voilà pour ce tour d'horizon : rebasage, édition, branches parallèles ou empilées,
00:12:36tout ça très facilement. Téléchargez-le, venez nous voir sur Discord
00:12:41pour nous donner votre avis, et profitez-en bien !

Key Takeaway

GitButler révolutionne le flux de travail Git en permettant aux développeurs de gérer visuellement des branches parallèles et empilées au sein d'un même répertoire de travail, tout en simplifiant radicalement la manipulation des commits.

Highlights

Gestion simultanée de plusieurs branches Git indépendantes ou parallèles sans changer de contexte.

Utilisation de branches empilées (stacked branches) pour gérer les dépendances entre Pull Requests.

Capacité d'assigner des modifications de code (hunks) à des branches spécifiques en temps réel.

Fonctionnalités avancées de manipulation de commits par glisser-déposer (amender

Timeline

Introduction et flux de travail de base

Scott, PDG de GitButler, présente l'outil à travers un projet d'exemple nommé "Y", un clone de Twitter. Il démontre comment l'interface liste les fichiers modifiés de manière similaire à un "git status" classique. L'utilisateur peut inspecter les changements de fichiers comme le CSS ou l'index directement dans l'application. La section explique comment créer une nouvelle branche et y commiter des changements de manière granulaire. Cette étape est cruciale car elle pose les bases de la gestion des branches au sein de l'écosystème GitButler.

Branches parallèles et intégration de l'IA

Cette séquence montre l'utilisation de l'IA Claude pour modifier rapidement le thème visuel du projet, passant du bleu au rouge. Scott illustre la force de GitButler : la capacité de maintenir deux branches indépendantes appliquées simultanément dans le répertoire de travail. On peut ainsi tester des correctifs front-end tout en travaillant sur un nouveau thème sans basculer manuellement entre les branches. L'avantage majeur est de pouvoir pousser ces changements séparément sur GitHub tout en les visualisant ensemble. Cette approche élimine la friction habituelle liée au changement de contexte dans Git.

Gestion des branches empilées (Stacked Branches)

L'auteur introduit le concept de branches empilées, où une branche dépend des modifications d'une autre. Il montre comment transformer un commit en branche dépendante pour créer une hiérarchie logique de Pull Requests. Lors de l'exportation vers GitHub, GitButler ajoute automatiquement des métadonnées pour lier les PR entre elles. Cela permet aux réviseurs de comprendre que la "partie 2" d'une fonctionnalité dépend de la "partie 1". Cette gestion propre évite les conflits complexes lors des fusions successives en amont.

Assignation de code et zones de staging multiples

Le narrateur explique comment GitButler gère l'assignation automatique des modifications (hunks) à des branches spécifiques. Contrairement au "git add" classique qui est global, ici chaque colonne de branche possède sa propre zone de staging. Si un développeur modifie un fichier déjà assigné à une branche, l'outil comprend intelligemment où placer le changement. La vidéo montre également l'utilisation de l'IA pour générer des messages de commit basés sur l'analyse des différences de code. Cela garantit que le travail reste parfaitement cloisonné même si plusieurs fonctionnalités sont codées en même temps.

Manipulation avancée des commits et rebasage visuel

Cette partie technique détaille la réorganisation des commits par simple glisser-déposer, une alternative intuitive au "rebase interactif". On y voit comment déplacer un commit d'une branche à une autre, fusionner (squash) des éléments ou diviser un commit existant en deux. Scott démontre le "mode édition" qui permet de modifier un commit situé profondément dans la pile sans effort manuel. L'outil s'occupe de rebaser automatiquement tous les commits dépendants après la modification. Cette flexibilité transforme des tâches Git complexes et risquées en manipulations visuelles sécurisées.

Journal des opérations et voyage dans le temps

La démonstration se termine par la présentation du journal des opérations, une version simplifiée et plus puissante du "reflog" de Git. Chaque action effectuée dans l'interface est enregistrée dans une timeline permettant de restaurer des instantanés précis du projet. Scott montre qu'il est possible de revenir en arrière même après avoir supprimé une branche ou annulé des commits. Ce filet de sécurité permet aux développeurs d'expérimenter sans crainte de perdre leur travail. Enfin, il invite les utilisateurs à rejoindre la communauté sur Discord pour contribuer à l'évolution du produit.

Community Posts

View all posts