Cómo generar un .gitignore
- Marca cada combinación de lenguaje, sistema operativo y editor que aplique a tu proyecto, por ejemplo Node.js, macOS y VS Code para una configuración típica de JS/Mac.
- Haz clic en Generar .gitignore.
- Copia el resultado o descárgalo, guárdalo como
.gitignoreen la carpeta raíz de tu proyecto, y haz commit.
Por qué un generador basado en casillas
El .gitignore real de un proyecto casi siempre es una combinación de varias cosas no relacionadas: los artefactos de compilación propios del lenguaje/runtime, el sistema operativo en el que desarrollas, y el editor que sea que genere su propia carpeta local de ajustes. Ensamblarlo a mano de memoria (o a partir de tres respuestas distintas medio recordadas de Stack Overflow) es exactamente el tipo de tarea pequeña y repetitiva que merece la pena automatizar, marca las casillas que apliquen, y esta herramienta combina solo esas, en un orden fijo, con las reglas duplicadas eliminadas automáticamente.
Qué incluye (un subconjunto curado, no un espejo en vivo)
Esta herramienta cubre 11 de los patrones combinados más habituales: Node.js, Python, Java, Go, Rust, macOS, Windows, Linux, VS Code, IntelliJ IDEA y Vim. Cada uno es un subconjunto escrito a mano y de alta confianza de los patrones de exclusión estándar bien conocidos de ese ecosistema, no un espejo automático y actualizado byte a byte del propio github/gitignore de GitHub, que sigue siendo la referencia autorizada si necesitas el contenido exacto y actual de una plantilla concreta.
Combinar y eliminar duplicados, explicado
Cada plantilla marcada recibe su propia cabecera de sección # <Nombre>, siempre emitida en el mismo orden (Node → Python → Java → Go → Rust → macOS → Windows → Linux → VS Code → IntelliJ IDEA → Vim) sin importar en qué orden marcaste las casillas. Si el mismo patrón de exclusión aparece en más de una sección que elegiste (por ejemplo tanto la plantilla de Java como la de IntelliJ IDEA excluyen out/) se escribe solo una vez, la primera vez que aparece, así que el archivo final no repite la misma regla bajo dos cabeceras distintas.
Un .gitignore son tres listas sin relación dentro de un archivo
Casi el archivo de exclusiones de nadie trata de una sola cosa. Está el lenguaje o entorno de ejecución, que deja salida de compilación y carpetas de dependencias en el árbol de trabajo. Está el sistema operativo, que esparce sus propios metadatos allá donde abras una carpeta. Y está el editor, que guarda estado por proyecto justo al lado de tu código. Tres listas, tres orígenes, normalmente ensambladas de memoria una vez y nunca más revisadas.
Por eso esta página es una columna de casillas y no un campo de texto. Tú describes la máquina y el proyecto, y el generador escribe esas listas separadas como un solo archivo con una sección etiquetada para cada una.
Comprometerlo, y la trampa de los archivos que Git ya sigue
Una regla de exclusión no es un borrado. Git la aplica solo a los archivos que todavía no sigue, así que añadir .env al archivo no hace absolutamente nada si .env se comprometió el mes pasado. Esa es la sorpresa más común alrededor de este archivo, y la solución es quitar la ruta del índice y comprometer esa eliminación antes de que la regla nueva tenga ningún efecto. Para cualquier cosa secreta, da por hecho que está comprometida en el momento en que llega a una rama compartida, porque el historial la conserva.
El otro hábito que conviene adquirir es revisar el diff. Regenerar una base para un archivo antiguo que ha ido derivando es buena idea, pero las líneas específicas del proyecto que alguien fue añadiendo con los años son exactamente las que no te puedes permitir perder. Pega el archivo viejo y el nuevo en el Comparador de Textos y fusiona deliberadamente en lugar de sobrescribir.
Dónde acaba .gitignore y empieza .dockerignore
Estos dos archivos se parecen y responden a preguntas distintas. Este decide qué registra Git; un .dockerignore decide qué se envía al demonio de Docker como contexto de construcción, que es una cuestión de tamaño y de caché y no de historial. El Generador de Dockerfile produce ese segundo archivo, seleccionado mediante su desplegable de qué archivo mostrar, y su salida para Node.js cubre .git, node_modules/, .env y un puñado de directorios de compilación con independencia de lo que marques aquí.
Los repositorios nuevos suelen necesitar varios de estos a la vez, así que merece la pena saber qué hay cerca. El Generador de Configuración Nginx y .htaccess construye las reglas del servidor, y el Generador de README se encarga de la puerta de entrada.
Una nota de implementación, porque explica una rareza que quizá notes: el módulo entrega al contenedor un archivo llamado .gitignore, pero el contenedor del generador solo lee el texto de ese archivo hacia el recuadro de resultado. El nombre nunca te llega. Es peso muerto, conservado porque todas las herramientas de este sitio devuelven la misma forma, y es peso muerto precisamente porque la maquetación de generador ofrece un botón de copiar y ninguna ruta de descarga en la que ese nombre pudiera acabar.
Sin viaje de ida y vuelta a un servidor, sin cuenta
Cada casilla se combina en texto plano usando JavaScript que se ejecuta enteramente en tu pestaña del navegador. No hay subida, no hay cuenta, y ningún dato sobre tu proyecto (ni siquiera el hecho de que generaste un .gitignore) sale jamás de tu dispositivo.
Usos habituales
- Poner en marcha el
.gitignorede un proyecto nuevo de Node.js + macOS + VS Code en segundos en lugar de retipear las mismas líneas de memoria. - Combinar un lenguaje de backend (Python, Java, Go, Rust) con los patrones de SO y editor que usa todo tu equipo, para que nadie haga commit por accidente de
.DS_Storeo.idea/. - Limpiar un
.gitignoreantiguo e inconsistente regenerando una base fresca y combinando de vuelta tus líneas específicas de proyecto, mira el Comparador de Textos para comparar el archivo antiguo y el nuevo línea a línea. - Combinarlo con el Generador de Configuración Nginx y .htaccess al poner en marcha el repositorio de un proyecto nuevo y su configuración de servidor a la vez.
- Poner en marcha a la vez el Dockerfile del proyecto, mira el Generador de Dockerfile (su propio .dockerignore ya cubre
node_modules/,.git, y patrones similares por separado de este). - Poner en marcha a la vez el README.md del proyecto, mira el Generador de README.
