O GitHub anunciou em 23 de outubro um app consolidado no Teams, reunindo notificações e Copilot. O aplicativo legado será renomeado GitHub (deprecated) e retirado em 16 de novembro de 2026.

Quem usa GitHub notifications deve atualizar o aplicativo. Quem usa o app legado deve instalar o consolidado. O fluxo descrito começa com uma notificação de issue: a equipe menciona @GitHub, o agente propõe a correção em uma pull request e as pessoas revisam, testam e fazem o merge.

O que muda para quem já usa a integração

A novidade é a consolidação dos pontos de entrada e o prazo de migração. O Copilot já estava presente no Teams, como mostramos na cobertura anterior sobre contexto de conversas.

Na análise da MnzAI Labs, juntar aviso e ação pode diminuir a distância entre perceber um problema e organizar sua investigação. Mas uma conversa curta também pode omitir condições importantes: onde a falha acontece, como reproduzi-la e qual comportamento seria correto.

Por isso, a qualidade do pedido continua sendo parte do trabalho de engenharia. Uma issue precisa não se torna dispensável quando o pedido pode começar no chat.

O que conferir antes da retirada do app antigo

Nossa proposta é tratar a migração como uma mudança operacional pequena e verificável:

  • Identificar qual aplicativo está instalado e quem responde por sua administração.
  • Escolher uma tarefa de teste com escopo e resultado esperado claros.
  • Conferir a conta vinculada e o repositório usado antes de solicitar alterações.
  • Verificar se a PR permite rastrear o pedido e compreender o que foi modificado.
  • Confirmar que notificações relevantes continuam chegando após a mudança.

Esses são critérios editoriais de validação, não uma afirmação de que todos esses pontos migram automaticamente.

A conversa inicia o trabalho; a PR permite avaliá-lo

Uma correção sugerida ainda precisa ser examinada à luz do código e dos testes. O ganho potencial está em preservar o encadeamento entre problema, tentativa de solução e decisão de aceitar a mudança.

Abrir uma PR é produzir uma proposta revisável, não comprovar que a falha foi resolvida.

Para os responsáveis pela plataforma, a prioridade imediata é reconhecer a instalação atual e preparar a transição antes de 16/11. Para os times, o teste útil é acompanhar uma tarefa até a revisão final e observar se a integração reduz esforço sem tornar a decisão menos clara.

Fonte oficial em inglês. Anúncio de 23/10; checagem editorial em 24/10/2026. Capa conceitual, sem reproduzir a interface do produto.