GitHub fixa visualizações salvas dos Issues a um clique

Em 20 de agosto de 2026, o GitHub tornou geralmente disponível a fixação de visualizações salvas na barra lateral dos Issues de repositórios. O changelog oficial do GitHub confirma que as visualizações mais usadas ficam a um clique mesmo quando a barra lateral está recolhida.

A disponibilidade geral desde 20 de agosto também é descrita por uma cobertura independente da atualização. Na prática, filtros recorrentes de bugs, tarefas e revisões podem permanecer no próprio ambiente de triagem, sem que a consulta precise ser reconstruída a cada rodada.

O que muda com a visualização fixada

A novidade encurta o acesso a um recorte já configurado; ela não duplica issues nem modifica estado, responsável, rótulo ou prioridade. A visualização determina quais itens aparecem, enquanto a fixação transforma esse filtro em um atalho permanente na barra lateral do repositório.

Quando o atalho é aberto novamente, a consulta apresenta os itens que correspondem às condições naquele momento. Uma fila de bugs recentes, por exemplo, passa a incluir novos registros compatíveis sem que a equipe tenha de criar outra visualização.

O recurso deve ser distinguido dos favoritos do navegador e da fixação de uma issue individual. O objeto fixado é uma consulta salva: um caminho reutilizável para uma seleção dinâmica de issues ou pull requests.

Como criar, fixar e reutilizar

As visualizações são criadas a partir de consultas com filtros avançados. No painel geral de Issues, o controle ao lado de “Views” abre o formulário para informar título, descrição, ícone e a expressão de busca; depois, “Save view” grava a configuração. A documentação de visualizações do GitHub também informa que esse painel aceita até 25 visualizações salvas e que is:pr inclui pull requests no resultado.

Depois de salva, a visualização pode ser aberta pela seção “Views”. O menu ao lado do nome permite editar, duplicar ou excluir a configuração. Nas páginas de Issues de repositórios, a visualização escolhida pode ser fixada na barra lateral para acesso com um clique.

Há uma diferença de escopo importante: o limite de 25 citado na documentação refere-se ao painel geral de Issues, usado para acompanhar itens de vários repositórios. O anúncio de 20 de agosto trata da fixação na barra lateral de um repositório e não publica um limite separado para a quantidade de atalhos fixados.

Nomes específicos ajudam a evitar interpretações erradas. “Bugs recentes — 7 dias” identifica melhor o período do que apenas “Bugs”; “PRs aguardando minha revisão” deixa claro que o resultado depende da conta conectada.

Quatro consultas para a triagem diária

As expressões abaixo são modelos ajustáveis. Os rótulos bug e blocked precisam existir com esses nomes no repositório; equipes que usam outra taxonomia devem substituir os valores.

• Bugs recentes: is:open is:issue label:bug created:>@today-7d sort:created-desc. A consulta seleciona issues abertas com o rótulo “bug”, criadas na última semana, e coloca as mais novas primeiro.
• Issues atribuídas a mim: is:open is:issue assignee:@me sort:updated-desc. O recorte reúne itens abertos atribuídos à conta conectada e prioriza os atualizados mais recentemente.
• Bloqueios em aberto: is:open is:issue label:blocked sort:updated-desc. Se os bloqueios forem registrados por outro rótulo ou campo, esse critério precisa ser adaptado.
• Pull requests aguardando minha revisão: state:open is:pr user-review-requested:@me. A expressão busca pull requests abertos com uma solicitação de revisão dirigida à conta conectada.

Cada consulta responde a uma pergunta operacional diferente. Separar bugs novos, trabalho atribuído, impedimentos e revisões evita uma fila única na qual itens com responsáveis e ritmos distintos competem pela mesma atenção.

Para reutilizar um modelo, basta inseri-lo em “Query”, ajustar os rótulos ou o período e salvar a visualização com um nome descritivo. A fixação deve ser reservada aos recortes consultados com frequência; as demais visualizações continuam disponíveis em “Views”.

Outras mudanças no mesmo lançamento

O pacote de 20 de agosto também passou a exibir avatares nas reações de issues, adicionou um controle de densidade ao painel e permitiu ocultar sub-issues fechadas. A densidade altera a quantidade de informação visível de uma vez, enquanto a ocultação reduz a presença de trabalho concluído durante a leitura da fila.

Os avatares identificam quem reagiu a uma discussão, mas uma reação não equivale automaticamente a aprovação formal, atribuição ou mudança de prioridade. O lançamento também fez os endpoints REST de dependências blocked_by, blocking e relates_to filtrarem resultados conforme o escopo concedido ao token.

O estado confirmado é de disponibilidade geral desde 20 de agosto de 2026, não de prévia. O GitHub não detalhou no anúncio um teto próprio para visualizações fixadas; o que está documentado é o acesso de um clique aos filtros salvos na barra lateral, inclusive quando ela permanece recolhida.