Qué ignorar y qué confirmar

Un buen .gitignore no se juzga por su longitud, sino por su criterio. El criterio es uno solo: ¿puede alguien que acaba de clonar el repositorio obtener el mismo resultado solo con el código fuente y la configuración? Lo que se puede volver a generar se ignora; lo que no se puede volver a generar o fija el resultado se confirma.

Qué ignorar

Tipo	Ejemplo	Motivo
Artefactos de compilación	`dist/`, `build/`, `target/`, `.o`, `.class`	Se regeneran a partir del código fuente
Resultados de instalar dependencias	`node_modules/`, `vendor/`(PHP), `.venv/`	Se reinstalan con el manifiesto y el lockfile
Cachés y registros	`.cache/`, `.pytest_cache/`, `*.log`, `coverage/`	Cambian en cada ejecución
Entorno local y secretos	`.env`, `.pem`, `local.properties`, `.tfstate`	Difieren por persona y entorno o no deben filtrarse
Estado de herramientas personales	`.DS_Store`, `*.swp`, `.idea/workspace.xml`	No tienen relación con el proyecto (se recomienda el gitignore global)

Qué confirmar

lockfiles: package-lock.json, yarn.lock, pnpm-lock.yaml, Cargo.lock, poetry.lock, uv.lock, Gemfile.lock, composer.lock, go.sum, .terraform.lock.hcl. Hacen que todos instalen las mismas versiones. Algunas plantillas, como la de Angular, ignoran el lockfile, así que revisa el resultado.
Configuraciones de ejemplo: .env.example, config.example.yml. Indican qué valores hacen falta sin contener los secretos reales.
Wrappers de herramientas de compilación: gradlew y gradle/wrapper/, mvnw. Comprueba que el *.jar de la plantilla de Java no haya hecho que se ignore el jar del wrapper.
Ajustes de editor acordados por el equipo: .editorconfig, .vscode/settings.json, .vscode/extensions.json, .idea/codeStyles/. Compartir la configuración de formato y lint facilita las revisiones.

Poner .gitignore en subdirectorios

.gitignore no tiene por qué estar solo en la raíz. Un .gitignore de subdirectorio funciona tomando ese directorio como base y tiene prioridad sobre el archivo superior. En un monorepo, si cada paquete necesita reglas distintas, es más legible ponerlas por separado en la carpeta de cada paquete.

repo/
├── .gitignore          # común: .DS_Store, .env, coverage/
├── apps/web/.gitignore # .next/, out/
└── services/api/.gitignore # target/

Conservar directorios vacíos

git solo rastrea archivos y no guarda directorios vacíos. Para que la carpeta exista pero su contenido se ignore, como en una carpeta de registros, pon un archivo marcador dentro y recupéralo con una regla de negación.

/log/*
!/log/.keep

Nombres como .keep o .gitkeep no son una función oficial de git, solo una convención. Cualquier nombre funciona. Otra opción es poner dentro de esa carpeta un .gitignore con el siguiente contenido, que ignora todo excepto a sí mismo.

*
!.gitignore

Al combinar plantillas

Lo habitual es la combinación 1 o 2 lenguajes/frameworks + SO + editor. Si las reglas de SO y editor están en el global, puedes omitirlas.
Revisa el orden. Las plantillas con reglas de negación (Gradle, VisualStudioCode) van después de las plantillas con reglas amplias (Java, Kotlin).
Eliminar duplicados respetando el significado. Aunque se repita la misma regla el comportamiento es igual, pero cuesta más leerlo. El generador de este sitio solo elimina duplicados cuando no hay reglas de negación en medio.
Deja comentarios de sección. Unos meses después hay que poder saber de dónde viene cada regla para borrarla con seguridad.
Prueba. Pon en el probador de patrones las rutas reales obtenidas con git ls-files y comprueba que no se ignoren archivos no deseados (por ejemplo, código de frontend atrapado por el lib/ de la plantilla de Python).

Reglas cortas y concretas

Una regla demasiado amplia como *.json se traga incluso los archivos de configuración. Acota las rutas en lo posible (/dist/) y pon barra final a los directorios para distinguirlos de archivos con el mismo nombre. Si escribes el motivo en un comentario de una línea encima de la regla, la siguiente persona podrá decidir si se puede borrar.