Si Git marca repentinamente casi todos los archivos como modificados en tu Mac, es posible que la conversión de finales de línea esté haciendo que la copia de trabajo difiera de la versión que Git rastrea. Primero inspecciona el repositorio antes de cambiar o restaurar archivos. Luego, utiliza configuraciones de Git adecuadas para macOS y vuelve a normalizar solo después de proteger cualquier edición real. Git recomienda almacenar texto con finales de línea LF; su guía para macOS utiliza core.autocrlf input. Guía de GitHub sobre finales de línea

¿Por qué los finales de línea pueden hacer que todos los archivos parezcan modificados?

Un final de línea marca el final de cada línea: el estilo LF de Unix usa un solo carácter, mientras que el estilo CRLF de Windows usa un retorno de carro más un salto de línea. Si Git o un editor cambian los finales de línea en una copia de trabajo, Git puede reportar cambios generalizados en los archivos incluso cuando el texto en sí parece idéntico. Git puede normalizar el texto a LF en su índice y aplicar diferentes finales al extraer archivos (checkout), según la configuración y el archivo .gitattributes. Documentación de gitattributes de Git

Inspecciona el repositorio antes de solucionarlo

Abre Terminal, ve al directorio del repositorio y comprueba su estado y la configuración de finales de línea:

git status --short
git config --show-origin --get core.autocrlf
git ls-files --eol

El comando config puede no mostrar nada si no se ha establecido ningún valor. --show-origin ayuda a identificar qué archivo de configuración proporcionó el ajuste. En git ls-files --eol, compara los finales del índice (i/) y del árbol de trabajo (w/); mixed indica finales de línea mixtos. El valor attr/ muestra los atributos aplicables. Git documenta esta salida como un diagnóstico del índice, el árbol de trabajo y los atributos de final de línea. Documentación de git-ls-files de Git

Verifica también si hay ediciones reales antes de continuar. Si encuentras cambios que deseas conservar, haz un commit de ellos o cópialos en un lugar seguro. No utilices una restauración o un restablecimiento indiscriminado como solución para los finales de línea: esos comandos pueden descartar tu trabajo. Los archivos binarios requieren especial cuidado porque la conversión de finales de línea puede dañar los datos si Git los trata como texto. Documentación de git-config de Git

Establece un valor predeterminado sensato para macOS

Para tu propio uso de Git en todos los repositorios, establece la preferencia documentada para macOS:

git config --global core.autocrlf input

Con input, Git normaliza CRLF a LF al añadir texto, sin convertir los archivos con LF a CRLF durante el checkout. Esta configuración no define la política para cada archivo: los atributos del repositorio pueden especificar el comportamiento según el tipo de archivo, y los atributos text y eol de Git controlan la normalización y los finales al extraer archivos. Guía específica de plataforma de GitHub y Referencia de configuración de Git

Si el problema se limita a un solo proyecto, da prioridad a la política del archivo .gitattributes de ese proyecto en lugar de cambiar tu configuración global para adaptarla a un único repositorio. Un punto de partida común es * text=auto; los formatos específicos pueden fijarse en LF o CRLF, mientras que los formatos binarios deben marcarse como binary. Por ejemplo, los scripts de shell suelen necesitar LF, mientras que algunos archivos de proyectos de Windows requieren CRLF. Los patrones correctos dependen de las herramientas y de los colaboradores del repositorio. Ejemplos de gitattributes de Git

* text=auto
*.sh text eol=lf
*.bat text eol=crlf
*.png binary

Vuelve a normalizar solo después de revisar los cambios

Cambiar la configuración o los atributos no garantiza que los archivos existentes se vuelvan consistentes de inmediato. El procedimiento de actualización documentado por GitHub primero guarda o confirma (commit) el trabajo pendiente, luego ejecuta git add --renormalize . y revisa el estado resultante. Instrucciones de actualización de GitHub

Una vez que hayas guardado tus ediciones de forma segura y hayas definido la política del repositorio, prepara la normalización en el área de preparación (stage) e inspecciona exactamente qué propone Git:

git add --renormalize .
git status --short
git diff --cached --stat
git diff --cached

No hagas commit automáticamente. Revisa el diff preparado (staged), prestando especial atención a archivos binarios o generados inesperados. Si todavía muestra cambios de contenido no deseados, detente e inspecciona las rutas afectadas y sus valores attr/ con git ls-files --eol; corrige la política de atributos antes de volver a prepararlos. La renormalización puede producir un diff grande y legítimo si el repositorio almacenaba previamente finales de línea inconsistentes, por lo que debes coordinar un commit de normalización con tus colaboradores cuando sea necesario.

Si los archivos siguen apareciendo como modificados

Los finales de línea son solo una causa posible. Busca diferencias sustanciales en los diffs preparados o sin preparar, comprueba si algún editor reescribió los archivos e inspecciona los filtros o atributos específicos de los archivos. Si git ls-files --eol informa i/lf y w/crlf, confirma si algún atributo o ajuste solicita intencionadamente CRLF. Si reporta mixed, identifica qué archivos tienen finales mixtos y si son de texto antes de normalizar. Las comprobaciones de seguridad de Git pueden advertir sobre conversiones irreversibles, pero no pueden determinar si un archivo se clasificó erróneamente como texto. Referencia de configuración de Git

La secuencia práctica es: protege las ediciones, inspecciona core.autocrlf y git ls-files --eol, elige una política consistente para el proyecto, y luego vuelve a normalizar y revisa el diff. Esto soluciona el ruido de los finales de línea al tiempo que te permite mantener el control de cualquier cambio de contenido real.

Fuentes