DEV Community: Felipe Augusto

Como usar git-filter-repo para remover arquivos e segredos do histórico Git

Felipe Augusto — Sat, 21 Mar 2026 11:05:59 +0000

Como usar git-filter-repo para remover arquivos e segredos do histórico Git

Quando um arquivo sensível ou uma chave vaza para o repositório, apagar o arquivo no commit atual não resolve o problema. O conteúdo continua acessível no histórico do Git. Nesses casos, a abordagem correta é reescrever todo o histórico do repositório.

Hoje, a ferramenta mais recomendada para esse tipo de limpeza é o git-filter-repo, inclusive apontada como substituta do antigo git filter-branch. O projeto exige Python 3.6+ e Git >= 2.24.0, e a versão publicada no PyPI no momento é a 2.47.0, liberada em 4 de dezembro de 2024 (o que consideramos ser bastante estável)

Neste artigo, vou mostrar como:

verificar se o Python está pronto no Windows;
instalar o git-filter-repo;
apagar arquivos do histórico;
substituir segredos no histórico;
publicar a nova árvore de commits;
orientar o restante do time após o rewrite;
conectar isso com um fluxo de prevenção usando Gitleaks no GitHub Actions.

Também deixo no final um vídeo seu no YouTube que complementa esse processo.

1. Verificando a versão do Python

No Windows, um jeito simples de listar as versões instaladas é:

py -0

O git-filter-repo requer Python 3.6 ou superior como já falamos.

Se você não tiver uma versão compatível, instale uma versão atual do Python antes de continuar. A própria documentação do projeto observa que usuários Windows às vezes enfrentam problemas com aliases do Python e, nesses casos, pode ser necessário executar o script explicitamente com o interpretador Python.
Entenda esse alias, como as configuração da variável de ambiente para o path de onde o python esta instalado.

2. Documentando a instalação do git-filter-repo

A página oficial do pacote no PyPI é a referência mais prática para documentar a versão e a instalação do git-filter-repo. No momento, ela mostra a versão 2.47.0 e o comando base:

pip install git-filter-repo

No entanto, a documentação oficial do projeto destaca instalação via pipx ou uv tool como caminhos recomendados para o pacote PyPI. Exemplo com pipx:

pipx install git-filter-repo

Se você quiser apenas validar a instalação depois, pode testar:

git filter-repo -h

Se no seu ambiente Windows o comando git filter-repo não funcionar diretamente, a própria documentação sugere chamar o script pelo Python:

python git-filter-repo --help

3. Antes de mexer no histórico: clone limpo e cuidado com impacto

Reescrever histórico não é uma operação trivial. Ela altera hashes de commits, branches e tags reescritas. O git-filter-repo tem inclusive uma checagem de segurança voltada a uso em clone “fresco”, e o uso de --force serve justamente para contornar esse bloqueio quando você sabe o que está fazendo.

Por isso, a boa prática é:

trabalhar em um clone separado;
confirmar exatamente o que deve ser removido;
avisar o time antes do push forçado;
publicar a limpeza;
orientar todos a sincronizar novamente o repositório local.

4. Descobrindo em que commit um arquivo entrou

Quando o problema é um arquivo grande, um artefato indevido ou um ZIP versionado por engano, vale primeiro descobrir onde ele apareceu no histórico:

git log --all --full-history -- "caminho/do/arquivo.zip"

Esse comando ajuda a localizar os commits relacionados ao arquivo, entender o impacto da limpeza e até documentar o incidente.

5. Apagando um arquivo de todos os commits

Se a necessidade for remover completamente um arquivo do histórico, o comando é:

git filter-repo --path "caminho/do/arquivo.zip" --invert-paths

As vezes vc pode ter problema no path, colocando um ./ na frente ou não - então por vezes vai precisar fazer mais de uma vez ate vc acertar - mas isso é um erro seu e não do pacote. Alerto sobre isso pq eu que uso muito o PowerShell Core, ao usar o tab para completar os caminhos path, o terminal pode fazer esse erro de colocar um ./ ou inverter uma barra, o que pode prejudicar a execução do comando - portanto tenha atenção nisso.

A lógica é simples:

--path indica o caminho afetado;
--invert-paths diz para remover esse caminho e manter o restante.

Se o problema for uma pasta inteira, o raciocínio é o mesmo. Exemplo:

git filter-repo --path "storybook-static/" --invert-paths

6. Gerando análise antes ou depois da limpeza

Um comando muito útil para inspeção é:

git filter-repo --analyze --force

Ele gera relatórios dentro de .git/filter-repo/analysis, o que ajuda a entender melhor paths, blobs e objetos do repositório.

Esse comando é especialmente útil quando:

você quer descobrir arquivos grandes;
suspeita de lixo histórico;
quer investigar quais caminhos mais pesam no repositório;
precisa de uma visão mais segura antes de sair removendo coisas.

7. Substituindo segredos do histórico com arquivo `.gitfilter`

Quando o problema é uma chave, token, senha ou segredo hardcoded, você pode usar --replace-text.

Exemplo de arquivo .gitfilter:

389123yunfg34iug348r739ht==>**REMOVIDA**

Depois, execute:

git filter-repo --replace-text .gitfilter --force

Esse processo percorre o histórico reescrevendo o texto encontrado. Para incidentes de segredo exposto, isso é muito útil porque você não precisa necessariamente remover o arquivo inteiro; em alguns cenários, basta substituir o valor comprometido.

Um ponto importante sobre arquivos começando com ponto

Aqui vale uma correção conceitual importante: arquivos com . no nome, como .gitfilter, .env ou .gitignore, não são “por definição” arquivos que não devem ser versionados. No Unix e em vários ambientes, eles são apenas arquivos “ocultos” por convenção. Alguns devem sim ser versionados, como .gitignore, .editorconfig e muitos arquivos de configuração do projeto. Outros, como .env, muitas vezes não devem. Então a regra prática é: sempre confira o .gitignore e a política do projeto antes de decidir. Isso evita transformar uma convenção em regra absoluta.

8. Exemplo completo de fluxo

Um fluxo simples para um incidente comum pode ser:

Caso A: apagar um arquivo indevido do histórico

git log --all --full-history -- "caminho/do/arquivo.zip"
git filter-repo --analyze --force
git filter-repo --path "caminho/do/arquivo.zip" --invert-paths
git remote set-url https://<URL_DO_REPO>.git
git push origin --force --all
git push origin --force --tags

Caso B: substituir um segredo vazado

Crie o arquivo .gitfilter:

chave-antiga==>**REMOVIDA**

Depois rode:

git filter-repo --analyze --force
git filter-repo --replace-text .gitfilter --force
git remote set-url https://<URL_DO_REPO>.git
git push origin --force --all
git push origin --force --tags

9. Publicando a nova árvore de commits

Depois da limpeza, é necessário enviar a nova história para o remoto:

git push origin --force --all
git push origin --force --tags

Esses comandos forçam a atualização das branches e tags reescritas. Isso é esperado, porque os hashes dos commits mudam quando o histórico é alterado.

10. O que o restante do time precisa fazer depois

Depois de um rewrite desses, o time precisa sincronizar o ambiente local com a nova história. Um fluxo objetivo para a branch principal é:

git fetch origin
git checkout main
git reset --hard origin/main
git clean -fd

Esse conjunto de comandos:

busca a nova referência do remoto;
muda para a branch principal;
alinha o histórico local exatamente ao remoto;
remove arquivos e diretórios não rastreados.

Em alguns times, também vale orientar as pessoas a recriar branches locais derivadas de commits antigos, porque qualquer branch baseada na história anterior pode carregar referências inválidas ou até reintroduzir conteúdo removido.

11. Relacionando isso com Gitleaks no GitHub Actions

Limpar o passado é importante, mas o ideal é impedir reincidência. É aí que entra o Gitleaks.

O Gitleaks é uma ferramenta para detectar segredos em repositórios Git, e a ação oficial para GitHub Actions permite rodar varredura em pushes e pull requests.

Exemplo:

name: gitleaks

on:
  pull_request:
  push:
  workflow_dispatch:

jobs:
  scan:
    name: gitleaks
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Run Gitleaks
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

A conexão entre as duas ferramentas fica muito clara:

git-filter-repo corrige o passado;
Gitleaks ajuda a proteger o futuro.

Uma abordagem madura é usar os dois: primeiro saneia o histórico, depois adiciona validação contínua no pipeline para evitar que novos segredos cheguem ao repositório novamente.

Para conhecer mais sobre o projeto Gitleaks, acesse:

https://github.com/gitleaks/gitleaks

12. Erros comuns e observações práticas

Usar `--force` sem entender o impacto

O --force existe porque reescrever histórico é destrutivo e o git-filter-repo tenta evitar acidentes. Use apenas quando estiver operando em um clone seguro e com plano de comunicação ao time.

Achar que apagar no commit atual resolve

Não resolve. O arquivo ou segredo continua acessível em commits antigos.

Esquecer as tags

Se você só der push forçado nas branches e esquecer as tags, parte do histórico antigo ainda pode permanecer referenciada.

Não orientar o time

Esse é um dos pontos mais negligenciados. Sem alinhar o procedimento pós-rewrite, alguém pode fazer push de uma branch antiga e reintroduzir o problema.

Tratar dotfiles como regra universal

Nem todo arquivo iniciado por . deve ficar fora do versionamento. Isso depende da função do arquivo e da estratégia do repositório.

13. Vídeo complementar

Você também pode complementar a leitura com este vídeo no YouTube, que fala justamente sobre detecção de chaves commitadas e limpeza do histórico:

Learn how to detect committed keys in Git and how to clear the history to solve the problem

https://www.youtube.com/watch?v=HzfK3MZ1UpE

Conclusão

O git-filter-repo é hoje uma das formas mais seguras e práticas de reescrever histórico Git para remover arquivos indevidos e dados sensíveis. Ele é especialmente útil em dois cenários muito comuns:

quando um arquivo grande, ZIP ou pasta de build foi versionado por engano;
quando uma chave, token ou segredo foi commitado.

O fluxo ideal costuma ser:

identificar o problema;
analisar o histórico;
remover o path ou substituir o texto;
forçar push de branches e tags;
alinhar o time para resetar os clones locais;
adicionar Gitleaks no GitHub Actions para evitar recorrência.

Isso transforma um incidente pontual em uma melhoria real de governança do repositório.

Como Configurar Multiplas Contas do Git na sua Máquina Usando o Arquivo .gitconfig

Felipe Augusto — Fri, 20 Jun 2025 19:57:49 +0000

Um Desenvolvedor, Várias Identidades

Imagine um desenvolvedor que atua em diversos projetos em alguns clientes e está fazendo um curso (faculdade, mestrado ou qualquer tipo de curso) e também tem diversos projetos pessoais que sempre versiona no seu GitHub pessoal (se identificou com esse cenário). Cada uma dessas frentes exige uma identidade diferente no Git, certo?

Em um certo momento, esse desenvolvedor percebe que estava enviando commits do projeto corporativo com o e-mail pessoal, misturando identidades e gerando confusão tanto para ele quanto para seus colegas do trabalho, do curso e em seus projetos pessoais. Foi então que decidiu resolver isso com uma abordagem mais elegante e automatizada: usando o arquivo .gitconfig para configurar perfis por pasta de projeto.

Neste artigo, vamos explorar como configurar múltiplas identidades no Git de forma eficiente, com base em um cenário real. Se você também vive entre múltiplas contas, continue lendo para entender como o Git pode trabalhar a seu favor.

Entendendo a Estrutura do .gitconfig

O Git permite configurar suas preferências em três níveis:

Global: Aplica-se a todos os repositórios do usuário. Normalmente salvo em ~/.gitconfig no Linux/macOS ou C:/Users//.gitconfig no Windows.

Local: Específico de um repositório, salvo no arquivo .git/config dentro do próprio repositório.

Sistema: Configurações que afetam todos os usuários da máquina.

Neste artigo, vamos focar na configuração global com inclusões condicionais, que é uma forma poderosa de alternar configurações com base no diretório do projeto.

O Cenário: Três Contextos, Três Perfis

Os projetos estão organizados da seguinte maneira:

Projetos da empresa: C:/Proj/EmpresaX/

Projetos acadêmicos: C:/Proj/Academico/

Projetos pessoais: qualquer outro diretório da máquina

Cada contexto precisa de uma identidade Git diferente. Veja abaixo a estrutura de um exemplo de .gitconfig global e como ele resolve esse desafio.

[init]
    defaultBranch = main

[includeIf "gitdir:C:/Proj/canaldeploy/**"]
    path = C:/Users/<usuario>/.gitconfig-canaldeploy

[includeIf "gitdir:C:/Proj/Academico/**"]
    [user]
        name = Nome Exemplo
        email = usuario.academico@email.com

[user]
    name = Nome Exemplo
    email = usuario.pessoal@email.com

[http]
    sslverify = false

Explicando o Arquivo Passo a Passo

Definição do Branch Padrão

[init]
    defaultBranch = main

Define que todos os novos repositórios iniciados terão o branch principal como main.

Inclusão Condicional por Caminho

[includeIf "gitdir:C:/Proj/canaldeploy/**"]
    path = C:/Users/usuario/.gitconfig-canaldeploy

Sempre que o Git for utilizado em um repositório dentro desse caminho, ele incluirá as configurações do arquivo .gitconfig-canaldeploy, permitindo isolar nome, e-mail, credenciais e chaves SSH corporativas (mas não vamos abordar chaves ssh nesse artigo)
Abaixo, segue o conteúdo do arquivo .gitconfig-empresax

[user]
  name = Felipe Augusto
  email = felipe.augusto@canaldeploy.com.br

Configuração Direta para Projetos Acadêmicos - Caso não queira criar multiplos arquivos, é possível fazer a configuração dentro do próprio .gitconfig

[includeIf "gitdir:C:/Proj/Academico/**"]
    [user]
        name = Felipe Augusto
        email = felipe.augusto@academico.com

Nesse caso, não é usado um arquivo externo, mas sim a configuração embutida diretamente dentro do includeIf.

Identidade Padrão

[user]
    name = Felipe Augusto
    email = felipe.augusto@pessoal.com

Aplica-se a todos os outros diretórios que não se encaixam nas condições anteriores. Representa o perfil pessoal.

SSL e Safe Directory

[http]
    sslverify = false

Desabilita a verificação de SSL, útil em ambientes corporativos com proxies.

Como verificar se a configuração está correta

Abra um terminal dentro de cada projeto e execute:

git config user.email

Isso retornará o e-mail em uso naquele diretório, confirmando se a identificação está correta.

Se quiser ver todas as configurações que estão sendo aplicadas:

git config --list --show-origin

Considerações Finais

Configurar corretamente os perfis do Git evita confusão de identidade e dor de cabeça para resolver esses problemas, que apesdar de simples, podem demorar algumas horas para serem resolvidos. Além de manter seu histórico de commits limpo e profissional.

Com poucos blocos de código, você pode tornar seu ambiente Git inteligente, responsivo ao contexto e livre de erros comuns.

Com essa abordagem, qualquer pessoa pode aproveitar o poder do .gitconfig para atuar em múltiplos contextos sem dores de cabeça. Basta planejar, configurar e versionar com tranquilidade.

Gostou dessa dica?

Temos outras muitas no canal DEPLOY

Retorno de validações semânticas em API Rest

Felipe Augusto — Tue, 26 Mar 2024 19:36:47 +0000

Em um mundo cada vez mais conectado, as APIs desempenham um papel crucial na troca de informações entre sistemas e na construção de aplicativos robustos e interconectados. No entanto, à medida que a complexidade das aplicações e das interações entre sistemas aumenta, surgem desafios relacionados à integridade e à consistência dos dados transmitidos por meio dessas interfaces.

Um aspecto fundamental para garantir a qualidade e a confiabilidade das APIs é a capacidade de lidar com erros semânticos nos dados fornecidos pelas requisições. Estes erros, muitas vezes negligenciados, podem comprometer a integridade dos dados e afetar a funcionalidade geral do sistema. Neste artigo, exploraremos o que são os erros semânticos dos dados em APIs, como eles podem surgir e como podem ser mitigados.

O que são erros semânticos?

Erros semânticos nos dados fornecidos referem-se a problemas relacionados ao significado ou à interpretação dos dados enviados em uma requisição para a API. Enquanto erros de sintaxe são detectados facilmente através de verificações formais, erros semânticos exigem uma compreensão mais profunda do contexto e das regras de negócio envolvidas.

Exemplos de erros semânticos:

Em uma API de gerenciamento de usuários, tentar cadastrar um usuário com um endereço de e-mail já existente no sistema.
Em uma API de reservas de hotel, tentar fazer uma reserva para uma data que já passou.
Em uma API de e-commerce, tentar adicionar um produto ao carrinho com uma quantidade maior do que a disponível em estoque.

Detectando e tratando erros semânticos:

A detecção de erros semânticos nos dados fornecidos é essencial para garantir a integridade e a consistência dos sistemas. Isso geralmente é feito por meio de validações em código implementadas na API, que verificam se os dados fornecidos estão em conformidade com as regras de negócio estabelecidas.

Quando um erro semântico é detectado, a API deve retornar uma resposta adequada, geralmente utilizando códigos de status HTTP como o 422 "Unprocessable Entity". Além disso, é importante fornecer informações claras sobre o erro ocorrido, para que o cliente possa corrigir os dados e reenviar a requisição.

Na imagem abaixo, podemos analisar que, ao tentar inserir um registro (linha 74) é retornado dentro do DTO uma lista de possíveis erros (variável item).
Caso a operação de InsertAsync retorne algo, sera retornado o Http Status Code 422 (linha 79) com todas as msgs de validação de negócio (validação semântica)

Veja a execução e o retorno:

Então ao enviar um request com:

Nome em branco
Peso igual a zero.

Vamos obter o resultado da validação de semântica e o Http Status Code 422.

Plus sobre o artigo ...

Neste artigo não vou explicar como estamos construindo as validações, mas vou deixar um print aos curiosos.
Quem quiser, pode entrar em contato que posso explicar com mais profundidade:

Conclusão:

Erros semânticos nos dados fornecidos são uma parte inevitável do desenvolvimento de APIs, mas são cruciais para garantir a integridade e a consistência dos sistemas. Ao compreender e tratar adequadamente esses erros, os desenvolvedores podem construir APIs mais robustas e confiáveis, proporcionando uma melhor experiência para os usuários e garantindo o funcionamento correto das aplicações.

Link úteis:

Como instalar o componente buildx no docker

Felipe Augusto — Fri, 29 Dec 2023 13:31:01 +0000

Nos últimos meses o docker começou a alertar sobre a descontinuação do processo de build utilizando o comando docker build e a mesagem abaixo sempre é exibida ao utilizar o comando.

Nesse post quero apresentar como instalar o plugin buildx para que seu docker fique mais aderente ao novo modelo de build, isso inclui a atualização da sua linha de comando para construir suas imagens.

Vale ressaltar que o meu comando para gerar minhas imagens é:

docker build -f ./src/DEPLOY.Cachorro.Api/Dockerfile -t felipementel/cachorro.api:local ./src

Agora vamos aos comandos para poder começar a fazer nossa instalação

Atualize a versão do Ubuntu/WSL-2 (Para outras distros os comandos para atualização podem ser diferentes pois o gestor de paotes talvez não seja o apt)

apt-get update -y && apt-get upgrade -y

Para o exemplo, estamos utilizando a versão 0.12.0. Caso queira utilizar outra versão, verifique a lista no site https://github.com/docker/buildx/releases e adapte os comandos abaixo para a sua versão

Faça o download do pacote utilizando o cURL

curl --silent -L https://github.com/docker/buildx/releases/download/v0.12.0/buildx-v0.12.0.linux-amd64 -o buildx-v0.12.0.linux-amd64

Conceda as devidas permissões para o arquivo

chmod a+x buildx-v0.12.0.linux-amd64

e pasta de destino

chmod +x ~/.docker/cli-plugins/

Movimente o arquivo da pasta do destino do download que acabou de fazer para pasta onde o plugin deverá ser instalado

mv buildx-v0.12.0.linux-amd64 ~/.docker/cli-plugins/

Vá para o diretório de destino

cd ~/.docker/cli-plugins/

Instale o componente

apt install docker-buildx

Pronto!

Repare na imagem abaixo, onde agora temos o comando docker buildx build ...

Agora já pode contar pros seus vizinhos que estamos gerando imagens docker utilizando o buildx
\o

Espero que esse post tenha ajudado vcs, até breve.

O projeto utilizado no exemplo, com dockerfile e tudo mais: https://github.com/felipementel/DEPLOY.Cachorro.Api

referências:
https://docs.docker.com/engine/reference/commandline/buildx_build/
https://github.com/docker/buildx/releases

Como sair de organizações no Azure usando AzureCLI

Felipe Augusto — Tue, 06 Jun 2023 14:34:17 +0000

Aloha my friend,

Essa semana fui organizar meus ambientes de desenvolvimento para começar a postar meus vídeos no canal do youtube que vou começar com dois amigos. E já fica a dica, se vc não esta seguindo, já pode correr no yt e se inscrever:

Então vamos para o problema:
Abrindo o meu WSL2 no Windows (ainda vou escrever e gravar um vídeo de como subir o WSL2 e instalar algumas coisas legais nele, como Docker, para poder rodar na sua máquina), fiz o comando para poder fazer login no Azure Cloud

az login

feito isso, abriu uma pagina web, eu confirmei minha identidade

e dai foram listadas as contas que eu tenho acesso:

Hummmm, dai apareceram alguns tenants que eu não tenho mais acesso e na real nem queria ter. Gosto de ter minha conta bem exuta. (detalhe que eu já havia removido outras contas e dai então decidi escrever esse artigo para ajudar outras pessoas, pq eu mesmo já tentei fazer isso outras vezes)

Então catando nas documentações do Azure AD, encontrei o link abaixo:

https://learn.microsoft.com/en-us/azure/active-directory/external-identities/leave-the-organization

E tinha uma forma de sair do Tenant - visto que pelo Azure Cloud Portal, eu não estava conseguindo.

Então basicamente a gente precisa copiar o tenant id e montar uma URL na mão (recomendo usar um bloco de notas para isso)

Dai teremos a URL abaixo:

https://myaccount.microsoft.com?tenantId=wingtiptoys.onmicrosoft.com or https://myaccount.microsoft.com?tenantId=123ABCD456

Lembre de trocar o 123ABCD456 pelo ID do Tenant da primeira imagem

Feito isso, só jogar no seu navegador (eu curto usar o Edge da Microsoft).

Veja como ficou a minha URL

Dai é solicitado que eu faça login na minha conta pessoal

Ao escolher a opção de menu "Organizations" podemos ver exatamente o nome da organização que queremos sair.

Então precisamos clicar na opção "leave" (o meu esta em inglês então talvez o seu apareça escrito "sair" ou "deixar")

Será apresentado a tela abaixo

e logo na sequencia, uma confirmação:

onde, precisamos clicar no botão azul, no meu caso que esta em Inglês, "Leave"

Voltamos para o terminal e ao realizar o comando

az login

Podemos ver que realmente um tenant não existe mais.

Espero que tenha conseguido ajudar vcs
[]´s

DEV Community: Felipe Augusto

Como usar git-filter-repo para remover arquivos e segredos do histórico Git

Como usar git-filter-repo para remover arquivos e segredos do histórico Git

1. Verificando a versão do Python

2. Documentando a instalação do git-filter-repo

3. Antes de mexer no histórico: clone limpo e cuidado com impacto

4. Descobrindo em que commit um arquivo entrou

5. Apagando um arquivo de todos os commits

6. Gerando análise antes ou depois da limpeza

7. Substituindo segredos do histórico com arquivo .gitfilter

Um ponto importante sobre arquivos começando com ponto

8. Exemplo completo de fluxo

Caso A: apagar um arquivo indevido do histórico

Caso B: substituir um segredo vazado

9. Publicando a nova árvore de commits

10. O que o restante do time precisa fazer depois

11. Relacionando isso com Gitleaks no GitHub Actions

12. Erros comuns e observações práticas

Usar --force sem entender o impacto

Achar que apagar no commit atual resolve

Esquecer as tags

Não orientar o time

Tratar dotfiles como regra universal

13. Vídeo complementar

Conclusão

Como Configurar Multiplas Contas do Git na sua Máquina Usando o Arquivo .gitconfig

Um Desenvolvedor, Várias Identidades

Entendendo a Estrutura do .gitconfig

O Cenário: Três Contextos, Três Perfis

Explicando o Arquivo Passo a Passo

Como verificar se a configuração está correta

Considerações Finais

Retorno de validações semânticas em API Rest

Como instalar o componente buildx no docker

Como sair de organizações no Azure usando AzureCLI

7. Substituindo segredos do histórico com arquivo `.gitfilter`

Usar `--force` sem entender o impacto