Comparar e mesclar texto

Como funciona

1. Cole dois textos : insira o texto original no painel da esquerda e o texto revisado no da direita.
2. Consulte as diferenças : as linhas modificadas são destacadas, verde para adições, vermelho para exclusões e amarelo para modificações.
3. Percorra o diff : role pelas mudanças coloridas e copie ou capture em imagem as partes de que precisa.

Breve história do diff

A comparação de texto moderna nasceu nos Bell Labs. Douglas McIlroy (o mesmo McIlroy que inventou os pipes do Unix) e James W. Hunt escreveram o diff Unix original no início dos anos 1970; ele foi entregue como parte da 5.ª Edição do Unix em 1974. O algoritmo foi documentado no Bell Laboratories Computing Science Technical Report n.º 41 (junho de 1976), um relatório interno intitulado «An Algorithm for Differential File Comparison». O algoritmo de Hunt-McIlroy é construído sobre o problema da subsequência comum mais longa (LCS), encontrar a sequência mais longa de linhas que aparece, em ordem, nas duas entradas, e tudo que não estiver nessa sequência é uma deleção ou uma inserção. Uma década depois, Eugene W. Myers publicou «An O(ND) Difference Algorithm and Its Variations» em Algorithmica, Vol 1 número 2 (1986). Myers reformulou o problema como busca do caminho mais curto sobre um «grafo de edição» e mostrou que poderia ser resolvido em tempo e espaço O(ND), onde N é o tamanho da entrada e D é o tamanho do script de edição mínimo. Para entradas típicas, arquivos que diferem em apenas alguns lugares, D é pequeno, então o algoritmo é rápido na prática. O artigo de Myers tornou-se a base de uma implementação Unix diff mais rápida que rodava de duas a quatro vezes mais rápido que sua predecessora e produzia saída de maior qualidade. Patience diff (Bram Cohen, 2008) é um refinamento LCS que prioriza linhas-âncora únicas, produzindo diffs mais legíveis em torno de blocos movidos. O padrão atual em git diff é o algoritmo histograma em LibXDiff, geralmente considerado mais rápido que o Myers básico e produzindo diffs mais legíveis na presença de blocos movidos (tornou-se o padrão do Git em 2.11, lançado em 29 de novembro de 2016). Os fundamentos matemáticos vão ainda mais fundo: a distância de Levenshtein (Vladimir Levenshtein, 1965) é o primo em nível de caractere do problema LCS, e a solução de programação dinâmica de Wagner-Fischer (1974) é o que toda biblioteca de «correspondência fuzzy» ainda implementa internamente.

Como um diff é renderizado

Há quatro convenções visuais comuns para exibir um diff. Lado a lado, duas colunas, original à esquerda, modificado à direita, com as linhas correspondentes alinhadas. Bom para comparação relâmpago; funciona bem em larguras de desktop mas torna-se ilegível em viewports móveis estreitos. Diff unificado inline, uma única coluna mostrando linhas removidas (tipicamente prefixadas com - e coloridas de vermelho), linhas adicionadas (+, verde) e linhas de contexto inalteradas (sem prefixo, texto puro). O layout que git diff usa por padrão. Escala bem para mobile mas perde o paralelismo espacial do lado a lado. Diff em nível de palavra, destacando apenas as palavras que mudaram dentro das linhas modificadas. Útil para comparação de prosa onde a maior parte do texto não mudou mas frases específicas foram editadas. Diff em nível de caractere, destacando cada caractere mudado individualmente. Útil para mudanças muito pequenas (uma correção de erro de digitação, uma edição de dígito único) onde o nível de palavra destacaria a palavra inteira. As convenções de cor são notavelmente consistentes em todo o ecossistema: verde para adições, vermelho para remoções, amarelo ou âmbar para valores alterados, cinza neutro ou sem estilo para inalterado. Esta ferramenta usa o estilo unificado inline com destaque em nível de caractere dentro das linhas modificadas, um híbrido que escala bem para mobile preservando a precisão da comparação em nível de caractere para edições de prosa.

Mesclagem a três vias, quando dois diffs precisam se combinar

Um diff a duas vias (esta ferramenta) diz o que mudou entre a versão A e a versão B. Uma mesclagem a três vias responde a uma pergunta mais difícil: dado um ancestral comum e duas revisões divergentes, qual é o resultado combinado que incorpora ambos os conjuntos de mudanças? Esta é a operação central de todo sistema de controle de versão, quando dois desenvolvedores editam o mesmo arquivo independentemente e um tenta mesclar o trabalho deles, o sistema precisa aplicar os dois diffs ao original. O algoritmo diff3 formalizado por Khanna, Kunal e Pierce (2007) é a base. A convenção do marcador de conflito de sete caracteres, <<<<<<<, =======, >>>>>>>, que o Git insere nos arquivos quando uma mesclagem automatizada falha vem diretamente desta linhagem. Ferramentas modernas de mesclagem visual (o editor de mesclagem de três painéis do VS Code, padrão desde 1.69 em junho de 2022; Beyond Compare da Scooter Software, desde 1996; Meld; Kaleidoscope da Black Pixel para macOS) lidam com mesclagens a três vias com renderização lado a lado das três versões mais um quarto painel para o resultado de mesclagem proposto. Esta ferramenta foca em comparação a duas vias, a mesclagem a três vias pertence a um fluxo de trabalho real de controle de versão.

Casos de uso comuns

• Revisão de código. Colar duas versões de uma função ou módulo para detectar a mudança rapidamente, especialmente ao trabalhar fora de um fluxo Git (um trecho do e-mail de um colega, uma resposta do Stack Overflow contra seu código atual).
• Comparação de contratos jurídicos. Advogados e negociadores de contratos rotineiramente comparam duas versões de um contrato para ver o que a outra parte mudou. O termo legal-tech é comparação «blackline» ou «redline»; produtos como Draftable se especializam nisso.
• Edição de prosa. Comparar o rascunho de um escritor com a revisão de um editor, ou duas versões de um artigo. Controlar Alterações do Microsoft Word faz isso dentro do produto; para rascunhos em texto puro ou Markdown, uma ferramenta de diff é o equivalente.
• Drift de configuração. Comparar um arquivo de configuração em produção contra a versão no controle de fonte, a lacuna é o drift. Mesmo fluxo para configurações específicas de ambiente (dev vs staging vs produção).
• Comparação de logs. Fazer diff de dois arquivos de log de diferentes execuções do mesmo processo para encontrar o ponto de divergência.
• Revisão de localização. Tradutores frequentemente fazem diff de uma nova fonte em inglês contra a versão anterior para identificar exatamente o que é novo e precisa de tradução.

O ecossistema diff em 2026

Além de git diff e Unix diff, várias ferramentas de diff especializadas merecem menção. Beyond Compare (Scooter Software, 1996) é a ferramenta comercial veterana de comparação de pastas e arquivos, popular entre desenvolvedores e profissionais de TI para diffing entre máquinas. Meld (open source, baseado em GTK) é o padrão do GNOME. Kaleidoscope (Black Pixel, macOS) integra-se com controle de versão e é a escolha de facto para muitos desenvolvedores Mac. O editor de diff embutido do VS Code lida com comparações a duas e três vias nativamente; o editor de mesclagem de três painéis tornou-se padrão em 1.69 (junho de 2022). Mergely (Wayne Stidolph, 2013, licença MIT) é o editor canônico de mesclagem a duas vias baseado em navegador construído sobre CodeMirror. jsdiff (Kevin Decker, ~2010) é a biblioteca JavaScript de diff dominante, usada por toda ferramenta de diff baseada em navegador na qual você já colou. diff-match-patch (Neil Fraser no Google, 2006) é a biblioteca alternativa que lida com diffing, correspondência fuzzy e geração de patches em uma única API; usada no histórico de revisões do Google Docs. Diffchecker é o serviço freemium dominante de diff online, completo mas com privacidade atrás de paywall (o nível gratuito envia o texto ao servidor deles). text-compare.com é o site de diff de texto puro na web mais antigo, UI datada mas funcional.

Privacidade: por que somente-navegador importa especialmente aqui

Todo diff revela exatamente o que mudou entre duas versões, e o que mudou frequentemente é mais sensível do que qualquer uma das versões sozinha. Três cenários concretos onde isso importa agudamente. Patches de segurança: fazer diff de uma versão vulnerável de uma função contra a versão corrigida revela a localização e natureza precisas de um bug de segurança, um atacante que encontrar o patch pode criar um exploit para a versão não corrigida (o ataque «patch gap» documentado por Tian et al. no USENIX Security 2017). Colar um patch de segurança em uma ferramenta de diff do lado servidor é essencialmente publicar a vulnerabilidade. Negociação de contrato: fazer diff de duas versões de um contrato revela exatamente quais cláusulas cada lado se importa, que é precisamente a informação que você não quer que a outra parte (ou qualquer um observando a rede) tenha durante a negociação. Decisões editoriais pré-publicação: fazer diff de um manuscrito antes e depois da edição revela o que um autor e editor decidiram cortar ou mudar, frequentemente mais revelador do que a versão final publicada. Ferramentas de diff do lado servidor sobem ambas as versões para um terceiro, onde elas ficam em logs. Esta ferramenta roda inteiramente no seu navegador via JavaScript, verifique na aba Rede do DevTools enquanto clica em Comparar, ou tire a página do ar (modo avião) após carregar e a ferramenta ainda funciona.

Perguntas frequentes

Posso comparar arquivos de código ?

Sim. Cole qualquer texto, incluindo código, JSON, HTML, Markdown ou texto simples. O diff é puramente textual, então funciona para qualquer formato.

Ele ignora diferenças de espaçamento ?

Ative a opção « Ignorar os espaços » para ignorar diferenças que são apenas espaços ou finais de linha. Útil para comparar código reformatado mas não alterado no conteúdo.

Que algoritmo isto usa?

O algoritmo O(ND) de Myers (Eugene Myers, Algorithmica Vol 1 N.º 2, 1986), o mesmo algoritmo que o GNU diff usou por padrão por décadas e a base da maioria das implementações de diff de texto. Myers reformulou o problema da subsequência comum mais longa como busca de caminho mais curto sobre um grafo de edição, tornando-o rápido na prática para entradas que diferem em poucos lugares. O algoritmo histograma mais novo (padrão atual do Git desde v2.11, novembro de 2016) lida ligeiramente melhor com blocos movidos mas é exagero para o caso típico de dois colados que esta ferramenta lida.

Há um limite de tamanho?

Sem limite rígido, mas a comparação roda no seu navegador via JavaScript então o teto prático é a memória disponível do seu dispositivo. Dezenas de milhares de linhas funcionam confortavelmente. Entradas muito grandes (arquivos de log de vários MB, romances completos) rodarão mas podem levar segundos notáveis para renderizar. Para entradas genuinamente enormes use o diff do Git na linha de comando, ele faz streaming da saída e lida com arquivos de tamanho arbitrário sem pressão de memória.

Pode fazer mesclagem a três vias ou aplicar patches?

Atualmente não, esta ferramenta foca em comparação a duas vias (A vs B). A mesclagem a três vias (o algoritmo diff3 com marcadores de conflito <<<<<<< / ======= / >>>>>>>) é a operação que o Git usa ao mesclar branches; requer um ancestral comum mais duas versões divergentes. Para mesclagem a três vias, use um sistema real de controle de versão ou uma ferramenta dedicada como o editor de mesclagem de três painéis do VS Code (padrão desde 1.69 em junho de 2022).

Meus textos são enviados?

Não. A comparação roda inteiramente no seu navegador via JavaScript. Os textos que você cola nunca cruzam a rede, verifique na aba Rede do DevTools enquanto clica em Comparar, ou tire a página do ar (modo avião) após carregar e a ferramenta ainda funciona. Especialmente seguro para fazer diff de patches de segurança (onde o diff mesmo revela a vulnerabilidade), revisões de contrato (onde o diff revela posições de negociação) ou rascunhos editoriais pré-publicação.