Como funcionam os PRs empilhados nos bastidores do GitHub | S02E05 | The GitHub Podcast

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: How stacked PRs work behind the scenes at GitHub | S02E05 | The GitHub Podcast · Canal: GitHub · 41:27 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Engenharia de software com IA, Open source e ecossistemas de software

Resumo

Samin Karim, gerente de produto sênior no GitHub, explica como os PRs empilhados ajudam a dividir mudanças grandes em unidades menores, mais fáceis de revisar e coordenar. Ele detalha os desafios de integrar esse recurso nativamente à plataforma, incluindo a complexidade do merge box, das APIs, das regras de proteção e da segurança. A conversa também aborda como agentes podem ajudar a planejar stacks e testar casos que tentem contornar regras. Por fim, o episódio apresenta limitações atuais, planos de evolução e ferramentas como a CLI GH stack.

Pontos-chave

PRs empilhados dividem mudanças grandes em partes relacionadas e revisáveis de forma independente.
Cada PR de uma stack pode ser direcionado a uma equipe responsável diferente, facilitando a revisão em repositórios grandes.
A integração nativa exigiu mudanças em serviços antigos do GitHub, APIs e no fluxo de merge.
O merge box avalia muitas condições e, com stacks, precisa considerar também o estado dos PRs anteriores.
Regras de proteção e configurações de CI destinadas à branch principal são aplicadas a cada PR da stack.
Alterações em CODEOWNERS no meio de uma stack são ignoradas; a fonte de verdade permanece na branch principal.
Agentes podem decompor planos de implementação em stacks e testar tentativas de contornar regras.
Entre os usos recomendados estão migrações, mudanças em várias partes de um monorepo e sequências de alterações dependentes.
No momento da gravação, stacks entre forks ainda não eram compatíveis; automerge e outras capacidades também estavam entre as limitações mencionadas.
A CLI GH stack permite criar e gerenciar stacks localmente e é apresentada como open source.

Capítulos

Início	Capítulo	Resumo
00:03	Apresentação do episódio e do convidado	As apresentadoras introduzem Samin Karim e antecipam a conversa sobre PRs empilhados.
02:07	O que são PRs empilhados	Samin explica como dividir uma mudança grande em PRs relacionados para facilitar a organização e a revisão.
05:14	Revisões e integração nativa no GitHub	A conversa aborda revisões por equipes responsáveis e os desafios de incorporar stacks à plataforma.
09:21	A complexidade do merge box	Samin descreve as verificações do merge box e como as dependências entre PRs ampliam o trabalho.
12:28	Decisões de arquitetura e compatibilidade	O episódio detalha por que o recurso manteve o modelo de PRs e exigiu novas estruturas e APIs.
17:40	Uso, regras e segurança das stacks	Samin apresenta a integração com CI, as opções de ferramentas e as precauções relacionadas a CODEOWNERS.
23:50	Adoção e colaboração com agentes	As apresentadoras e Samin discutem como equipes podem adotar stacks e como agentes podem decompor mudanças e testar regras.
28:04	Adoção em projetos open source e próximos passos	Samin cita projetos que adotaram o recurso e comenta limitações e melhorias planejadas.
31:11	A experiência de PR em diferentes ferramentas	A conversa trata da evolução da experiência de PR e do suporte a stacks em diferentes superfícies do GitHub.
35:17	Projetos recomendados e encerramento	As apresentadoras e Samin compartilham projetos e recomendações, incluindo agents.md e a CLI GH stack.

Citações

Também é mais fácil para os revisores analisarem suas mudanças e, como gosto de dizer, ajuda a contar a história do recurso que você está lançando. — 03:42

Queríamos criar uma experiência que parecesse nativa do GitHub e oferecesse vantagens realmente únicas. — 07:17

Sempre carregamos os CODEOWNERS da branch principal, porque ela é a fonte da verdade. — 21:17

Uma stack deve contar a história do recurso que você está construindo. — 27:01

A razão pela qual os PRs empilhados foram priorizados e concluídos é que a comunidade continuou pedindo por eles. — 34:16

Conceitos e entidades

GitHub (empresa): Plataforma de desenvolvimento que integrou suporte nativo a PRs empilhados.
Samin Karim (pessoa): Gerente de produto sênior no GitHub focado em workflows de desenvolvimento e revisão de código.
Cassidy Williams (pessoa): Apresentadora do podcast e integrante da equipe de developer advocacy do GitHub.
Andrea Griffiths (pessoa): Apresentadora do podcast e developer advocate sênior no GitHub.
stacked PRs (conceito): Forma de organizar mudanças relacionadas em uma sequência de PRs que podem ser revisados em partes.
merge box (conceito): Área do PR que informa se ele pode ser mesclado após avaliar verificações, aprovações, regras e conflitos.
CODEOWNERS (conceito): Arquivo que especifica quais equipes são responsáveis pela revisão de partes do código.
GH stack (ferramenta): CLI para trabalhar localmente com stacks de PRs e criá-las no GitHub.
AGENTS.md (repo): Projeto open source mencionado no episódio como local padronizado para instruções e contexto destinados a agentes de programação.

Tradução completa (pt-BR)

00:03 Este é o podcast do GitHub, um programa dedicado aos temas, tendências, histórias e à cultura da comunidade de desenvolvedores open source no GitHub e em torno dele. Sou Cassidy Williams, também conhecida como Cassadoo, e faço parte da equipe de defesa dos desenvolvedores no GitHub. E hoje está comigo minha adorável coapresentadora, Andrea Griffiths. >> Oi, Cassidy. Oi, pessoal. Sou Andrea Griffith, defensora sênior de desenvolvedores aqui no GitHub. >> Temos uma convidada muito especial hoje. Está animada, Andrea? Eu estou. >> Estou superanimada. Já gravei com ele antes. Ele é uma lenda por aqui. Nossa incrível convidada de hoje é Samin Karim, gerente de produto sênior no GitHub, com foco em workflows de desenvolvedores e revisão de código, e ele lançou minha coisa favorita entre tudo o que já foi lançado, que são os pull requests empilhados. Ele vai dar uma palestra no GitHub Universe sobre PRs empilhados na prática e sobre como pull requests grandes atrasam você e como dividi-los de forma prática. Vamos conversar sobre isso e muito mais hoje. Você pode nos ver ao vivo em San Francisco no dia 28 de outubro ou se inscrever para assistir ao Universe inteiro e muito mais

00:34 online em githubuniverse.com. Dito isso, oi, Samine, como vai? >> Oi, Cassie. Oi, Andrea. Obrigado por me receberem. Estou superanimado. >> Estamos muito felizes de ter você aqui. Então, você poderia contar um pouco às pessoas sobre como chegou ao GitHub? Como chegou aonde está hoje? >> Ah, claro. Sabe, uso o GitHub há tanto tempo quanto consigo me lembrar, desde que comecei a programar no ensino fundamental, e comecei no mundo das startups. Passei um tempo com publicidade, vendi minha

01:06 última startup, trabalhei um pouco na empresa que a adquiriu e, depois disso, tentei pensar no que queria fazer em seguida. Acabei me apaixonando por ferramentas para desenvolvedores, porque era algo que eu usava todos os dias. Comecei uma startup nessa área e, por fim, cheguei ao GitHub, porque que lugar melhor para causar impacto nas ferramentas para desenvolvedores do que o centro de toda a atividade de desenvolvimento? É muito empolgante estar no GitHub agora e poder melhorar de fato a vida de centenas de milhões de desenvolvedores

01:36 no mundo todo. >> E sua equipe está trabalhando em coisas práticas muito legais, com as quais os desenvolvedores realmente se importam. Sinceramente, adoraria me aprofundar nos PRs empilhados. Para quem não sabe o que são, você poderia dar uma visão geral e explicar como eles mudaram os workflows das pessoas? >> Claro. Fico feliz em dar uma visão geral de alto nível sobre o que são PRs empilhados, de onde essa ideia surgiu e, principalmente, por que ela é mais importante hoje do que nunca. A ideia por trás dos pull requests empilhados é que você tem um grande conjunto de alterações.

02:07 Talvez você esteja lançando um recurso enorme, sabe, e precise fazer migrações de banco de dados, endpoints de API e código de frontend. Normalmente, você faria isso de uma destas formas: teria um PR enorme, com talvez mais de 10 mil linhas de código, muito difícil para quem vai revisar e que provavelmente ficaria parado por um tempo enquanto você tenta garantir que tudo esteja certo. É como uma atualização de uma vez só. Ou você teria uma série de PRs meio desconectados. Eles não estão exatamente vinculados. Podem acabar se

02:39 perdendo. Você precisa dizer: “Ei, não faça merge disso fora de ordem”. Com os pull requests empilhados, esse fluxo fica mais simples e você tem uma forma bem clara de, como o nome sugere, empilhar seus pull requests. Assim, você tem um PR para as migrações do banco de dados, outro para os endpoints de API e outro para as alterações no frontend, e tudo fica empilhado. O bom é que agora fica muito fácil gerenciar esse conjunto coordenado de alterações, mas também evitar a armadilha de ter um PR enorme com dezenas de

03:10 milhares de linhas de código, que pode levar uma eternidade para ser revisado. Então, fica mais fácil escrever e organizar seu código, mas também fica mais fácil, o que é importante, para quem revisa analisar suas alterações e, como gosto de dizer, ajudar a contar a história do recurso que você está lançando. Adoro muito esse recurso porque já passei por aquela situação em que precisei dizer: “Certo, não façam merge dos PRs B e C até que o A esteja pronto, e lembrem-se de fazer esse rebase quando começarem a revisar o B, antes de entrar nele”. E isso

03:42 acaba virando uma confusão logística, porque basicamente você precisa dizer explicitamente: “faça isto, por favor; leia isto, leia aquilo”. Então, o fato de as pilhas resolverem esse problema e cuidarem disso é muito bom. Sim, acho que é um daqueles workflows que, depois que você usa, percebe todo tipo de maneira de turbinar seu workflow, especialmente neste mundo em que estamos usando agents. Estamos começando a trabalhar em alterações maiores de uma só vez e fazendo muito mais. É uma ótima forma de organizar seu workflow.

04:13 E acho que cada vez mais desenvolvedores estão descobrindo diferentes maneiras de usar pilhas. Estamos muito animados com isso. Estou muito animada com a redução da carga cognitiva que isso vai me proporcionar, com a promessa de revisões menores e mais focadas. Pelo menos para mim, acho que isso fez uma grande diferença até em projetos nos quais sou eu quem precisa aprovar a pilha inteira. >> O que você percebeu? Como isso mudou a

04:44 experiência de quem revisa código agora que usa PRs empilhados? Ah, sim. Acho que isso nos leva de volta à época anterior, em que você tinha apenas um PR enorme para seu recurso gigantesco. Isso era muito comum, especialmente em organizações maiores. O que podia acontecer é que você provavelmente tinha code owners, principalmente se estivesse trabalhando em um monorepo, e tinha esse PR enorme. O resultado é que vários grupos de code owners revisavam aquele único PR, e isso podia ficar muito

05:14 complicado, muito confuso, com todo tipo de thread para administrar. Podia ser muito confuso tanto para quem revisava quanto para quem escrevia o código, que tentava entender o que estava acontecendo e, depois, fazer com que todo mundo acompanhasse as alterações. O bom dos PRs empilhados é que eles dividem o trabalho. Então, o que costumo recomendar às pessoas, especialmente se trabalham em uma organização grande com code owners configurados, é garantir que cada camada da pilha, cada PR, tenha como alvo um code owner. Assim,

05:45 a equipe de banco de dados, a equipe de API, a equipe de frontend ou quem for. Isso facilita bastante porque a equipe responsável pelo código passa a ter sua própria parte, e sabe tudo o que precisa revisar. Assim, você pode ter uma conversa focada com aquela equipe naquele PR, em vez de todo mundo tentar comentar em um único PR enorme. Este não é um conceito novo. É algo que já vimos na

06:16 indústria, como uma extensão do GitHub ou uma ferramenta que funciona em cima do GitHub. >> E houve comentários perguntando: “Por que demoramos tanto?” >> Adoraria que você explicasse por que demoramos tanto. [risos] >> Para criar isso. >> Sim, sabe, havia muita coisa que precisava ser feita para que os PRs empilhados funcionassem. E acho que, principalmente, como já havia tantas ferramentas e plugins de terceiros

06:46 para fazer isso acontecer, não queríamos simplesmente criar mais um plugin. Queríamos criar uma experiência que parecesse nativa do GitHub e oferecesse algumas vantagens realmente únicas. Também queríamos garantir que os PRs empilhados simplesmente funcionassem, sem concessões: que você pudesse dizer “quero criar uma pilha” sem precisar atualizar todas as configurações, regras e configurações das actions; simplesmente funcionasse. Também queríamos garantir que isso desse suporte a esse tipo de

07:17 e plugins para fazer isso acontecer. Sabe, não queríamos simplesmente criar mais um plugin. Queríamos mesmo criar uma experiência que parecesse nativa no GitHub e oferecesse vantagens realmente únicas. E queríamos garantir que stacked PRs simplesmente funcionassem, sem concessões: bastava dizer “quero criar uma pilha”, sem precisar atualizar todas as suas configurações, regras, actions e configs. Simplesmente funcionava. Também queríamos garantir que isso, de certa forma, desse suporte a isso

07:48 capacidade de fazer merge de vários PRs de uma vez. Acho que, para quem já usou stacked PRs — e, se você ainda não usou, recomendo muito que experimente —, fazer merge de vários PRs de uma vez é extremamente complicado, especialmente quando se lida com squash merges e repos com throughput muito alto, onde os merges acontecem às vezes várias vezes por segundo, como acontece com alguns dos nossos maiores clientes. Então, é muito importante garantir que isso funcione direito. E o que acabamos tendo que fazer foi não só

08:19 reescrever um monte de coisas no GitHub, porque, como vocês sabem, os PRs são, de muitas maneiras, o centro do GitHub. Todos os outros serviços que o GitHub tem, de certa forma, partem dos PRs. Mas também precisamos garantir que todos os serviços que dependem deles fossem atualizados. >> Transformar algo em algo nativo da plataforma não é fácil. É algo em que você não está lidando só com diferentes partes da base de código, mas também com partes legadas dela. Você sabe qual foi a parte mais antiga da

08:49 base de código que teve que ser atualizada para isso? Tenho certeza de que havia muitas camadas diferentes para atravessar. >> Ah, sim. Acho que, sabe, a forma como um PR é integrado é, de muitas maneiras, bastante padrão. Acho que chegamos a mexer em partes do código que não eram atualizadas havia pelo menos uma década. E é uma daquelas coisas: os PRs existem há muito tempo. Então, sabe, se está funcionando, é um código central sólido e estável, e precisamos entrar lá e editá-lo. É, pela primeira vez em bastante tempo.

09:21 >> Dá medo. >> Mas é… [risos] Foi aterrorizante. Desculpa. E eu sei que só o merge box já é um código muito complexo. O que é o merge box, para quem não sabe? E, por favor, explique o quanto ele é complexo, porque, quanto mais eu aprendo sobre isso, mais minha cabeça fica girando. >> É, sabe, como desenvolvedor e usuário final do GitHub, eu nunca entendi de verdade o quanto o merge box era complexo. Agora, estando do outro lado, tenho uma perspectiva e uma apreciação bem diferentes pelo merge box. Então,

09:53 para quem não conhece, o merge box é aquela parte no fim do PR que informa se o PR está pronto para o merge ou não. Parece algo bem direto quando você pensa nisso. É como: “Certo, está verde? Está vermelho? Estou esperando as verificações terminarem?”. Mas, na verdade, muita coisa acontece nos bastidores, porque é claro que precisamos saber: as verificações estão passando? Os builds estão passando? Você configurou regras? Exige uma aprovação? E, claro, há conflitos? Você precisa resolver esses conflitos? Eles podem ser resolvidos automaticamente ou você

10:24 precisa fazer isso na linha de comando? E há centenas de condições que avaliamos. Outra coisa que talvez as pessoas não percebam é que ele é atualizado em tempo real. Então, quando alguém envia um commit para o próprio branch ou alguém envia uma aprovação em outra aba, ele recarrega e se atualiza automaticamente. Basicamente, o que estamos fazendo nos bastidores é que, por trás do GitHub, é claro, está o Git. Temos uma enorme série de servidores que estão executando operações do Git constantemente. Então,

10:56 sempre que algo muda, basicamente simulamos um merge do Git e tentamos ver: certo, esse commit realmente passa? Há conflitos de merge? Ele passa por todas as regras? Sabe, dá para complicar bastante, por exemplo, garantindo que o commit resultante tenha determinados metadados, que seja assinado etc. Poderíamos continuar falando disso sem parar. E isso já era complicado por si só e é uma parte essencial do GitHub. Mas, além disso, temos os stacked PRs, que agora

11:28 acrescentam outra camada de complexidade e dependências, porque, para fazer merge de uma stack, você precisa garantir não só que o PR atual está em ordem, mas também que todos os PRs abaixo dele estão verdes. Então, agora você não verifica apenas o estado de um PR, mas potencialmente o de até 100 PRs. >> Isso vai muito fundo, e o merge fantasma que acontece nos bastidores foi o que mais me surpreendeu. Eu simplesmente não sabia que era assim que funcionava. E isso exige muito processamento só

11:58 para garantir que algo possa receber merge. É realmente interessante. >> É, é uma daquelas coisas em que queremos muito que a experiência do usuário final seja perfeita. Não é algo em que as pessoas deveriam ter que pensar, porque o GitHub faz isso nos bastidores. Mas é uma daquelas coisas em que trabalhar em um novo recurso como stacked PRs aumenta literalmente de forma exponencial a complexidade de algo assim. E são justamente essas coisas que precisamos garantir

12:28 não só que fizemos direito, para garantir que a segurança esteja assegurada, mas também que seja confiável e esteja disponível. >> Adoro isso. Como você passou de alguém na internet dizendo que queria isso a realmente fazer acontecer? Na verdade, comecei no GitHub em janeiro. Então, quando entrei, o projeto de stacked PRs já tinha recebido sinal verde e já havia bastante interesse crescendo em torno dele. O que posso dizer é que, na verdade, houve outras tentativas ao longo

12:59 dos anos de executar stacked PRs no GitHub. Esta é, acho, a terceira ou quarta tentativa que fizemos. >> Eu ia dizer que vi que houve uma tentativa por volta de 2022 também. É, acho que houve vários tipos de tentativa, algumas que tentaram abordar isso como um conceito completamente diferente, algo fora dos PRs, algo muito ligado a referências do Git e que, essencialmente, acabaram levando à iteração atual. E o motivo de ter funcionado foi termos decidido manter o modelo central de PR, em vez de nos afastarmos dele

13:31 — o que, sabe, certamente tem suas vantagens —, mas isso acabou exigindo tanta reconstrução que ficou caro demais e complicado demais, especialmente em um sistema tão grande. >> Com os PRs, decidimos usar o conceito de PR que já temos e permitir que você os agrupe em stacks, mas, é claro, garantindo que isso funcione nativamente com todo o GitHub. Acho que essa foi uma das principais decisões de arquitetura que

14:01 nos permitiram avançar com stacked PRs de uma forma mais acessível. >> Isso trouxe alguma desvantagem além de ter que lidar com essa montanha de código legado, ou foi simplesmente a decisão certa, algo que ficou claro com o tempo? >> É, quer dizer, estamos obviamente pegando um modelo existente de pull requests e sobrecarregando-o até certo ponto. Uma das coisas interessantes que precisamos mudar como parte dos stacked pull requests é que, em geral, quando você tem um PR,

14:33 o PR tem uma base ou um destino, e presume-se que ele será integrado a esse destino. Há lógica em um zilhão de serviços diferentes por toda parte que literalmente presume isso. Com os stacked PRs, introduzimos esse novo conceito em que a base de um PR pode ser, por exemplo, o PR2 ter como destino o PR1, mas o destino do merge ser diferente, porque o destino do merge é o seu branch principal. E assim você pode ter todos esses PRs diferentes cujas bases não

15:03 realmente se alinhar aos destinos de merge. E isso foi um empreendimento e tanto. Provavelmente foi uma das maiores coisas que tivemos que fazer, porque era tipo… >> Sim. >> Sim. Porque não aponta para uma branch, aponta para um PR. >> Exatamente. >> É uma estrutura de dados totalmente nova. Ah, nem tinha considerado isso. [risos] >> Foi um empreendimento realmente enorme. Acho que essas foram algumas das concessões que tivemos que fazer, e definitivamente tivemos que criar várias APIs novas e atualizar vários serviços.

15:35 Uma das coisas que também tivemos que fazer como parte dos pull requests empilhados foi criar, essencialmente, um caminho de merge totalmente novo. E isso significava que, como parte dessa operação, as APIs existentes que oferecíamos aos nossos clientes e a outras plataformas para fazer merge de PRs não funcionariam, porque eram síncronas e expiravam em 10 segundos. PRs empilhados, especialmente se você tiver uma pilha enorme, definitivamente vão levar mais de 10 segundos. Então tivemos que criar uma nova API que fosse

16:06 assíncrona, e tivemos que pedir às pessoas que migrassem. Então, definitivamente tivemos que fazer algumas concessões, mas acho que, no fim das contas, continuar usando PRs, embora não seja perfeito, nos deu o melhor caminho a seguir, que ainda usava conceitos conhecidos pelos usuários, pelas plataformas e também pelos agents, e então aplicamos esse conceito adicional por cima, em vez de tentar reconstruir tudo do zero. Sim, eu nem

16:38 tinha considerado também o lado da API. Há tantas coisas em que você não pensa até precisar pensar nelas. E é por isso que leva tanto tempo. Há tanto legado e tantas coisas a fazer. >> Com certeza. Quer dizer, de fora, a maioria das pessoas pensa: “O que é isso? É só mostrar uns aos outros…” >> …e fazer merge de tudo. [risos] Tenho certeza de que muita gente tem várias ideias equivocadas sobre como as coisas funcionam internamente e sobre tudo o que precisava ser alterado e atualizado para fazer isso funcionar. E não apenas para fazer funcionar, porém. E agradeço por você ter mencionado isso antes, Sam, que você

17:09 queria que isso fosse apenas parte da própria plataforma, um recurso de primeira classe, com suporte nativo, e não algo simplesmente anexado como uma extensão, outra ferramenta ou algo assim. E realmente parece ser assim. Parece muito integrado aos PRs. Agora, parece algo bem nativo da plataforma. Legal. Então, para quem já usava outras coisas, tinha outros truques ou maneiras de fazer isso, seja com um plugin externo

17:40 ou fazendo funcionar de alguma outra forma, o que essa pessoa pode esperar agora ao começar a usar PRs empilhados, que agora fazem parte da plataforma? E você mesmo, não sei se fazia isso de alguma maneira antes. Há algo que possa compartilhar sobre como isso mudou ou o que as pessoas podem esperar? Qual você diria que é a maior diferença? >> Sim. Para quem talvez esteja usando essas outras ferramentas e agora está avaliando os PRs empilhados do GitHub, acho

18:12 que uma das melhores coisas é que eles estão integrados nativamente ao GitHub. Então, ao olhar seus PRs, você poderá ver todos eles juntos. E algumas coisas que talvez você precisasse fazer antes, de um jeito meio improvisado, não são mais necessárias. Por exemplo, sei que muita gente precisava configurar as próprias actions, ou seja, as execuções de CI, para rodar em cada PR, em vez de apenas nos PRs direcionados à main, ou precisava flexibilizar as regras de proteção da branch por causa do modo como as coisas funcionavam.

18:43 Você não precisa mais fazer isso. A maneira como avaliamos tudo para as pilhas é a seguinte: as regras de proteção, as configurações de CI e tudo o que você tiver direcionado à main se aplicam a cada PR da pilha. Então, provavelmente você pode desfazer alguns desses truques ou soluções alternativas de que precisava. Outra coisa muito importante é que temos uma CLI que estamos lançando, a GH stack, que permite trabalhar com pilhas localmente. >> E também temos uma API pública que é

19:13 totalmente aberta, e já vimos vários plugins de terceiros, ferramentas e projetos open source adotarem nossa API. Então, se você não quiser usar nossa CLI, não precisa. Isso também é diferente de alguns outros produtos. Você pode criar sua própria ferramenta para fazer seu próprio empilhamento. E ela é muito aberta, e acho que essa é uma das grandes coisas que estou animado para ver: temos essa plataforma aberta e uma série de ferramentas opinativas que criamos. Mas, se quiser criar a sua própria, fique à vontade. E

19:44 sinceramente, eu adoraria ver isso, porque é algo com que podemos aprender e talvez até incorporar ao GitHub. Acho que também é uma boa ideia equivocada a esclarecer: não estamos criando esses recursos para esmagar a concorrência nem nada assim. Estamos fazendo isso porque são boas ideias que queremos disponibilizar a todos para que possam usá-las e desenvolvê-las. Então, se você estava usando pilhas em outra ferramenta fora do GitHub, agora não só não precisa mais fazer isso, como talvez essas ferramentas possam ser melhores de outras

20:15 maneiras, porque o recurso está integrado nativamente e elas não precisam criar as próprias soluções alternativas. >> Com certeza. Acho que aqui nós valorizamos muito a liberdade de escolha dos desenvolvedores, e adoro isso. >> Isso mesmo. >> Adoro isso para nós. >> Há mais alguma coisa que possamos compartilhar sobre como essa coisa foi feita? Talvez uma das ideias equivocadas ou algo que vocês não esperavam que fosse o maior desafio, quando começaram a trabalhar de fato nos detalhes internos para fazer isso funcionar? >> Há uma coisa interessante que vou mencionar: Code Owners é um caso bem interessante. Então… o conceito de Code Owners é

20:46 na verdade bem simples: você tem um arquivo de Code Owners que indica quais equipes são responsáveis pela revisão do código de uma parte específica, com base na equipe responsável pelo código naquele diretório, por exemplo. Com PRs empilhados, surgiu uma peculiaridade interessante: potencialmente, como os PRs da pilha são construídos uns sobre os outros, você poderia fazer uma alteração no primeiro PR, o PR da base, removendo ou alterando os proprietários do código

21:17 e, assim, ao criar o segundo, o terceiro ou o quarto PR, conseguir contornar a revisão exigida dos proprietários do código. É uma peculiaridade um pouco estranha que pode acontecer. A solução que adotamos foi simplesmente ignorar quaisquer alterações em Code Owners no meio de uma pilha. Quando você tem uma pilha de PRs, sempre carregamos Code Owners da sua branch main, porque ela é a fonte da verdade, e não queremos

21:48 permitir que as pessoas se apropriem dos Code Owners para contornar a revisão de código ou fazer alguma coisa suspeita. >> Nem tinha pensado nisso. [limpa a garganta] Ah, desculpe. [risos] Pode continuar. >> Não, é que há todas essas coisas diferentes, e esse é o nível de detalhe a que prestamos atenção enquanto trabalhamos nisso. Claro que estamos tentando garantir que esse recurso funcione e seja fácil de usar, mas, no caso do GitHub e dos PRs, isso também é, em grande medida, um produto de segurança. De

22:18 Claro, você sabe, empresas dependem disso para garantir que o código seja bem revisado, atenda a todos os requisitos e, para quem segue padrões como SOC 2 ou ISO 27001, essas são coisas realmente importantes. E é aí que os code owners e todas aquelas considerações de segurança foram realmente importantes para nós. >> Adoro como uma parte tão grande do desenvolvimento é pensar: como alguém vai tentar quebrar isso? Sim, >> é fascinante ter que pensar em todos esses casos de uso diferentes em que

22:49 a questão é: como alguém poderia quebrar nosso sistema impecável? >> E sabe o que é ainda melhor hoje em dia? Você também pode ter agents fazendo isso. Isso foi algo que fizemos de forma bastante extensiva: tínhamos um enxame de agents rodando dia e noite, tentando quebrar o recurso, contornar as regras e fazer todo tipo de coisa. >> É um bom teste. >> Eles são muito engenhosos. São muito criativos e os testes conduzidos por agents, acho que são um novo tipo de teste. Sempre falamos em desenvolvimento orientado a testes, mas agora acho que existe

23:20 essa nova era em que deixamos os agents tentarem quebrar as coisas. E eles aprenderam com toda a nossa criatividade e são incansáveis. >> Sim. E também conseguem fazer isso sem precisar descansar à noite. É, isso é, na verdade, uma forma muito interessante de fazer um teste de estresse de um sistema. Não tinha pensado nisso dessa maneira. Muito legal. Podemos falar sobre quem… quer dizer, sobre como as equipes estão adotando os stacks agora? Então, equipes começam a adotar esses workflows, como vimos na internet, e

23:50 havia algumas pessoas… obviamente, muita gente tinha opiniões, muita gente estava feliz, muita gente tinha críticas válidas, mas >> sim, exatamente. Para as equipes que estão adotando esses workflows, vamos falar de uma coisa que elas talvez precisem fazer como equipe. Há algum hábito que precisam mudar? Há alguma maneira de encarar a construção de PRs que precise se adaptar a essa nova forma de pensar e trabalhar? E, com base nas

24:22 experiências que você viu, tanto no uso interno quanto entre os primeiros a adotar, há alguma lição aprendida que possamos compartilhar para facilitar a transição das pessoas para PRs empilhados, caso queiram adotá-los? >> Sim, ótima pergunta. Acho que, sinceramente, a coisa mais fácil é perguntar aos seus agents. Temos um arquivo de skill. Os agents são muito bons em dividir as tarefas, especialmente se você estiver usando o modo de planejamento. Quando pedir ao seu agent para

24:54 planejar esse recurso, certifique-se de que a skill de stacks esteja instalada, e seu agent poderá seguir as instruções e usá-la para decompor seu plano maior em um stack com talvez alguns PRs. O que descobrimos é que isso também ajuda a orientar o agent a dividir o código. Em vez de, mais uma vez, enviar um PR enorme com dezenas de milhares de linhas de alterações, ele o divide. Assim, cada PR é, de forma

25:26 lógica, uma unidade atômica de alteração que pode ser revisada de forma independente. E isso facilita muito o trabalho até mesmo dos seus agents de revisão de código e dos revisores humanos quando chega a hora de fazer o merge. Acho que isso é enorme. Para quem está adotando PRs empilhados e começando a explorá-los, eu diria para analisar as situações em que, quer dizer, basta revisar o histórico dos seus PRs e procurar os casos em que havia vários PRs agrupados, como a Cassie mencionou, em que vocês os marcavam juntos e diziam: “Ei, talvez ainda não façamos o merge deste”

25:58 e, sabe, “este está relacionado àquele, mas precisa entrar depois daquele e não antes deste”. Há vários casos em que fazemos isso. Migrações de banco de dados, ou qualquer tipo de migração, são um exemplo comum em que existe uma sequência de coisas que precisam ser lançadas, e PRs empilhados são ótimos para isso. Se você trabalha em um monorepo e tem todos os seus projetos ou serviços dentro de um único repo, tudo organizado em diretórios diferentes, e tem code owners, e tudo isso configurado, esse é outro ótimo caso de uso para PRs empilhados, quando você está trabalhando em um recurso, mas tem alterações diferentes espalhadas pelo repo. Você pode usar stacks para dividir isso em partes individuais. E a última coisa que eu diria sobre stacks é que a decisão realmente cabe a você. Vimos pessoas usando stacks apenas para o próprio desenvolvimento, para continuar avançando. Sabe, se você usa squash merge, há uma funcionalidade de rebase muito boa que o squash merge e os stacks oferecem. Assim, você evita

26:29 ter que lidar com conflitos de merge se fizer squash merge com frequência. Portanto, há várias maneiras pelas quais os stacks podem ser úteis, mesmo que você não esteja necessariamente trabalhando em uma sequência de coisas. Mas, em geral, volto ao conceito de que um stack deve contar a história do recurso que você está desenvolvendo. Há literalmente uma pequena visualização de linha do tempo na página do PR, com cada PR empilhado. E o que você quer é que o revisor, ou

27:01 qualquer pessoa que venha a consultar esse código depois, ao olhar para a linha do tempo e para a lista de PRs, consiga entender a história do que você está tentando construir. Assim, basta uma olhada rápida para entender: “Certo, é isso que está prestes a ser lançado”. Sinto que esse tipo de narrativa é cada vez mais essencial hoje em dia, na era do desenvolvimento agentic, em que as pessoas estão lançando tanta coisa. Se você não conhece a história, um recurso individual não faz sentido. E, por isso, poder ver essa linha do tempo e entender como as coisas se encaixam é

27:33 muito bom para entender — que é do que mais precisamos agora. >> Concordo. Concordo. E quanto a projetos open source? Você tem visto muita adoção? Recebeu algum feedback de mantenedores sobre como isso talvez tenha mudado a forma como trabalham com colaboradores, sejam humanos ou agents, já que eles também vão aparecer nos PRs? [limpa a garganta] >> Sim, vários projetos open source, da Vercel, Next.js e NX à equipe do React, entre muitos outros,

28:04 e o Homebrew, estão usando PRs empilhados. Estamos muito animados em ver essa adoção. Uma das limitações que ainda existem nos PRs empilhados, e que estamos trabalhando para resolver — é o próximo item para nós —, é o suporte a PRs empilhados entre forks. Esse é um dos grandes pedidos da comunidade. >> No momento, os PRs empilhados só funcionam dentro de um único repo. Se você tiver um fork, não poderá criar um PR empilhado. Estamos trabalhando para mudar isso. Mais uma vez, esse é um daqueles casos que envolvem muitas coisas. Então,

28:35 estamos trabalhando nisso, mas estou muito animado para quando lançarmos esse recurso. >> Sim, entender como a branch base é diferente do PR base e coisas assim. Imagino que, entre forks, seja um desafio totalmente diferente, mas estou muito animado com a chegada desse recurso. >> Que legal. Você nos leva a um ótimo ponto, a um ótimo momento para falar sobre o que mais está por vir. Vocês já fizeram tanta coisa, e isso vem sendo preparado há muito tempo. Um salve para as equipes que tentaram antes — quem quer que fossem, lá em

29:07 2022, que deu uma última tentativa sincera — e para todos que estão aqui trabalhando duro para fazer isso acontecer. E ter você se juntando à equipe e ajudando a concluir tudo isso é incrível. Esse foi, sem dúvida, um grande esforço da equipe do GitHub, que vinha sendo preparado há muito tempo. Fico feliz que finalmente tenha chegado. O que mais está no horizonte, além do suporte a forks, que também me deixa muito animado? >> Sim. Como mencionei, com os PRs empilhados tivemos que criar um caminho de código totalmente novo para fazer o merge. Então, uma das limitações

29:38 em 2022, que deu a última chance sincera, além de todo mundo que esteve aqui trabalhando muito para fazer isso acontecer, e de você ter se juntado à equipe e também ajudado a concluir o trabalho. Incrível. Esse certamente foi um grande esforço da equipe do GitHub, que já vinha sendo preparado há muito tempo. Fico feliz que finalmente esteja aqui. O que mais está no horizonte, além do suporte a forks, que também me anima muito? >> Sim. Como mencionei, com stacked PRs tivemos que criar um caminho de código totalmente novo para fazer o merge. Então, uma das limitações

30:08 O que temos para stacked PRs é que há alguns recursos que ainda faltam para mesclar stacked PRs. Não temos mesclagem automática nem a possibilidade de ignorar regras e mesclar forks, como já conversamos. Essas são coisas que estamos trabalhando para incluir, para deixar as mesclagens de stacks no mesmo nível das mesclagens de PRs comuns. Mas há mais coisas que acabamos de lançar recentemente. Acabamos de lançar a possibilidade de criar commits assinados durante rebases. Para quem faz parte da turma do rebase e do force push, vocês sabem que eu, pessoalmente, nunca usei merge commits. Na minha opinião pessoal — é uma opinião forte — eu odeio merge commits. Acho que são feios. Então, pessoalmente, adoro fazer rebase e force push. Gosto do histórico linear, mas, independentemente disso, sei que muita gente vinha pedindo que os rebases criassem commits assinados, porque, quando você cria um merge commit, o GitHub cria um commit assinado, mas os rebases não. E essa é uma das coisas que os stack rebases agora fazem: criam commits assinados, o que, se vocês

30:39 faz parte da turma do rebase e do force push, vocês sabem que eu, pessoalmente, nunca usei merge commits. Na minha opinião pessoal — é uma opinião forte — eu odeio merge commits. Acho que são feios. Então, pessoalmente, adoro fazer rebase e force push. Gosto do histórico linear, mas, independentemente disso, sei que muita gente vinha pedindo que os rebases criassem commits assinados, porque, quando você cria um merge commit, o GitHub cria um commit assinado, mas os rebases não. E essa é uma das coisas que os stack rebases agora fazem: criam commits assinados, o que, se você

31:11 tem regras que exigem commits assinados, é uma daquelas coisas para as quais, mais uma vez, temos que voltar e refazer um monte de coisas. Mas agora isso está disponível. Estamos muito animados com isso. Ainda há muito mais que precisamos fazer em geral. Falando em rebase e force push, para melhorar a experiência com PRs, muita coisa foi construída ao longo dos anos na experiência com PRs, para além de stacks. Como equipe, estamos analisando de forma ampla como as pessoas escrevem código, como colaboram com seus agents e umas com as outras, e realmente reformulando a experiência com PRs para torná-la muito mais rápida, trazer as informações de que você precisa e simplesmente permitir que você avance mais rápido pela experiência.

31:41 Ótimo. >> Adoro isso. Adoro isso. E, na verdade, isso me leva ao tema da escolha do desenvolvedor, que é minha música favorita do dia aqui, hoje, porque você pode usar stacked PRs em todas as interfaces do github.com, certo? Então, talvez vocês possam nos contar um pouco sobre onde dá para usar: na CLI, no app do Copilot, que é

32:12 uma das minhas novidades favoritas, porque existe uma skill para a CLI. Você pode falar um pouco sobre por que era importante garantir que ela estivesse acessível em todos os lugares? >> Sim, acho que, mais uma vez, queremos que stack PR seja uma parte essencial dos PRs no GitHub. E isso significa que precisa funcionar em todos os lugares: na CLI, na Copilot CLI, no app GitHub Copilot, no app para dispositivos móveis, no Android, no iOS e, claro, no github.com. >> E, para isso acontecer, tivemos muita coisa a fazer. Já falamos sobre os modelos que precisávamos alterar e coisas do tipo, mas, no fim das contas, mais uma vez, as pessoas estão escrevendo código em muitos lugares diferentes agora. As pessoas estão programando pelo celular, fazendo sessões remotas com agents. E queremos apenas tornar tudo isso fácil. E, mais uma vez, mesmo que você não use o app do Copilot ou nenhuma dessas ferramentas, temos o arquivo de skill, e você pode indicar esse arquivo para qualquer agent, independentemente do fornecedor

32:42 e ele pode criar stacked PRs usando a CLI ou a API pública. A ideia é que seja muito aberto e, como você mencionou, Andrew, tudo gira em torno da escolha do desenvolvedor. Queremos apenas construir a plataforma, e desenvolvedores podem descobrir como querem integrá-la, independentemente dos workflows que usam. Gosto muito disso e quero reconhecer você e sua equipe, porque vocês têm trabalhado muito nisso. De repente, houve muitos holofotes sobre a equipe em certos momentos, quando o projeto ficou particularmente

33:12 viral nas várias redes sociais, e as pessoas descobriram que havia uma equipe trabalhando nisso. Vocês fizeram um ótimo trabalho para atravessar todo o ruído e chegar ao essencial: torná-lo aberto, seguro e fazê-lo funcionar na plataforma. Então, mais uma vez, parabéns e obrigado por levar isso até o fim, porque não foi pouca coisa. >> Todos os elogios para você e para a equipe. [risos] >> Obrigado. E preciso repassar isso a todos os nossos clientes, usuários,

33:44 todos os desenvolvedores que participaram da beta e pediram esse recurso. Primeiro, o motivo pelo qual Stack PRS foi priorizado e concluído é que a comunidade continuou pedindo. Sei que muita gente vinha pedindo isso há muito tempo. Demorou um pouco, mas conseguimos. E não é o fim. Há muito mais que precisamos fazer, e realmente dependemos das contribuições e do feedback da comunidade. Sei que pode ser muita coisa. Há muita coisa acontecendo, mas nós realmente ouvimos. Passamos muito

34:16 tempo em todas as plataformas, nos posts de discussão e em tudo mais, realmente ouvindo o que as pessoas estão dizendo, porque queremos melhorar a plataforma, e não conseguimos fazer isso sem as contribuições e o feedback de vocês. É realmente uma parceria entre nós, os desenvolvedores e a comunidade. >> Com certeza. >> Adoro isso, e é uma parceria contínua, certo? As coisas mudam, mas vocês continuam fazendo isso à medida que crescem, e adoro isso. Às vezes, as pessoas encontram os casos de borda mais inusitados e dizem algo como

34:47 >> E que prazer é esse. >> Sim. >> Dito isso, estamos chegando ao fim do nosso tempo. Então, antes de ir, todos nós temos vários projetos open source e outras coisas que gostaríamos de compartilhar. Se não se importarem, vou começar. O link que vou compartilhar — e todos esses links estão nas notas do episódio — é para um projeto de Sarah Drazner. Ela é engenheira distinta no Google e, em uma vida anterior, antes de entrar na área de tecnologia, era ilustradora científica. Ela está combinando suas habilidades técnicas e de ilustração para criar explorações visuais

35:17 de código. Então, se você acessar o site dela — o endereço também está nas notas do episódio —, sarah.dev/projects, poderá ver os desenhos de código dela. Ela explica em detalhes como MCP funciona na prática, as diferenças entre GPUs e CPUs, bancos de dados vetoriais ou vários tipos de arquitetura de software. É muito legal ver tudo isso explicado visualmente. E ela também é uma artista muito talentosa. Esse era o trabalho dela antes de

35:49 entrar na indústria de tecnologia. É uma combinação muito legal de habilidades que também pode ensinar algo a você. Essa é a minha escolha para este episódio. >> Adoro isso. Sou muito fã da Sarah — é até constrangedor. E também aprendo muito visualmente. Adoro quando as pessoas desenham coisas para me explicar. [risos] Estou empolgada com esse projeto. Preciso conferir. Que legal. Ótimo. Vou em seguida. Quero destacar um clássico, um clássico novo, que é

36:19 agents.md. Sabiam que esse é um projeto open source de verdade? E do que se trata o agents? Bem, >> aqueles comandos de configuração que ficam escondidos nos seus readmes, como os testes que ninguém executa, >> as regras que, sabe, você não… elas ficam na sua cabeça, eu acho, mas precisam estar em um arquivo. Só que não necessariamente pertencem aos PRs. Então, todo esse contexto de que seu coding agent precisa, independentemente do coding agent ou do fornecedor, na maioria das vezes ele não sabe onde

36:50 encontrar isso, certo? Ele só tem acesso ao que contamos a ele. Então, agents.md oferece aos repos um lugar óbvio para colocar essas informações. É um padrão; o setor concordou que essa é a forma de trabalhar com agents. E também é, por si só, um projeto open source, sob a AIF Foundation. Você pode encontrar o próprio projeto em github.com/agentsmd/agents.md. Adoro isso. É um padrão simples que funciona. É aberto. E

37:20 encontrar essa informação, certo? Eles só têm acesso ao que contamos a eles, então agents.md dá aos repos um lugar óbvio para colocá-la. É um padrão; é um padrão do setor, que se alinhou e decidiu que essa é a forma de trabalhar com agents. E também é um projeto open source por si só, sob a AIF Foundation. Então, você pode encontrar o próprio projeto em github.com/agentsmd/agents.md. Adoro isso. É um padrão sem graça que funciona. É aberto. E

37:51 >> Padrões sem graça são os melhores padrões. >> Exatamente. Exatamente. E qualquer coisa que ajude seus agents a fazer menos suposições e simplesmente inventar coisas que você sabe que não vão funcionar no seu projeto vai ser incrível. Então, confira se ainda não começou o projeto. E, se tiver feedback ou estiver interessado em como o AGENTS.md pode melhorar, abra uma issue. >> Samine, o que você trouxe para nós hoje? >> Bem, talvez seja meio trapaça, mas preciso mencionar o GH stack CLI.

38:22 >> Ooh, sim. Muito bom. >> O stack CLI é um que tem uma história engraçada por trás. Quando começamos a trabalhar no projeto de PRs empilhados, na verdade não estávamos planejando criar um CLI. Pensamos que talvez fosse algo mais leve. E, quando comecei a trabalhar com o pessoal, pensei: precisamos mesmo de um CLI. E, como gerente de produto, pensei: bom, provavelmente não vou ser eu quem vai criar isso, mas vou começar a montar alguns scripts, algumas coisas para ajudar,

38:54 sabe, a criar algumas issues e tarefas. Então eu tinha uma série de scripts de bash no meu computador e pensava: “Sim, é assim que poderíamos fazer um rebase em cascata, ou é assim que poderíamos gerenciar uma stack localmente.” E esses scripts foram crescendo, crescendo e crescendo. Depois, escrevi uma série de documentos, basicamente, para o CLI, para compartilhar com clientes e usuários iniciais, e perguntar: “Ei, isso parece… tem todos os comandos? Teria

39:24 tudo o que vocês precisariam?” E as pessoas diziam: “Sim, temos feedback” ou algo assim. Mas, no fim das contas, pensei: “Sabe, é muito difícil conseguir feedback sobre isso se for só documentação.” Aí pensei: “Quer saber? Vou começar a criar isso.” E comecei a criar o CLI. Ele passou de algo escrito inteiramente em bash para uma versão que reescrevi em Go — que é também a linguagem em que o GH CLI principal foi escrito — e virou esse monstro que faz operações locais com stacks e

39:55 que, claro, pode enviar e criar suas PRs empilhadas. Tem todas essas TUI, essas interfaces gráficas legais no terminal para visualizar uma stack, enviar uma stack de PRs e modificar uma stack. Com certeza me diverti muito com elas. Mas, de todo modo, incentivo o pessoal a conferir, especialmente porque, mais uma vez, é open source, então fiquem à vontade para fazer um fork. Deixem suas sugestões, abram uma issue. Tenho muita coisa no meu roadmap que quero continuar aprimorando. E, mais uma vez, eu realmente

40:26 adoraria receber bastante feedback, porque queremos muito que isso se torne uma parte central da experiência STAX, e sei que ainda queremos fazer muito mais. Me diverti bastante criando isso. >> É um CLI lindo. Tipo, você fica: “Ah, sim, sem problema. Só reescrevi tudo em Go e agora é uma ferramenta de CLI espetacular que as pessoas estão usando.” O fato de você poder reorganizar sua stack, remover algo do meio, adicionar algo no fim… Foi muito bem feito e tem uma aparência ótima para uma

40:57 interface de terminal. Fiquei muito impressionada quando experimentei pela primeira vez, então não seja modesto. É uma ferramenta de CLI incrível. >> Obrigado. >> Certo, dito isso, pessoal, chegamos ao fim do episódio. Muito obrigada por se juntarem a nós hoje. Eu sou Cassidy Williams. Vocês podem me encontrar como Cassadoo, C-A-S-I-D-O-O, na maioria das plataformas. >> E eu continuo sendo Andrea Griffets, e vocês podem me encontrar como Colombia Dev na maioria dos lugares. Entrem em contato, por favor. Nos

41:27 digam. Sabe, nunca pedimos feedback. Contem o que acharam deste episódio. Odiaram? Mandem para seus amigos e seus inimigos >> e digam que adoraram. [risos] >> E, Samine, onde as pessoas podem encontrar você na internet? >> Vocês podem me encontrar como Samine Karim no Twitter ou escare no GitHub. >> Certo, pessoal. Até a próxima. Tchau, tchau. >> Tchau.

Transcrição original

[00:03] This is the GitHub podcast, a show dedicated to the topics, trends, stories, and culture in and around the open source developer community on GitHub. I’m Cassidy Williams, aka Cassadoo, and I am on the developer advocacy team at GitHub. And with me is my lovely co-host today, Andrea Griffiths. >> Hey, Cassidy. Hi, friends. I’m Andrea Griffith, senior developer advocate here at GitHub. >> We have a very exciting guest today. Are you excited, Andrea? I am >> I am super excited. I’ve actually recorded with him before. Um he is a

[00:34] legend around this part. Uh our amazing guest today is Samin Karim who is a senior product manager at GitHub and he is focused on developer workflows core review and he shipped my favorite thing that’s shipped absolutely which is stack pull request. He has a talk at GitHub universe coming up about stacked PRs in practice and how big pull requests slow you down and how to practically break them up. We’ll talk about this and more today and you can see us talk live in San Francisco on October 28th or register to see all of Universe and more

[01:06] online at githubuniverse.com. All that being said, hey Samine, how are you? >> Hey Cassie. Hey Andrea. Thanks for having me here. Super excited. >> We’re so excited to have you. So could you give people a little bit of background on how you got to GitHub? How you got to where you are today? >> Oh yeah. You know, I have been using GitHub for as long as I can remember since I started coding in middle school and I started in the startup world. spent some time in advertising, sold my

[01:36] last startup, uh worked at the acquirer for a little bit, and after that, I really was trying to think about what do I want to work on next, and I really fell in love with developer tools because it’s something that I used every day and started a startup in that area and eventually found my way to GitHub because what better place to make an impact on developer tools than the hub of all developer activity? And it’s just so exciting to be here at GitHub now being able to actually improve the lives of hundreds of millions of developers

[02:07] around the world. >> And your team is working on such cool practical things that developers really care about. I would love to honestly just do a deep dive into PR stacks. And for those who don’t know what they are, could you give just an overview and and how they have changed people’s workflows? >> Yeah, absolutely. So happy to give just a high level overview of what stacked PRs are, where kind of this started from, and especially why it’s more important today more than ever. So stacked pull requests, the idea behind it is you have a large set of changes.

[02:39] Maybe you’re you’re shipping a giant feature, you know, you have to make database migrations, API endpoints, front-end code. And normally the way that you would do this is either you would have one giant PR where you’d have, you know, maybe 10,000 plus lines of code and it would be very difficult for the reviewer and that probably would be sitting there for a while while you’re trying to make sure everything looks good. It’s this like big bang update or you’d have a series of sort of disconnected PRs. They’re not exactly tied together. They could kind of get

[03:10] lost. You have to be like, hey, like make sure you don’t merge this out of order. With stacked pull requests, it sort of streamlines that flow and gives you a very clear way to, as the name implies, stack your pull requests. So you have one PR for your database migrations, one for your API endpoints, one for your front-end changes, and it’s all stacked together. And what’s great is now it makes it really easy for you to manage this coordinated set of changes, but also avoids the the trap of having this giant PR with tens of

[03:42] thousands of lines of code that can take forever to review. So it’s easier for you to write and organize your code, but it’s also easier for the reviewers importantly uh to take a look at your changes and as I like to say help tell a story of the feature that you’re shipping. I love this feature so much because I have been in that world where I where I’ve had to say like, “Okay, don’t merge PRs B and C until A is done and make sure that you do this kind of rebase whenever you start reviewing B before you get into it.” And and like it

[04:13] ends up being such a mess logistically because you basically just have to explicitly say do this, please read this, read this. Um and so the fact that STAX kind of solves that problem and takes care of that is very nice. Yeah, I think it’s just one of those workflows that once you have used it, I think you will find all sorts of ways where it can supercharge your workflow, especially in this world where, you know, we’re using agents. We’re starting to work on larger changes all at once. And, [clears throat] you know, we’re doing so much more. It’s such a great way to sort

[04:44] of coordinate your workflow. And I think we’re seeing more and more developers figure out different ways to use stacks. And we’re super excited about it. I’m super excited about the cognitive load that this gonna help me kind of throw off like this promise of like smaller more focused reviews. Um at least for me I think even for projects where I am it like I’m the one that has to approve the entire stack. Um it’s made a big difference. >> Uh what’s something that you noticed I guess how has this changed the

[05:14] experience for people who are reviewing code now when they’re using stack PRs? Oh yeah. I think this is again going back to the sort of previous era where you just had one giant PR for your huge feature. Uh a very common thing especially like larger organizations. What could happen is you probably have code owners especially if you’re working in a mono repo and you have this giant PR. What ends up happening is you have multiple groups of code owners reviewing that single PR and it can get very

[05:45] complicated, very confusing and you got all sorts of threads you’re trying to manage and it can be very confusing for both the reviewer and the person who’s writing the code trying to figure out what’s going on and then as you’re making changes for everybody to follow along. The great thing about stacked PR is it breaks it up. So the way that I usually uh recommend folks to do uh stacking especially if they have like a large organization with code owner set up is to make sure each layer of the stack each PR targets one code owner. So

[06:16] again the database team or the API team or the front-end team or what have you. And what that really makes it easy is that that code owning team now has their like one individual slice where they know all they need to review and you can just have that like uh focused conversation with that team in that PR instead of having everybody trying to comment on one giant PR. This isn’t a new concept. This is this is something that that like we we have seen out in

[06:46] the industry that where it was an extension to GitHub or a tool on top of GitHub and stuff and >> there has been some commentary saying what took us so long. >> I would love to you to for you to go into what took us so long [laughter] >> to build. >> Yeah. you know, uh, there’s been a lot that is needed to be done to make stacked PRs work. And I think crucially, you know, there because there have been so many other sort of third-party tools

[07:17] and plugins to make it happen, you know, we didn’t want to just create another plugin. We really wanted to create an experience that felt native to GitHub and offered some really unique advantages. And we wanted to make sure that stacked PRs just worked, that there were no compromises, that you just say, I want to create a stack and you didn’t have to update all your configurations and your rules, your actions, configs, it just worked. We also wanted to make sure that it um sort of supported this

[07:48] ability to merge multiple PRs at once. I think uh for folks who’ve used stacked PRs, uh if you haven’t, highly encourage you to do so. Merging multiple PRs at once is actually uh extremely complicated especially when you’re dealing with squash merges and really high throughput repos where merges are happening sometimes multiple times a second uh and some of our like biggest customers. So it’s really important that we make sure that this just works properly. And so what we actually end up having to do is not only having to

[08:19] rewrite a ton of stuff across GitHub cuz you know PRs are in many ways the center of GitHub. Every other service that GitHub has sort of goes off of PRs. Uh but then also, you know, we need to make sure all of the the services that depend on it were updated as well. >> Making something native native into a platform is not an easy thing to do. It’s it’s it’s something they were you’re not only dealing with just different parts of the codebase but also legacy parts of the codebase. Do you know like what the oldest part of the

[08:49] codebase had to be updated for this cuz I’m sure there were so many different layers to go through. >> Oh yeah. I think uh you know the way a PR is merged that is in a lot of ways like merging a PR is very standard. I think glue are touching parts of the code that hadn’t been updated in at least a decade. And it’s one of those things that like PRs have been around for a long time. So, you know, if it works, like it’s solid and it’s like stable core code and we need to go in there and and edit that. Um, yeah, for the first time in in quite a while.

[09:21] >> It’s scary, >> but that’s Yeah, [laughter] that was terrifying. Sorry. Well, and I know that like the merge box alone is such complex code and and what what is the merge box for those who don’t know and please explain how complex that is because the more I learn about it, it it makes my head spin. >> Yeah, you know, I never as a developer, as an end user of GitHub, I never truly appreciated how complex the merge box was. And then now being on the other side, I have a very different uh view and appreciation for the merge box. So,

[09:53] for those of you who aren’t aware, the merge box, you know, at the bottom of PR, it tells you if your PR is ready to merge or not, which it sounds very straightforward when you think about it. It’s like, okay, like is it green? Is it red? Am I waiting for checks to finish? But there’s actually so much that happens behind the scenes because there’s of course like are your checks passing, are your bills passing? Uh do you have rules set up? Do you require an approval? And then of course, do you have conflicts? Do you need to resolve those conflicts? Are those conflicts automatically resol resolvable or do you

[10:24] need to do that in the command line? And there’s u hundreds of conditions that we evaluate for. And the other thing that people may not realize is that it live updates. So as someone pushes a commit to their branch or you know someone submits an approval in another tab, it live reloads and auto updates. So basically what we’re doing behind the scenes is you know backed behind GitHub of course is Git. There’s a giant series of servers that we have that are constantly running git operations. So

[10:56] every time anything changes we are basically running a simulation of a git merge and trying to see okay does this commit actually pass? Is it are there merge conflicts? Does it like pass all the rules? you know, you could get really complicated with like making sure that the resulting commit has certain metadata, is it signed, etc. We could go on and on. Uh, and so that was already complicated as it is and it is a very core part of GitHub. Uh but then you also have stacked PRs which now

[11:28] introduces another layer of complexity and dependencies because in order to merge a stack you essentially need to make sure not only that your current PR is good but that all the PRs below it are green as well. Uh so now you’re not only checking for the state of one PR but potentially up to 100 PRs. >> It goes so deep and the the the like ghost merge behind the scenes is the thing that blew my mind the most. I I just didn’t know that that is how that worked. And that is so much compute just

[11:58] to make sure something can be merged. It’s it’s really interesting. >> Yeah, it’s one of those things that again we really want to make this a seamless experience for the end user. So it’s not something people should have to think about because GitHub is just doing it behind the scenes. But it’s one of those things that when you are working on a a new feature like stacked PRs, it literally exponentially increases the complexity of something like that. And and those are the types of things that like we really need to make sure that

[12:28] not only do we did that properly to make sure like security uh is is in place, but also making sure it’s reliable and available as well. >> I love this. How did you go from like someone on the internet say they wanted this to actually make it happen? I actually started in GitHub in January. So by the time I joined the stacked PRs project was already uh sort of green lit and there was a lot of interest already that been building up behind stacked PRs. What I will say is that there’s actually been different attempts over

[12:59] the years at running stacked PRs in GitHub. This is actually I think the third or fourth attempt that we’ve >> I was going to say I saw there was an attempt in like 2022 at some point too. Yeah, I think there’s been various types of attempts, some that tried to approach this as a completely different concept, something outside of PR, something that was very much related to get refs and essentially will we end up with the current iteration and the reason why it worked is we decided to stick with the core PR model instead of breaking away

[13:31] from the PR model which you know has definitely its benefits but ultimately required so much rebuilding. that it just was too expensive and and too complicated, especially in in such a big system. >> With PRs, what we decided to do was sort of use the existing PR concept that we have today and allow you to group it and group it as stacks, but of course make sure it natively works with all of GitHub. So I think that was really one of the core architectural decisions that

[14:01] allowed us to move forward with stacked PRs in a uh more approachable way. >> Did that lead to any negative trade-offs besides just dealing with the mountain of legacy or was that just really the right decision that was clear over time? >> Yeah, I mean you’re we’re obviously taking an existing model of pull requests and we are overloading it to to some extent. uh like one of the one of the interesting things that we we have to change as part of stat pull requests is generally when you when you have a PR

[14:33] your PR has a base or a target and it’s assumed well you know that PR is going to merge into that target and there’s logic in a gajillion different services across the board that literally assume that with stacked PRs we kind of introduced this new concept where you can have a base of a PR uh for example like PR2 is targeting PR1 one, but the merge target is actually different because the merge target is your main branch. And so you could have all these different PRs where the bases don’t

[15:03] actually line up with their merge targets. Uh, and so that was a whole undertaking. That’s probably one of the biggest things that we had to cuz that was like a >> Yeah. >> Yeah. Because it’s not pointing at a branch, it’s pointing at a PR. >> Exactly. >> That’s a whole new data structure. Oh, I didn’t even consider that. [laughter] >> It was It was quite a huge undertaking. And so I think there were definitely like those are some of the the trade-offs that we had to make and we definitely had to go and make a bunch of new APIs, update a bunch of services.

[15:35] You know, one of the things that we had to do also as part of u you know stacked pull requests is that we had to create an entirely new merge path essentially. uh and that meant as part of that operation like the the existing APIs that we gave to our customers and to other platforms uh to merge PRs wouldn’t work because those APIs were synchronous and they would time out in 10 seconds and stacked PRs especially if you have a huge stack will definitely take longer than 10 seconds. Uh and so we had to create a new API that’s like

[16:06] asynchronous and so we had to you know ask folks to move over. So there were definitely a number of trade-offs that we had to make but I think ultimately sort of sticking with PRs even though it definitely is not perfect sort of gave us the best path forward that still you know used familiar concepts that users and platforms and you know agents are familiar with as well uh and then sort of applying this additional concept on top of instead of trying to rebuild something entirely. Yeah, I didn’t even

[16:38] consider that API end too. There there are so many things that you don’t think about until you have to think about it. And that’s why it takes so long. There’s there’s so much legacy and so many things to do. >> Oh, for sure. I mean, from the outside, most people are like, what’s you know, it’s just like show each other >> and merge them together. [laughter] Like I’m sure there’s a lot of folks that have a lot of misconceptions about how things work internally and everything that needed to be changed and updated to make this work and to make it not just to make it work though. And I appreciate you mentioned that earlier Sam that you

[17:09] wanted this to be like a uh just a part of the platform itself like a first first class citizen like first support not just tagged on as an extension or another tool or like a and it does feel like that. It feels like it’s very much part of of the pull request. um it just feels very native to the platform now. Um awesome. So for folks who already were using other things like they had other hacks or ways be it a an external

[17:40] plugin or they were they were making it work. Um I guess what’s one thing that they can expect now when they start using um stock PRs as it is now a part of the platform and you yourself I don’t know if before did you do you have a way that you were doing this before and now like is there anything that you can share about how that’s changed or what can people expect I guess to be the the biggest difference? >> Yeah. um for folks who are maybe who may be using these other tools and now sort of looking at GitHub stack PRs, I think

[18:12] one of the best things is that it’s natively integrated into GitHub. So when you’re looking at your PRs, you’ll be able to see all those PRs together. Uh and then some of the things that you maybe have had to do before that were a little bit hackier, you don’t need to do. For example, like I know a lot of folks would have to configure their actions, you know, CI runs to run on every PR instead of just the PRs targeting main or they would have to relax their branch protection rules because of the way that things worked.

[18:43] You don’t need to do that anymore. The way that we evaluate everything for stacks is that the protection rules, the CI configs, everything that you have that targets main is applied for every PR in the stack. So you can probably unwind maybe some of that those hacks or those workarounds you needed to have. Um the other thing that’s that’s really big is that you know we have a CLI that we’re shipping GH stack which allows you to work with stacks locally. >> Uh but also we have a public API that’s

[19:13] completely open and we’ve already seen a number of thirdparty plugins and tools and open source projects adopt using our our API. So if you don’t want to use our CLI, you don’t have to. that’s also like, you know, compared to some other products. So, you could build your own tool to do your own stacking. And I and it’s it’s very open and and I think that’s one of the the great things that I’m really excited about seeing is we have this open platform and we have a series of opinionated tools that we’ve built. But if you want to go build your own, you are welcome to do that. And

[19:44] honestly, I I would love to see that cuz that’s stuff that we can learn from and and maybe we’ll we’ll pull those into into GitHub as well. I think that’s a good misconception to address too where we aren’t building these features to squash competition or anything like that. We’re we’re doing it because they’re good ideas that we want everybody to have access to and build on. And so if you were using stacks in some other tool external to GitHub, now you not only don’t have to, but maybe those tools can be better in different

[20:15] ways because it’s natively built in and they don’t have to build their own workarounds. >> Absolutely. I think we’re all about developer choice around these parts and I love that. >> That’s right. >> I love that for us. >> Anything else that we can share about how like the sausage was made? Maybe that’s that’s one of the misconceptions or like the things that you didn’t expect to be like the biggest challenge once you actually got to work and like the internals of making this work. >> There’s one interesting thing I I’ll bring up which is uh so code owners is actually a really interesting one. So >> so code owners the concept is you

[20:46] actually pretty straightforward again like you have a code owners file that tells you who are the teams that own code review for a particular piece of the code um based off of the team that had the code in this directory or something like that. Now, with stacked PRs, this opened up this very interesting quirk that what you could do potentially is cuz your stack of PRs build on top of each other, you could make a change in your first your bottom PR that removes or changes the code

[21:17] owners so that when you went to write your second, third, fourth PRs, you kind of were able to get around the code owner review that was needed. So, it’s a little bit of a weird quirk that you could run into. And the way that we we solved it is that we basically ignored any changes to code owners in the middle of a stack. So, when you have a stack of PRs, we always load code owners from your main branch because that is the source of truth and we don’t want to

[21:48] allow people to kind of hijack code owners to kind of circumvent code review or do anything a little funny. >> I didn’t even think about that. [clears throat] Ah, sorry. [laughter] Go ahead. >> No, it’s it’s there’s again there’s just all of these different things and it that is like the level of detail that we sort of paid attention to as we you know of course we’re trying to make sure that this feature works. It’s easy to use but also for GitHub and PRs this is very much a security product as well. Of

[22:18] course, >> you know, enterprises rely on this to ensure that their code is is well reviewed, meets all the requirements and it is, you know, for folks who are doing SOCK 2 or ISO 2701 like those are really important things and that is where the uh code owners and all those like security considerations were really important for us. >> I love how much of development is how is someone going to try to break this? Yes, >> it’s fascinating to have to think about all of these different use cases where

[22:49] it’s like how can someone break our pristine system? >> And you know what’s even better nowadays is you can have agents uh do this as well. That’s something that we did actually quite extensively is we just uh had a swarm of agents that were just running around the clock trying to break the feature, trying to circumvent the rules, do all sorts of things. >> That’s a good test. >> They are they’re very crafty. They’re very resourceful and uh agentdriven testing. I think it’s it’s a new type of testing. We’ve always said test-driven development, but now I think there’s

[23:20] this new era of have the agents go at it and try and break it. And they they they have learned from all our creativity and uh they are they are relentless. >> Yeah. And they can do it without having to rest at night too. That’s Yeah, that’s that’s actually a really interesting way of just stress testing a system. I hadn’t thought of it that way. Very cool. Can we talk about who um I guess how teams are adopting stacks now? So like teams start adopting these workflows like we’ve seen online like

[23:50] folks was there were some folks that obviously lots of opinions um lots of people happy lots of people with you know their valid criticisms but >> yeah exactly but like for the teams that are adopting these workflows let’s let’s talk about one thing that they they sort of need to do I guess as a team is there a habit that they need to change is there a way that they need to look at the way that they’re building PRs that needs will adapt to this new new way of thinking and working or um and from the

[24:22] experiences that you’ve seen that how us internally have used them plus the early adopters any lessons learned that we can share so that folks have like an easier transition into stock PRs if they desire to. >> Yeah, that’s a great question. I think the easiest thing to do honestly is ask your agents. Uh we have a skill file. The agents are really good at breaking down, especially if you’re using plan mode. When you are asking your agent to

[24:54] plan this feature, make sure that the stack skill is installed and your agent will be able to go through it and use it to decompose your big plan into a stack of maybe a couple PRs. And what that’ll do is what we found is it helps sort of steer the agent to break up its code as well. Instead of again pushing up one giant PR with tens of thousands of lines of changes, it breaks it up. So it it you know logically each PR is like an

[25:26] atomic unit of change that is independently reviewable. And that really makes it much easier for even your code review agents, your human code reviewers when it comes time to merge that. I think is is huge. Uh for folks who are who are adopting stacked PRs and looking into it for the first time, I’d say look at the areas where I mean just go back through your PR history and look at places where you had a bunch of PRs that you know as Cassie was mentioning like where you’ve tagged them together like hey like maybe don’t merge this one

[25:58] just yet and you know like this one’s related to this but needs to merge after that one but not before this one. There are all sorts of cases where we do this. You know, database migrations or any sort of migration is a common example where you kind of have this like sequence of things that need to go out and stacked PRs are great for that. Uh if you’re working in a monor repo and you have all of your projects or your services within one repo and everything’s within different directories and other you got code

[26:29] owners, you got all this stuff set up. That’s another great use case for stacked PRs where you’re working on one feature but you have different changes throughout the repo. You can use stacks to break that up into sort of individual parts. And and the last thing I’ll say is is for stacks is it really is is up to you. Uh we’ve seen folks use stacks just to for their own personal development just to keep going there. You know if you’re using squash merge there’s actually like a really nice like rebase thing that squash uh squash merges and stacks do. So it just avoids

[27:01] you having to deal with merge conflicts if you’re squash merging a lot. So there’s a lot of ways in which even if you’re not necessarily working on a a sequence of things, stacks can be helpful. But generally speaking, again, the the concept I’ll go back to is a stack should tell the story of the feature that you’re building. And there’s literally like a little timeline view that you see on the PR page with each stacked PR. And what you really would like to do is for the reviewer or

[27:33] anyone who’s looking at that code later that looking at that timeline, looking at that list of PRs should tell them the story of what you’re trying to build. So in a quick glance, they can understand, okay, this is what is about about to ship. I feel like that kind of storytelling is more and more essential now in today’s day and age of agentic development where people are shipping so much if you don’t know the story an individual feature doesn’t matter and and so being able to have that timeline and and understand where things go. It’s

[28:04] it’s very good for understanding which is the thing that we need the most right now. >> I agree. I agree. Uh what about for open source projects like have you seen a lot of adoption? like have you had any feedback from maintainers about how this is maybe changed the way that they work with contributors be human or agents cuz they’ll be open in PRS too friends. [clears throat] >> Uh yeah, we’ve had a lot of open- source projects from Verscell uh Nex.js to NX to the React team and and many others

[28:35] homebrew uh using stacked PRs. We’re very excited to see the adoption there. One of the things that is still the limitation of stacked PRs that we are working on uh which is next up for us is support for stacked PRs across forks. This is one of the big requests from the community. >> So right now stacked PRs only works within a single repo but uh if you have a fork you can’t create a stacked PR. We are working on changing that. Again this is one of those things that is it’s there’s a lot of stuff involved. So,

[29:07] we’re working through it, but I’m very excited uh once we will release that. >> Yeah, just understanding again how how the base branch is different from the base PR and stuff. I can imagine across forks, it’s a whole other beast to tackle, but I’m so excited that that’s coming. >> That’s sweet. Oh, you bring us to a good place, a good moment in time to talk about what else is out there. you already done so much and like this has been like an incredible like long time coming and uh shout out to the teams that tried it before whoever that was in

[29:38] 2022 that gave it the last uh honest go plus everyone that’s been here working really hard on making this happen and having you join the mean and also like bring it home amazing uh this has definitely been a a great effort by the GitHub team long time coming happy it’s finally here what else is in the horizons before support for besides support for forks which I’m really excited about as well. >> Yeah. U as I mentioned with stacked PRs we had to create a whole new code path for merging. So one of the limitations

[30:08] that we do have for stacked PRs is that there are some features that are missing for stacked PR merges. Automerge we don’t have that bypassing rules and merge forks of course as we already talked about. So, those are things that we are working to uh include uh to bring stack merges up to par with regular PR merges. Uh but there’s there’s more that we’re uh we’ve just actually recently released. We just released the ability for rebases to create signed commits. Uh for those of you who are part of the the

[30:39] rebase uh force push gang, you know, I personally never used merge commits. I personally find merge commit my hot take. I I hate merge commits. I think they’re ugly. So, I personally love rebasing and force pushing. I like the linear uh history, but even regardless of that, I know a lot of folks have been asking for rebases to create signed commits cuz when you create a merge commit, it creates a signed commit on GitHub, but rebases don’t. And that is one of the things that stack rebases do create signed commits now, which if you

[31:11] have rules that require signed commits, it’s one of those things that again we have to dig back through and and redo a bunch of stuff, but it is here now. We’re super excited about it. Uh we just there’s a lot more we just need to do in general. Speaking of rebase force push to improve it in the PR experience, there’s a lot that has been built up in the PR experience over the years and outside of just stacks. We as a team are looking broadly at how people are writing code, how people are collaborating with their agents, with

[31:41] each other, and really redesigning the PR experience to be a lot faster, get you the information that you need, and just allow you to just move faster through the experience. Good. >> I love that. I love that. And actually bring me to the point of like developer choice which is my favorite song of the day here today but because you can use stack PRs across every surface on.com right so maybe tell us a little bit about what you can use it on the CLI uh you can use it the copilot app which is

[32:12] one of my most favorite new things because there is a CLI skill for it can you talk a little bit about why that was important to make sure that it was accessible everywhere >> yeah I I think we just want Again, stack PR is to be just a first class part of PRs in GitHub. And that means it just needs to work everywhere. The CLI, Copilot CLI, the GitHub Copilot app, the mobile app, Android, iOS, uh obviously github.com. >> And in order to make that happen, there

[32:42] was really just a lot that we had to do. We already talked about the models that we needed to change and whatnot, but ultimately again people are writing code from so many different places now. People are, you know, coding from their phone. They’re, you know, doing remote sessions with agents. And we just want to make it easy. And really again, even if you’re not using the co-pilot app or any of those tools, we have the skill file and you could point any agent uh regardless of the vendor at the skill

[33:12] file and it can create stacked PRs using either the CLI or the public API. So it’s meant to be very open and as Andrew you mentioned it’s all about developer choice and we just want to build the platform and any developers de regardless of their workflows they can figure out however they want to integrated with it. I love that so much and I I want to give like you and your team flowers because you’ve been working on this so hard and suddenly there were a lot of big spotlights on your team at at certain points as it got particularly

[33:44] viral on the various social medias that there was a team actually working on it and y’all did such a great job kind of cutting through the noise and just getting to the meat of it of making it open, making it secure and and just making it work on the platform. So again, huge kudos and and thank you for driving it home because that was no small feat. >> All the flowers, all the flowers to you and the team. [laughter] >> Thank you. And I I have to uh pass that on to all of our customers, our users,

[34:16] all the developers who were part of the beta, who were asking for it. I mean, first off, the reason that Stack PRS was prioritized, the reason it got done is because the community kept asking for it, and I know folks have been asking for it for a really long time. Um, and it took a while, but we did it. And it’s not the end. There’s a lot more that we need to do, and we really rely on the community’s input and feedback. And I know it could be a lot. There’s a lot that’s going on, but it really like we really do listen to that. We spend a lot

[34:47] of time on all the platforms and discussion posts and everything really listening to what folks are are saying because we want to make the platform better and we can’t do that without the input and feedback from folks and it really is a partnership between us and the developers and the community >> for sure. >> I love that and a continue partnership right like the the things chip but that you’re still as you continue to grow and I love it. folks sometimes find like the most unique um edge cases that they’re like so

[35:17] >> and what a pleasure that is. >> Yeah. >> That being said, we are getting to the end of our time here. So before we go, we all have various open- source projects and things that we would like to share. And if y’all don’t mind, I will go first. So the link that I’ll share, and these links are all in the show notes, um is a project by Sarah Drazner. She is a distinguished engineer over at Google and in a previous life before she went into tech she was a scientific illustrator and she’s kind of combining her tech skills and her illustration skills to make visual

[35:49] explorations of code. And so if you go to her website and again the URL is in the show notes sarah.dev/projects dev/ projects. You can see her code drawings and she goes very deep into how MCP works in practice or the differences between GPUs and CPUs or vector databases or just various types of software architecture. And it’s really cool to see that visually explained. And she’s also just a really talented artist and this was her actual job before going

[36:19] into the tech industry. And so it’s a very cool mashing of skills that also can teach you something. And so that is that is my pick for this episode. >> I love that. I am a big fan of Sarah like embarrassing. So um and also I am a big visual learner. Like I love it when people draw me things to explain things to me. [laughter] I am excited for this project. I have to check it out. That’s awesome. Awesome. I’ll go next. Um, I’m going to shout out a classic, a new classic, and it’s

[36:50] agents.md. Did you know that that is an actual open source project, right? Uh, and what agents is all about? Well, >> those setup commands that get buried in like your read mess, like the tests that like nobody ever runs, >> the rules that you know, you don’t really they live in your head, I guess, but they they need to live on a file. Um, but they don’t necessarily belong in PRs. So all of that context that your coding agent needs regardless of the coding agent of the provider uh most of the times they don’t really know where

[37:20] to find it right like they only have access to what we tell them and so agents.md gives repose that obvious place to put it uh it is a standard it’s a standard in the industry has aligned and decided that is the way to work with agents uh and it’s also an open source project itself under the Aif a AIF foundation so uh you can find the project itself under github.com/ SL aents MD/agents.mmd. Um, I love this. It’s a boring standard that works. It’s open. And

[37:51] >> boring standards are the best standards. >> Exactly. Exactly. And anything that can help like your agents make fewer assumptions and like just go make stuff up that you know is not going to work for your project. Uh, it’s going to be awesome. So, uh, check it out if you haven’t started the project and if you have feedback or actually are interested in the way that agents MD can get better. uh open an issue. >> Sam mean what did you bring for us today? >> Well, maybe this is cheating a little bit, but I do have to shout out the GH stack CLI.

[38:22] >> Ooh, yes. So good. >> The the stack CLI is is one that uh there’s there’s a funny story behind it. So, as we were starting working on the stacked PRs project, we actually were not really planning on a CLI. It was well, maybe it’ll be like something more lightweight. And as I sort of started working with folks, I was like, we we really do need a CLI. And uh as a product manager, I was like, well, you know, I’m probably not going to be the one building this, but I’m going to start just putting together some some scripts, some some things to just help,

[38:54] you know, create some issues and tickets. And so I had a series of bash scripts on my computer that I was like, “Yeah, this is how we could, you know, do run a cascading rebase or here’s how we could sort of, you know, manage a stack locally.” And that that those scripts just kept building and building and building. And then I I wrote a series of of basically documentation for the CLI to share it with customers and early users and be like, “Hey, like does this seem like the you know, does this have all the commands? Would this have

[39:24] all the things that you would like need?” And people like, “Yeah, we have feedback or this or that.” Um, but ultimately I was like, you know, this is really hard to get feedback on this if it’s just documentation. And I was like, you know what? I’m just going to go ahead and and start building it. And so I just started started building the the CLI and it went from something that was written completely in in bash to I rewrote it in Go uh which is actually what the main GH CLI is is written in as well and has turned into this behemoth that does local stack operations that

[39:55] can of course push up and create your stack PRs. has all these tuies, these cool graphical interfaces in your terminal for viewing a stack that for uh submitting a stack of PRs, for modifying a stack. I had a lot of fun with those for sure. Uh but would definitely, you know, encourage folks to like check it out, especially if you know, again, it’s open source, so feel free to fork it. Uh leave your uh suggestions, file an issue. There’s a lot I I I have on my road map that I want to continue to improve there. And again, would really

[40:26] love a bunch of feedback on it because it’s one of those things that we really want to make it a core part of the STAX experience and there’s a lot more that I know we want to do and it I had a lot of fun building it. >> It’s a gorgeous CLI. Like it is you’re just like, “Oh yeah, no big deal. I just rewrote it all in Go and now it’s a spectacular CLI tool that people are using.” the fact that you can rearrange your stack or remove something in the middle, add something at the end, it’s it’s so well done and looks so good for

[40:57] a terminal user interface. I I was so impressed with it the first time I tried it and so don’t be humble. It’s an it’s an awesome CLI tool. >> Thanks. >> Okay, that being said, everybody, we’ve made it to the end of our episode. Thank you so much for joining us today. I have been Cassidy Williams. You can find me at Cassadoo C A S I D O O on most things >> and I still am Andrea Griffets and you can find me at Colombia Dev in most places. Uh please reach out. Let us

[41:27] know. You know, we never ask for feedback. Let us know how you like this episode. Did you hate it? Send it to your friends and your enemies >> and say you love it. [laughter] >> And Seamine, where could people find you on the internet? Uh, you can find me at Samine Karim on Twitter or escare on GitHub. >> All right, y’all. We’ll see you next time. Bye bye. >> Bye.