La plus grande nouveauté de GitHub depuis des années : les PR empilées.

BBetter Stack
Computing/SoftwareInternet Technology

Transcript

00:00:00GitHub vient de sortir sa plus grande mise à jour depuis des années : les PR empilées, une toute nouvelle façon de diviser
00:00:05de grosses PR en morceaux plus gérables. Dans cette vidéo, nous allons voir exactement ce que c'est
00:00:10et pourquoi vous devriez les utiliser. Les PR empilées reposent sur un concept puissant mais assez simple : diviser de grands changements de code
00:00:21en une chaîne de pull requests plus petites et interdépendantes. Vous pouvez les examiner et les fusionner indépendamment.
00:00:26Pour avoir une pile, il vous faut au moins deux pull requests dans le même dépôt, où la première
00:00:31ou la pull request du bas cible le tronc, généralement la branche par défaut de votre dépôt comme main,
00:00:37puis chaque pull request suivante cible la précédente. Cela forme une chaîne de dépendances où
00:00:42chaque branche se construit sur celle du dessous. Les modifications fondamentales telles que les types partagés ou les schémas de base de données
00:00:48vont dans les branches inférieures, et le code qui en dépend, comme les routes API et les composants d'interface,
00:00:53va dans les branches supérieures. Et vous vous dites peut-être : j'ai toujours pu faire ça, non ?
00:00:58Je pouvais créer une PR vers main, puis en faire une deuxième vers cette PR et chaîner les PR autant que je voulais.
00:01:04C'est tout à fait vrai, car dans le contexte de Git seul, le concept de PR empilées n'existe pas
00:01:09et vous ne faites que connecter des PR à la chaîne. C'est uniquement au sein de GitHub que les PR empilées
00:01:16prennent tout leur sens. Mais elles apportent d'immenses avantages. Et si vous voulez rester à la page
00:01:22en matière de tech et d'IA, abonnez-vous à Better Stack. Pour utiliser les PR empilées, il est préférable d'avoir
00:01:27la CLI de GitHub installée. Vous pouvez alors exécuter gh stack init puis déclarer votre nouvelle pile.
00:01:33Allons donc dans notre éditeur de texte pour voir un exemple de la façon d'empiler plusieurs PR.
00:01:38La première chose à faire est d'exécuter gh stack init setup database. Dans ce cas,
00:01:44la PR ou la branche s'appellera setup database. Ce sera la PR de base qui va désormais
00:01:50pointer vers main. Ensuite, nous pouvons faire nos modifications. Pour la démo, je vais simplement
00:01:54apporter des changements au fichier readme. J'ai indiqué que j'ai implémenté la base de données, puis il suffit de faire git add,
00:01:59git commit. Tout cela reste du git standard. Lorsque vous êtes prêt à passer à votre série suivante
00:02:04de modifications, vous pouvez exécuter gh stack add, suivi de votre prochaine branche. Je peux ensuite faire d'autres changements,
00:02:10créer les points de terminaison de l'API. Je veux peut-être ajouter quelques points supplémentaires ici, donc je valide ce changement.
00:02:16Ensuite, nous pouvons ajouter une deuxième modification, puis la valider à nouveau. Comme vous pouvez vous y attendre,
00:02:20vous pouvez faire plusieurs commits par branche. Enfin, nous exécutons gh stack add setup front end,
00:02:25puis faisons un dernier changement ici. Et à nouveau, nous faisons git add et git commit. Une fois que nous sommes satisfaits
00:02:31de tous nos changements et que nous voulons pousser toutes ces branches sur GitHub en même temps,
00:02:36nous pouvons simplement exécuter une seule commande : gh stack submit. Cela ouvre cette mini interface en CLI où nous pouvons parcourir
00:02:42chacune des PR de la pile et ajouter un titre et une description siè nous le souhaitons. Ou nous pouvons
00:02:48simplement appuyer sur suivant pour chacune et soumettre trois PR d'un seul coup. Vous pouvez ainsi voir que ces trois PR,
00:02:55setup database, API et front end, ont toutes été envoyées sur GitHub sous forme de pile en une seule commande.
00:03:02Et vous pouvez en réalité faire tout cela sans la CLI de GitHub, en suivant la méthode traditionnelle
00:03:07qui consiste à lier manuellement les PR entre elles, de main vers PR1, puis PR2. GitHub les détectera alors
00:03:14comme une pile une fois que vous les aurez toutes envoyées. La CLI rend simplement la gestion beaucoup plus facile. Rien n'a changé
00:03:20dans Git lui-même. Si vous voulez basculer sur une branche complètement différente qui ne fait pas partie de la pile
00:03:24sur laquelle vous travaillez, vous pouvez le faire et revenir plus tard sur la branche de la pile.
00:03:29Si nous allons maintenant sur GitHub, vous pouvez voir nos trois PR créées
00:03:34en tant que pull requests ici. On remarque aussi la présence d'une petite icône de pile indiquant que ces
00:03:39PR sont associées à une pile. Si nous ouvrons la PR de tête, celle qui se trouve tout en haut de la pile, vous pouvez
00:03:45voir ici que nous pouvons cliquer sur merge stack et afficher cette interface. Nous y voyons chaque
00:03:49PR faisant partie de la pile. Nous pourrions les approuver une par une. Mais une fois que nous sommes satisfaits
00:03:54de tout cela, il suffit de cliquer sur merge stack pour que l'ensemble de ces PR soit fusionné
00:03:59dans main en même temps. Vous remarquerez également que les références aux piles sont désormais intégrées
00:04:03partout sur GitHub. Vous les trouverez sur la page des pull requests, sur la liste des pull requests,
00:04:09ainsi que dans des fonctionnalités comme les workflows GitHub et à travers toute l'application.
00:04:14Donc, si vous travaillez sur de grosses PR et avez besoin d'un moyen simple de les diviser
00:04:18en segments séparés, vous n'avez plus besoin d'attendre que des PR distinctes soient fusionnées dans main
00:04:23et de gérer les rebase et les fusions vous-même. Vous pouvez créer une longue pile et GitHub
00:04:28est maintenant parfaitement équipé pour tout gérer via son interface. La CLI offre quant à elle un moyen très pratique
00:04:33de tout automatiser. La communauté a réservé un accueil extrêmement positif à cette nouveauté
00:04:38en ligne. Et couplée à l'IA, je pense que cela peut devenir une fonctionnalité très puissante,
00:04:43par exemple lors de la conception de boucles d'agents en laissant tourner un agent pendant des heures. Il peut désormais créer
00:04:48des PR empilées et lier tout ce travail ensemble, plutôt que de créer soit une énorme PR, soit une multitude
00:04:54de PR totalement indépendantes. J'espère que cette vidéo vous a été utile. Dites-moi ce que vous pensez
00:04:58des PR empilées dans les commentaires et abonnez-vous à Better Stack pour suivre les dernières actualités
00:05:02de la tech et de l'IA. Merci d'avoir regardé, et à la prochaine !

Key Takeaway

L'introduction des PR empilées sur GitHub simplifie la gestion du code complexe en permettant de créer, soumettre et fusionner une chaîne de pull requests interdépendantes en une seule opération.

Highlights

  • Les PR empilées permettent de diviser de grands changements de code en une chaîne de pull requests plus petites et interdépendantes.

  • La première pull request d'une pile cible la branche principale tandis que chaque pull request suivante cible la précédente.

  • L'utilisation de la ligne de commande GitHub s'effectue via la commande gh stack init suivie de gh stack add et gh stack submit.

  • Il est possible d'utiliser la méthode traditionnelle en liant manuellement les pull requests sur GitHub sans la ligne de commande.

  • La commande unique gh stack submit envoie l'ensemble des branches de la pile sur GitHub simultanément.

  • La fusion de la pile entière dans la branche principale s'exécute en un seul clic grâce au bouton merge stack.

Timeline

Concept des pull requests empilées

  • Les modifications fondamentales comme les schémas de base de données se placent dans les branches inférieures.
  • Le code dépendant comme les routes API et les composants d'interface s'intègre dans les branches supérieures.
  • Chaque pull request d'une pile cible la précédente pour former une chaîne de dépendances.

Cette mise à jour majeure de GitHub résout la difficulté de diviser de grosses modifications en morceaux gérables. Le concept repose sur un chaînage où chaque branche se construit sur celle du dessous. Les développeurs peuvent ainsi examiner et fusionner chaque élément de manière structurée tout en maintenant une hiérarchie claire avec le tronc principal.

Création et soumission avec la ligne de commande

  • La commande gh stack init initialise la première branche de base pointant vers le tronc.
  • L'ajout de modifications successives s'effectue à l'aide de gh stack add pour chaque nouvelle étape.
  • L'envoi de l'ensemble de la pile sur GitHub se réalise via la commande unique gh stack submit.

L'utilisation de la CLI de GitHub automatise la création des piles de branches. Après l'initialisation de la base de données, l'ajout successif de l'API et du front-end prépare la série de modifications. Une interface textuelle permet ensuite de parcourir et de valider l'ensemble des composants avant l'envoi simultané.

Gestion et fusion sur l'interface GitHub

  • GitHub détecte automatiquement les piles créées manuellement par liaison de branches sans utiliser la CLI.
  • Une icône spécifique signale l'association des pull requests à une même pile sur la plateforme.
  • Le bouton merge stack fusionne l'intégralité des pull requests de la pile dans la branche principale en une seule fois.

L'écosystème GitHub intègre les références aux piles dans l'ensemble de ses fonctionnalités et workflows. Le processus de fusion final ne nécessite plus d'attendre la validation sélective de chaque PR indépendante ni de gérer manuellement les fusions complexes. Cette approche s'associe également aux boucles d'agents autonomes pour automatiser la création de code.

Community Posts

View all posts