Los archivos mágicos de Git

 (nesbitt.io)
45 puntos por GN⁺ 2026-02-24 | 2 comentarios | Compartir por WhatsApp
  • Git controla su forma de funcionar mediante archivos específicos dentro del repositorio, que no son configuración interna de .git/, sino archivos que se confirman y viajan junto con el código
  • .gitignore, .gitattributes, .lfsconfig, .gitmodules, .mailmap, etc. se encargan respectivamente de excluir archivos del seguimiento, definir atributos, configurar LFS, administrar submódulos y unificar autores
  • .git-blame-ignore-revs y .gitmessage permiten ignorar commits de formateo de código y usar plantillas de mensajes de commit, mejorando la calidad de la colaboración
  • GitHub, GitLab, Gitea, etc. amplían funciones como CI/CD o asignación de revisores mediante carpetas de configuración específicas de cada forja como .github/, .gitlab/ y .gitea/
  • Esta estructura se aplica también más allá de Git, en herramientas como EditorConfig, Docker y gestores de versiones de lenguajes, formando un ecosistema de configuración automática basado en dotfiles

Principales archivos mágicos de Git

  • Git reconoce varios archivos especiales como .gitignore, .gitattributes, .lfsconfig, .gitmodules y .mailmap para controlar el comportamiento del repositorio
    • Estos archivos no son configuración interna de .git/, sino componentes compartidos que se confirman en el repositorio, lo que garantiza un comportamiento consistente al colaborar

.gitignore

  • Define patrones de archivos que Git no debe rastrear
    • Soporta comodines (*.log), directorios (dist/) y negaciones (!important.log)
    • Se aplica en el orden .gitignore, .git/info/exclude, configuración global (~/.config/git/ignore)
  • Los archivos ya rastreados seguirán siéndolo incluso después de agregar .gitignore, y pueden eliminarse con git rm --cached
  • GitHub, GitLab y Gitea permiten confirmar archivos que coinciden con patrones ignorados sin mostrar advertencias
  • GitHub ofrece plantillas de .gitignore por lenguaje en su repositorio oficial

.gitattributes

  • Controla por archivo filtros, diff, merge, finales de línea y detección de lenguaje
    • Ej.: *.psd filter=lfs, *.png binary, *.sh text eol=lf
  • text normaliza finales de línea, binary desactiva diff/merge y merge=ours conserva la versión local en caso de conflicto
  • GitHub Linguist lee .gitattributes para excluir estadísticas de lenguaje, plegar código generado y excluir documentación, entre otros usos
  • También reconoce .gitattributes por directorio y .git/info/attributes

.lfsconfig

  • Guarda la configuración de Git LFS junto con el repositorio
    • Permite configurar la URL del servidor LFS, la cantidad de reintentos de transferencia y más
    • Ej.: 
      [lfs]
    url = https://lfs.example.com/repo
[lfs "transfer"]
    maxretries = 3
  • .gitattributes define qué archivos se manejan con LFS, y .lfsconfig se encarga de los detalles como la ubicación del servidor
  • Para mover archivos ya existentes en commits anteriores a LFS, se necesita el comando git lfs migrate

.gitmodules

  • Guarda la información de configuración de submódulos
  • Se crea con git submodule add y se consulta con git submodule update
  • Al hacer git clone, los submódulos no se descargan automáticamente; se necesita la opción --recurse-submodules
  • Tiene desventajas como no poder rastrear rangos de versiones y generar directorios .git anidados

.mailmap

  • Permite unificar nombres y correos electrónicos de autores
    • Ej.: 
      Jane Developer <[email protected]> <[email protected]>
  • Se muestra con el nombre unificado en git log, git shortlog, git blame, etc.
  • El gráfico de contribuidores de GitHub no refleja mailmap
  • La ubicación puede definirse con .mailmap o con la configuración mailmap.file

.git-blame-ignore-revs

  • Define una lista de commits que git blame debe ignorar
    • Excluye cambios sin significado, como ejecución de formateadores o aplicación de lint
    • Ej.: 
      # Ran prettier on entire codebase
a1b2c3d4e5f6g7h8i9j0...
  • Se activa con git config blame.ignoreRevsFile .git-blame-ignore-revs
  • GitHub, GitLab (15.4+) y Gitea lo reconocen automáticamente
  • Si el archivo no existe, puede producirse un error, por lo que se recomienda mantener un archivo vacío

.gitmessage

  • Define una plantilla de mensaje de commit
    • Ej.: 
      # <type>: <subject>
#
# Types: feat, fix, docs, style, refactor, test, chore
  • Requiere configurarse con git config commit.template .gitmessage
  • Después de clonar, hace falta una configuración manual; algunos equipos lo automatizan con herramientas como husky
  • Como alternativa, se pueden usar hooks commit-msg o prepare-commit-msg

Carpetas de extensión específicas de cada forja

  • GitHub, GitLab, Gitea, Forgejo y Bitbucket usan sus propias carpetas de configuración
    • .github/, .gitlab/, .gitea/, .forgejo/, .bitbucket/
  • Incluyen flujos de trabajo de CI/CD, plantillas de issues y PR, archivos CODEOWNERS, etc.
  • Forgejo usa fallback en el orden .forgejo/ → .gitea/ → .github/, y Gitea en el orden .gitea/ → .github/
  • SourceHut usa .build.yml o .builds/*.yml

Otros archivos convencionales

  • .gitkeep: como Git no rastrea directorios vacíos, se usa como archivo dummy para conservarlos
  • .gitconfig: ofrece ejemplos de configuración de Git por proyecto, pero no se carga automáticamente
  • .gitsigners: administra la lista de claves de firma GPG/SSH y puede especificarse con gpg.ssh.allowedSignersFile
  • .gitreview: archivo de configuración del servidor de revisión de código Gerrit
    • Ej.: 
      [gerrit]
host=review.opendev.org
port=29418
project=openstack/nova.git
defaultbranch=master
  • .gitlint: define reglas de lint para mensajes de commit
    • Ej.: 
      [general]
ignore=body-is-missing
[title-max-length]
line-length=72
  • .jj/: directorio de estado de Jujutsu, un VCS compatible con Git, que puede coexistir con .git/

El ecosistema de dotfiles más allá de Git

  • .editorconfig: mantiene un estilo de código consistente entre editores
    • Define indentación, finales de línea, codificación, eliminación de espacios en blanco, etc.
    • Es compatible con editores principales como VS Code, Vim y Emacs
  • .ruby-version, .node-version, .python-version: herramientas de gestión de versiones de lenguajes como rbenv, nodenv y pyenv las leen para cambiar automáticamente de versión
  • .tool-versions: archivo de gestión multilenguaje de asdf
  • .dockerignore: especifica archivos a excluir durante el build de Docker
    • Usa la misma sintaxis de patrones que .gitignore, mejora la velocidad de build y excluye información sensible

Aspectos a considerar al desarrollar herramientas integradas con Git

  • Las herramientas que manejan repositorios Git deben reconocer obligatoriamente los siguientes archivos
    • .gitignore: aplicar patrones ignorados al explorar archivos
    • .gitattributes: distinguir archivos binarios y generados
    • .mailmap: mostrar información de autores de forma unificada
    • .gitmodules: manejar submódulos
  • El formato de los archivos de configuración de Git sigue la estructura [section "subsection"] key = value, y puede leerse o escribirse con el comando git config
  • La mayoría de las bibliotecas Git para distintos lenguajes ofrecen funciones para analizar este formato

Lecturas relacionadas

2 comentarios

 
wedding 2026-02-24

No conocía gitmessage, pero creo que voy a probarlo.
 
GN⁺ 2026-02-24
Comentarios de Hacker News
  • Se dijo que GitHub, GitLab y Gitea respetan .gitignore y por eso no muestran archivos ignorados en la UI web, pero esa explicación parece incorrecta
    En realidad no se muestran porque los archivos ignorados no están incluidos en el repositorio. Si un archivo ya fue committeado, más bien debería mostrarse
    • No es así. Aunque agregues un archivo ya pusheado después a .gitignore, igual sigue viéndose en la UI. Eso es porque el archivo sigue siendo parte del repo
      En cambio, también es posible hacer commit a un archivo ignorado desde el principio, pero requiere un pequeño truco
    • Sí, el comentario original está equivocado. .gitignore solo decide si ocultar archivos untracked o no. Si quieres, también puedes hacer commit de archivos ignorados
    • Me hace pensar que estaría bien tener una opción como showinwebui=(true|false) 😄
    • Sentí que esa clase de error no podía haberlo escrito una persona directamente, así que dejé de leer en esa parte
  • Quiero destacar .git/info/exclude. Es como un gitignore solo local, una configuración solo para mí
    Por ejemplo, sirve cuando estás investigando un bug y quieres dejar archivos temporales aunque cambies de rama
    Yo uso un alias de shell como este 
    git-ignore-local () {
  echo "$1" >> .git/info/exclude
}
    Así puedo agregar algo fácilmente con git-ignore-local myfile.ext
    • Hice una versión un poco más mágica para que funcione aunque no estés en el directorio raíz
      En macOS solo hay que ajustar la parte de readlink 
      git-ignore-local () {
  root=$(git rev-parse --show-toplevel)
  path=$(readlink -f "$1")
  relpath=$(relpath -m --relative-to="$root" "$path")
  echo "$relpath" >> "${root}.git/info/exclude"
}
      Si registras esta función en el PATH como git-ignore-local, puedes usarla como git ignore-local
    • .git/info/exclude también se menciona al inicio de la explicación de .gitignore
    • No conocía esta función. En mi proyecto los PR se han vuelto confusos por estos pequeños archivos temporales, y esto parece resolverlo
  • Si agregas /test export-ignore en .gitattributes, puedes excluir archivos de prueba al desplegar en un servidor de producción
    Cuando una herramienta de despliegue como Capistrano usa git export, esto se aplica automáticamente, así que los archivos de prueba no suben al servidor
    No afecta el desarrollo y además ahorra espacio en disco
    • Es una buena función, pero parece que la mayoría ni siquiera conoce bien git archive
      Casi no lo he visto usarse ni en herramientas básicas de CI. Capistrano fue el primer caso donde vi que se aprovechaba
      Como referencia, con la opción export-subst también puedes insertar dentro de un archivo información parecida a git describe
  • Al usar jj, quería excluir por completo la carpeta .jj del repo y de todas las operaciones de Git
    Incluso que no se borrara con git clean -xdf. Por ahora lo resuelvo con un alias temporal: git clean -e .jj
    • Basta con usar .git/info/exclude
  • El contributor graph de GitHub no soporta .mailmap
    La discusión relacionada está en GitHub Community Discussion
  • Me parece riesgoso usar la configuración package-lock.json merge=ours
    Porque en merge o rebase el significado de ours/theirs no es claro
    Ese tipo de configuración solo tiene sentido en herramientas de fusión automatizada, como git-annex branch
    Referencia: explicación del significado de ours/theirs, estructura interna de git-annex
  • .git-blame-ignore-revs es una buena función, pero debería ir en la sección de “otras convenciones”
    Si no lo configuras en el cliente de git, en un repositorio donde ese archivo no exista git blame falla
  • En general me parece una lista bien organizada
    Eso sí, es una lástima que no todas las herramientas soporten .mailmap. Por ejemplo, IntelliJ todavía lo tiene como bug/solicitud de función
    Además, .git-blame-ignore-revs es solo una convención; hay que configurarlo manualmente para que funcione
  • Es un tema un poco distinto, pero hace poco me enteré de que VS Code también reconoce archivos .ignore
    Pensaba que solo aplicaba .gitignore, pero al cambiar la configuración de ripgrep en .ignore los resultados de búsqueda cambiaron. Resultó ser un comportamiento razonable
  • El autor del artículo también publicó una continuación sobre forge-specific repository folders (una especie de “carpetas mágicas”)
    Enlace: artículo de nesbitt.io