.gitignore Todo por defecto

Artículo original ↗ Discusión en Hacker News ↗

Quienes defienden “.gitignore todo por defecto” sostienen que reduce el riesgo de cometer accidentalmente secretos, restos del sistema operativo o artefactos del IDE, especialmente cuando la gente usa habitualmente `git add .`. Los críticos responden que este enfoque oculta archivos nuevos de `git status`, aumenta la probabilidad de omitir archivos fuente importantes y es frágil en entornos colaborativos. Muchos recomiendan en cambio plantillas globales y a nivel de proyecto para .gitignore, un staging más disciplinado (`git add -p`, evitar `git add .`), o herramientas y comprobaciones de CI para imponer qué se debe y qué no se debe cometer.

Reacción general a “.gitignore everything by default”

  • Muchos lo consideran malo o excesivo: arriesga olvidar des-ignorar archivos importantes, romper compilaciones/CI y ocultar archivos que faltan en git status.
  • Sus defensores lo ven como una estrategia defensiva, de “denegar por defecto” / con mentalidad de seguridad, para evitar commits accidentales de secretos, basura o desorden específico de herramientas.
  • Varios señalan que funciona mejor para ciertos contextos (p. ej., contextos de compilación de Docker, experimentos con Unity, repositorios muy estructurados) que para el desarrollo general.

Staging selectivo vs git add . indiscriminado

  • Tema fuerte: evitar git add . / git add -A a ciegas.
    • Alternativas defendidas: git add -u, git add -p, staging interactivo y revisar git status antes y después de añadir.
  • Algunas personas estructuran el trabajo para que git add . sea seguro (árbol limpio, un único cambio coherente).
  • Desacuerdo sobre la reversibilidad: algunos creen que “añadir todo” es fácil de deshacer; otros señalan que muchos usuarios no saben o no usan git reset / git restore --staged.

Estrategias globales y locales de ignore

  • Ampliamente recomendado: un ignore global de usuario (~/.config/git/ignore o similar) para archivos del sistema/editor/herramientas (.DS_Store, configuraciones de IDE, restos de Emacs/Vim).
  • Otros sostienen que .gitignore a nivel de repositorio también debería ignorar de forma defensiva artefactos comunes de SO/editor, ya que no todo el mundo mantiene un ignore global.
  • Patrones populares:
    • Ignorar globalmente todos los dotfiles (.*) pero des-ignorar explícitamente los importantes (!.gitignore, !.editorconfig, etc.).
    • Directorios dedicados de pruebas/sandbox o .gitignore por directorio con * para archivos desechables.
    • Usar .git/info/exclude para ignores personales, locales al repositorio, que no se comparten.

Archivos de configuración de IA/agentes (p. ej., CLAUDE.md)

  • Hay desacuerdo sobre si deben estar en el repositorio:
    • Algunos ven las instrucciones de IA a nivel de proyecto como documentación compartida útil.
    • Otros las ven como volcados de preferencias personales, más cercanos a configuraciones del editor, y prefieren una variante estilo .local ignorada por git.

Herramientas, CI y salvaguardas alternativas

  • Varios recomiendan GUIs/TUIs (Magit, lazygit, tig, integraciones del IDE) para diffs visuales y staging a nivel de hunks.
  • Algunos usan linters/hooks (p. ej., alint) o reglas de CI para bloquear rutas no permitidas.
  • Un fallo de CI por archivos faltantes se ve como menos dañino que filtrar secretos, pero otros se preocupan por trabajo perdido y problemas de “funciona en mi máquina”.