Se o Git repentinamente marcar quase todos os arquivos como modificados no seu Mac, a conversão de quebras de linha pode estar fazendo com que a cópia de trabalho fique diferente da versão rastreada pelo Git. Primeiro inspecione o repositório antes de alterar ou restaurar arquivos. Em seguida, use configurações do Git adequadas para o macOS e apenas renormalizar após proteger quaisquer edições reais. O Git recomenda armazenar texto com quebras de linha LF; sua orientação para macOS usa core.autocrlf input. Guia do GitHub sobre quebras de linha
Por que as quebras de linha podem fazer com que todos os arquivos pareçam alterados?
Uma quebra de linha marca o final de cada linha: o estilo LF do Unix usa um caractere, enquanto o estilo CRLF do Windows usa um retorno de carro (carriage return) mais um avanço de linha (line feed). Se o Git ou um editor alterar as quebras em toda a cópia de trabalho, o Git poderá relatar alterações abrangentes de arquivos, mesmo quando o texto em si parecer idêntico. O Git pode normalizar o texto para LF em seu índice e aplicar quebras diferentes ao fazer o checkout dos arquivos, dependendo da configuração e do .gitattributes. Documentação do gitattributes do Git
Inspecione o repositório antes de corrigi-lo
Abra o Terminal, acesse o repositório e verifique seu status e as configurações de quebra de linha:
git status --short
git config --show-origin --get core.autocrlf
git ls-files --eol
O comando de configuração pode não exibir nada se nenhum valor estiver definido. --show-origin ajuda a identificar qual arquivo de configuração forneceu a definição. Em git ls-files --eol, compare as quebras do índice (i/) e da árvore de trabalho (w/); mixed indica quebras mistas. O valor attr/ mostra os atributos aplicáveis. O Git documenta essa saída como um diagnóstico do índice, da árvore de trabalho e dos atributos de quebra de linha. Documentação do git-ls-files do Git
Verifique também se há edições reais antes de prosseguir. Se encontrar alterações que deseja manter, faça o commit delas ou copie-as para um local seguro. Não use uma restauração ou reset geral como solução para quebras de linha: esses comandos podem descartar o trabalho. Arquivos binários exigem cuidado especial porque a conversão de quebras de linha pode corromper os dados se o Git os tratar como texto. Documentação do git-config do Git
Defina um padrão sensato para o macOS
Para o seu próprio uso do Git em todos os repositórios, defina a preferência documentada para macOS:
git config --global core.autocrlf input
Com input, o Git normaliza CRLF para LF ao adicionar texto, sem converter arquivos LF para CRLF no checkout. Essa configuração não resolve a política de cada arquivo: os atributos do repositório podem especificar o comportamento por tipo de arquivo, e os atributos text e eol do Git controlam a normalização e as quebras no checkout. Orientações específicas da plataforma do GitHub e Referência de configuração do Git
Se o problema estiver limitado a um único projeto, prefira a política do .gitattributes desse projeto em vez de alterar sua configuração global para atender a apenas um repositório. Um ponto de partida comum é * text=auto; formatos específicos podem ser fixados em LF ou CRLF, enquanto formatos binários devem ser marcados como binary. Por exemplo, scripts de shell geralmente precisam de LF, enquanto alguns arquivos de projeto do Windows exigem CRLF. Os padrões corretos dependem das ferramentas e dos colaboradores do repositório. Exemplos de gitattributes do Git
* text=auto
*.sh text eol=lf
*.bat text eol=crlf
*.png binary
Renormalize apenas após revisar as alterações
Alterar a configuração ou os atributos não garante que os arquivos existentes se tornem imediatamente consistentes. O procedimento de atualização documentado pelo GitHub primeiro salva ou faz commit do trabalho pendente, depois executa git add --renormalize . e revisa o status resultante. Instruções de atualização do GitHub
Depois de salvar suas edições em segurança e definir a política do repositório, prepare a normalização (stage) e inspecione exatamente o que o Git propõe:
git add --renormalize .
git status --short
git diff --cached --stat
git diff --cached
Não faça o commit automaticamente. Revise o diff preparado na área de stage, especialmente arquivos binários ou gerados inesperados. Se ele ainda mostrar alterações de conteúdo que você não pretendia fazer, pare e inspecione os caminhos afetados e seus valores attr/ com git ls-files --eol; corrija a política de atributos antes de preparar novamente. A renormalização pode produzir um diff legítimo e extenso se o repositório armazenava anteriormente quebras inconsistentes; portanto, coordene um commit de normalização com os colaboradores quando necessário.
Se os arquivos continuarem modificados
As quebras de linha são apenas uma causa possível. Procure por diferenças substanciais nos diffs preparados ou não preparados, verifique se um editor reescreveu os arquivos e inspecione filtros ou atributos específicos de arquivos. Se git ls-files --eol relatar i/lf e w/crlf, confirme se um atributo ou configuração solicita intencionalmente CRLF. Se relatar mixed, identifique quais arquivos têm quebras mistas e se são arquivos de texto antes de normalizar. As verificações de segurança do Git podem alertar sobre conversões irreversíveis, mas não conseguem dizer se um arquivo foi classificado incorretamente como texto. Referência de configuração do Git
A sequência prática é: proteja as edições, inspecione core.autocrlf e git ls-files --eol, escolha uma política consistente para o projeto e, em seguida, renormalizar e revisar o diff. Isso elimina o ruído das quebras de linha enquanto mantém você no controle de quaisquer alterações reais de conteúdo.