Generador de .gitignore

Qué hace un archivo .gitignore

Cuando trabajás con Git, no todos los archivos de tu carpeta deberían versionarse. Las dependencias descargadas (node_modules/), los archivos que genera la compilación (dist/, build/), los temporales del sistema (.DS_Store) y sobre todo las credenciales (.env) no aportan nada al historial y, en el peor caso, filtran secretos. El .gitignore es una lista de patrones que le dice a Git: "estos archivos existen en mi disco, pero no los sigas ni me los muestres como cambios pendientes".

Esta herramienta combina plantillas reales por tecnología. Si marcás Node, Python y macOS, junta los tres bloques, elimina líneas duplicadas y te devuelve un solo archivo ordenado por secciones con encabezados # --- Node --- para que sepas de dónde viene cada regla.

.gitignore del repositorio vs global

Hay dos lugares donde poner reglas. El .gitignore del repositorio vive en la raíz del proyecto, se versiona y se comparte con todo el equipo: acá van las reglas propias del proyecto (carpetas de build, dependencias, artefactos). El .gitignore global vive en tu máquina y aplica a todos tus repos; acá conviene poner lo personal, como los archivos de tu editor o de tu sistema operativo, que no todo el equipo necesariamente usa. Se configura una sola vez:

git config --global core.excludesfile ~/.gitignore_global

La regla práctica: lo que depende del proyecto va en el repo; lo que depende de tu setup (editor, SO) va en el global.

Orden y precedencia de las reglas

Git evalúa los patrones de arriba hacia abajo y gana la última coincidencia. Esto importa cuando usás negaciones con !. Por ejemplo, para ignorar todos los logs menos uno:

*.log
!important.log

Si invertís el orden, la regla *.log vuelve a ignorar important.log y la negación no sirve. Ojo con una limitación importante: no podés re-incluir un archivo si su carpeta padre ya está ignorada. Si tenés logs/, un !logs/keep.txt no funciona; primero tenés que ignorar el contenido con logs/* y después negar el archivo puntual.

Cómo se escriben los patrones

• *.log → todos los archivos que terminan en .log, en cualquier carpeta.
• build/ → la barra final indica una carpeta llamada build.
• /build → la barra inicial ancla la regla a la raíz del repo.
• **/temp → el doble asterisco cruza cualquier nivel de carpetas.
• !archivo → el signo de exclamación niega (re-incluye) un patrón anterior.
• # comentario → las líneas con # son comentarios y se ignoran.

Errores comunes que conviene evitar

• Commitear .env con secretos. El error más caro. Si ya lo subiste, no alcanza con borrarlo: quedó en el historial. Hay que rotar las credenciales expuestas y, si hace falta, limpiar el historial.
• Agregar la regla después de trackear el archivo. .gitignore solo afecta archivos no trackeados. Si el archivo ya está en Git, corré git rm --cached archivo y commiteá.
• Ignorar node_modules/ pero commitear el lockfile. Bien: el package-lock.json o yarn.lock SÍ deben versionarse; lo que se ignora es la carpeta de dependencias, no el lockfile.
• Usar rutas absolutas. Los patrones son relativos al repo, no a tu disco. /Users/vos/proyecto/dist no funciona; dist/ sí.

Referencia: patrones clave por stack