Generador de .gitignore

Acerca de Generador de .gitignore

Un archivo .gitignore indica a Git qué archivos no rastreados debe hacer como que no ve: resultados de compilación, carpetas de dependencias, archivos que el sistema operativo va dejando por todas partes y archivos de entorno con secretos. No afecta a los archivos que Git ya rastrea, y de ahí sale la mayoría de las confusiones.

Este generador combina plantillas de lenguajes, frameworks, sistemas operativos y editores en un solo archivo. Da igual en qué orden los marques: la salida siempre va ordenada por lenguaje, framework y sistema operativo, cada bloque con un comentario de cabecera como ### Node.js ###, y los patrones adicionales que escribas van al final bajo ### Custom ###. La mayoría de las plantillas se basan en la colección github/gitignore de GitHub.

Cuatro reglas de patrones que suelen malinterpretarse

Según la documentación oficial de Git:

• Una barra final significa solo directorios. build/ ignora un directorio llamado build y todo su contenido, pero no un archivo llamado build.
• Una barra al principio o en medio ancla el patrón a la ubicación del .gitignore. /TODO solo coincide con el TODO del nivel superior y doc/frotz solo con doc/frotz relativo a ese archivo. Un patrón sin barras, como *.log o node_modules/, coincide a cualquier profundidad.
• ** abarca varios niveles. **/logs coincide con logs en cualquier sitio; a/**/b coincide con a/b, a/x/b y a/x/y/b.
• Dentro de un mismo archivo gana la última línea que coincide. Por eso las excepciones con ! deben ir después de la regla que anulan.

Cuando una excepción con ! no hace nada

La documentación lo dice claramente: no es posible volver a incluir un archivo si está excluido un directorio padre. Por rendimiento, Git ni siquiera lista el contenido de un directorio excluido, así que la excepción para un archivo de dentro nunca llega a evaluarse.

La plantilla de VS Code de esta herramienta está escrita justo en torno a esa regla. Usa .vscode/* en lugar de .vscode/ y después vuelve a incluir !.vscode/settings.json, !.vscode/extensions.json y algunos más. .vscode/* excluye el contenido del directorio, no el directorio, de modo que Git sigue mirando dentro y puede aplicar las excepciones. Escrito como .vscode/, todas las excepciones de debajo serían inútiles. En la plantilla de Node.js, .env.* seguido de !.env.example funciona igual: .env.local con las claves reales queda fuera y el archivo de ejemplo que documenta las variables necesarias sí se sube.

Añadir un archivo a .gitignore no deja de rastrearlo

Las reglas de ignorar solo se aplican a archivos no rastreados. Si un archivo ya se confirmó, Git sigue detectando sus cambios diga lo que diga el .gitignore. Para dejar de rastrearlo hay que quitarlo solo del índice con git rm --cached ruta (git rm -r --cached carpeta para un directorio) y hacer commit. El archivo en disco no se toca.

Con los secretos no basta. Si confirmaste un .env y luego dejaste de rastrearlo, su contenido sigue en todos los commits anteriores, y si hiciste push lo tiene cualquiera que haya clonado el repositorio. Lo primero es revocar y regenerar las credenciales; reescribir el historial es una limpieza secundaria.

Líneas que conviene revisar antes de usar una plantilla tal cual

Las plantillas están escritas en sentido amplio para el caso habitual, y una regla amplia puede ocultar código real. La plantilla de Python de esta herramienta incluye lib/, build/ y dist/; si tu proyecto tiene su propio paquete lib, los archivos nuevos de ahí no se confirmarán nunca y nadie te avisará. La de Node.js ignora out y dist, y la de JetBrains también out/.

Para saber por qué se ignora un archivo, ejecuta git check-ignore -v ruta. Muestra el archivo .gitignore, el número de línea y el patrón responsables. Si una plantilla atrapa una carpeta que necesitas, añade una excepción como !lib/ en la casilla de patrones adicionales; como se añaden al final del todo, anulan las reglas de las plantillas que van antes.

Los archivos del editor y del sistema (.DS_Store, Thumbs.db, .idea/) también pueden ir en un archivo de exclusión global personal, configurado con git config --global core.excludesFile. En un repositorio compartido no puedes contar con que todos lo hayan hecho, así que incluirlos en el .gitignore del proyecto es la opción más segura.

Ejemplos

Cómo se usa

1. Busca o elige tus lenguajes, frameworks, sistema operativo y editores.
2. Añade rutas extra, o excepciones con ! para deshacer una regla de plantilla, en la casilla de patrones adicionales.
3. Guarda el resultado como .gitignore en la raíz del repositorio y comprueba con git status que han desaparecido los archivos correctos.

Preguntas frecuentes