Cómo ignorar todo por defecto en Git para evitar commits accidentales
.gitignore Everything by Default
¿Cansado de hacer commits accidentales de archivos como .DS_Store, node_modules o variables de entorno? Este artículo propone invertir la lógica de .gitignore: en lugar de permitir todo y excluir selectivamente, ignorar todo por defecto y permitir solo los archivos necesarios. Con un ejemplo práctico para un proyecto Go, muestra cómo configurar el archivo .gitignore para que solo se rastreen los archivos explícitamente permitidos. También menciona el .gitignore de 207 líneas de typescript-go y consejos útiles como verificar si un archivo está ignorado o usar lazygit.
¿Y si le diéramos la vuelta a este enfoque por completo? En lugar de permitir todo por defecto e ignorar archivos selectivamente, ¿y si ignoráramos todo por defecto y solo permitiéramos archivos específicos?
- rcfox
Esto parece un mal consejo. Muy rara vez he añadido archivos extra por accidente, pero olvidaría un 100% de las veces des-ignorar archivos que sí quería subir.
Si vas a hacer un paso de configuración inicial para ignorar todo en gitignore, ¿por qué no hacer un paso de configuración inicial para ignorar los archivos habituales? Crea una plantilla que copies en todos tus repos.
- Brajeshwar
Es extraño que bastantes desarrolladores den consejos que parecen venir de un mundo donde trabajan solos, no han trabajado con suficiente gente o con suficientes proyectos.
En este caso, un `.gitignore_global` se encarga de los sospechosos habituales que menciona: archivos `.DS_Store`, configuraciones de IDE, archivos comprimidos, etc. Incluso si algo sale mal, normalmente se detecta durante el andamiaje inicial antes de que entren archivos críticos.
Si trabajas con desarrolladores nuevos, jóvenes o novatos, dales la lección típica sobre el gitignore global, local, config, y que tengan dotfiles, etc. Da los tuyos como inspiración o como punto de partida.
Edito: Sé que los míos no son los mejores dotfiles de internet, pero esto me ha ayudado a cambiar entre múltiples dispositivos, múltiples identidades (trabajo, proyectos, personal, etc.) fácilmente. Recientemente lo limpié y le añadí automatización, pruebas, etc. con Claude Code. https://github.com/brajeshwar/dot
- isityettime
¿Qué tal si simplemente aprendes a usar `git add` correctamente? ¿Estás tan comprometido a usar `git add -A` todo el tiempo? No es difícil tener archivos sin commitear en tu árbol de trabajo sin tocar el .gitignore para nada.
- caseyw
Yo no ignoro por defecto, solo añado al stage los elementos que quiero explícitamente.
No puedo decirte cuántas veces he estado emparejado con alguien y simplemente dicen "git add .", siempre me confunde esa elección.
Lo entiendo, pero he visto más problemas surgir de añadir todo que de ser consistentemente selectivo. Cada uno con lo suyo.
- flexagoon
> otra basura (CLAUDE.md por ejemplo) que no debería estar en tu repositorio
¿Cómo es CLAUDE.md/AGENTS.md "basura que no debería estar en tu repositorio"? Si estás usando agentes para un proyecto y tienes algunas reglas específicas del proyecto para ellos, ¿por qué querrías que otras personas que usan agentes en tu repositorio no tengan acceso a esas reglas y produzcan código peor?
- yipinwong
Enfoque muy de ingeniero de seguridad.
Bloqueo todos los puertos en el VPS, y luego abro uno a uno.
Mismo enfoque aquí con los archivos.
La única desventaja que veo aquí es saber cuál permitir. Para los puertos es fácil, pero los archivos pueden tener muchas extensiones diferentes.
Las aplicaciones/CLIs, etc. crean archivos con extensiones que nunca has visto antes, lo que puede causar problemas.
Aparte de eso, me gusta el enfoque.
- matthewmc3
No estoy convencido de ignorar todo, pero uno de los mejores cambios que hice a mi flujo de trabajo con git fue ignorar todos los archivos ocultos por defecto añadiendo `.*` a ~/.config/git/ignore.
Mis proyectos ahora tienen que tener una plantilla para des-ignorar los comunes (!.gitignore, !.gitattributes, !.github, !.editorconfig, etc.), pero luego soy libre de tirar archivos .foo.lang, o directorios .tmp/.cache, o ayudantes de Claude como .code_analysis.md, o .todos.txt, o lo que sea en mi proyecto sin gestionar las consecuencias de olvidar gestionar el .gitignore. Me sorprende que más gente no siga este camino.
- ryanbrunner
El problema con este enfoque (que su primer ejemplo ya demuestra) es que casi de inmediato empezarás con una solución de "este tipo de archivo está bien", y si algo debería ir en git no tiene una correlación muy fuerte con el tipo de archivo.
Esto dificulta `git status` y esencialmente te obliga a llevar la cuenta de lo que has cambiado tú mismo (ya que los archivos ignorados no aparecerán ahí), y puede infundir una falsa sensación de seguridad de que `git add .` es seguro cuando podría no serlo.