Ignorar archivos en Git no se limita a `.gitignore`

 (nelson.cloud)
11 puntos por GN⁺ 4 시간 전 | 3 comentarios | Compartir por WhatsApp
  • Las reglas para ignorar archivos en Git se dividen en tres niveles según su alcance compartido: .gitignore, .git/info/exclude y ~/.config/git/ignore
  • .gitignore se confirma junto con el código del repositorio, por lo que es el lugar para poner reglas compartidas que el equipo o el proyecto deben aplicar en conjunto
  • Los elementos que son necesarios en el repositorio pero ambiguos para convertirlos en reglas del equipo, como archivos personales o de trabajo local, encajan mejor en .git/info/exclude
  • Los archivos que quieras excluir repetidamente en todos los repositorios, como .DS_Store en macOS, pueden colocarse en ~/.config/git/ignore, el archivo de ignore global de la máquina
  • git check-ignore -v <nombre_de_archivo> es útil para rastrear qué regla está ignorando un archivo, y si no hay ninguna regla que coincida, no produce salida

Dónde se aplican las reglas de ignore en Git

  • Git puede procesar reglas para ignorar archivos en tres ubicaciones
    • .gitignore
    • .git/info/exclude
    • ~/.config/git/ignore

.gitignore: reglas compartidas que se confirman en el repositorio

  • .gitignore es el archivo habitual donde se escriben los nombres de los archivos a ignorar
  • Se versiona en Git junto con el resto del código
  • Los archivos que coinciden con reglas de .gitignore no se tienen en cuenta al ejecutar comandos de git

.git/info/exclude: reglas personales por repositorio

  • El archivo exclude está dentro del directorio .git de cada repositorio Git
  • Los cambios en este archivo no se versionan en Git
  • En un repositorio Git nuevo, normalmente contiene unas cuantas líneas de comentario
  • Es adecuado para archivos que quieres ignorar solo en ese repositorio, pero no quieres agregar a .gitignore
    • Ejemplo: si quieres que notes.txt, necesario solo para tu flujo de trabajo personal, no se confirme en el repositorio ni se agregue al .gitignore del proyecto, puedes añadir notes.txt a .git/info/exclude

~/.config/git/ignore: reglas globales de la máquina

  • El archivo global ignore está en ~/.config/git/ignore dentro del directorio personal
  • Los nombres de archivo que agregues aquí se ignoran globalmente a nivel de máquina
  • No se versiona en Git ni está vinculado a un repositorio específico
  • Es un buen lugar para poner archivos que quieras ignorar en todos los repositorios Git de tu computadora
    • Ejemplo: en macOS, conviene añadir aquí .DS_Store

Cambiar la ruta del archivo global de ignore

  • El archivo global de ignore puede apuntar a otro archivo
  • Para usar .gitignore_global como archivo global de Git ignore, ejecuta el siguiente comando
git config --global core.excludesFile ~/.gitignore_global
  • Para volver a la configuración predeterminada, ejecuta el siguiente comando
git config --global --unset core.excludesFile

Cómo verificar qué regla está ignorando un archivo

  • Con git check-ignore -v <nombre_de_archivo> puedes ver qué regla está haciendo que se ignore un archivo específico
  • Para comprobar cómo se ignora .DS_Store, ejecuta el siguiente comando dentro de un repositorio Git
git check-ignore -v .DS_Store
  • Si el .gitignore del repositorio está ignorando .DS_Store, un ejemplo de salida es el siguiente
$ git check-ignore -v .DS_Store
.gitignore:1:.DS_Store	.DS_Store
  • Si .git/info/exclude del repositorio está ignorando .DS_Store, un ejemplo de salida es el siguiente
$ git check-ignore -v .DS_Store
.git/info/exclude:7:.DS_Store	.DS_Store
  • Si el archivo global ~/.config/git/ignore está ignorando .DS_Store, un ejemplo de salida es el siguiente
$ git check-ignore -v .DS_Store
/Users/nelson/.config/git/ignore:2:.DS_Store	.DS_Store
  • Si el archivo global personalizado .gitignore_global está ignorando .DS_Store, un ejemplo de salida es el siguiente
$ git check-ignore -v .DS_Store
/Users/nelson/.gitignore_global:1:.DS_Store	.DS_Store
  • Si no hay ninguna regla que ignore un archivo específico, el comando git check-ignore -v no produce ninguna salida

Lecturas relacionadas

3 comentarios

 
sudoeng 1 시간 전

También sería útil poner cosas como las especificaciones de trabajo o archivos plan.md en .git/info/exclude.
 
yangeok 2 시간 전

Vaya, sí que había una configuración para poner en la raíz jaja
 
GN⁺ 4 시간 전
Comentarios de Hacker News

  • Artículo interesante, pero le falta mi función favorita de casi ignorar en Git: .gitattributes
    Con este archivo puedes indicar que Git “ignore” las diferencias de ciertos archivos. Por ejemplo, en proyectos de Node, package-lock.json desde la perspectiva de Git es casi puro ruido. Solo aparecen diferencias enormes con versiones concretas de librerías, mientras que la información de versiones real y fácil de leer para humanos está aparte en package.json
    Si agregas una línea package-lock.json -diff en el .gitattributes de la raíz del proyecto, el archivo se sigue stageando y commiteando, pero en git diff ya no ves esas diferencias gigantes sin sentido

    • package-lock.json no debería ser ruido. Si no pretendes actualizarlo a propósito, no deberías modificarlo; de lo contrario te expones a riesgo en la cadena de suministro sin motivo
      Si los cambios en package-lock.json aparecen seguido de forma inesperada, estás haciendo algo mal
    • package-lock.json muestra todas las dependencias transitivas, mientras que package.json solo muestra las dependencias directas. Decir que este último contiene las “versiones reales legibles por humanos” no es cierto
      Ambos tienen propósitos distintos, y decir que siempre está bien ignorar las diferencias del lockfile es peligroso
    • Desde la perspectiva de alguien que hace upgrades de dependencias y rastrea el origen de bugs, me molestaría muchísimo que git diff no mostrara los cambios del lockfile
      Entiendo que pueda parecer ruido a nivel de líneas, pero cuando hace falta, hace muchísima falta

  • La configuración de exclusiones globales o por usuario debería ser mucho más conocida. A menudo llegan cambios que intentan agregar archivos del IDE, del SO o de IA al .gitignore de todos los proyectos; cuando les explicas que si lo ponen en la configuración estándar se ignorarán en todas partes, sin tocar cada proyecto, y además se evita el riesgo de commitearlos por accidente en proyectos cuyo .gitignore no se haya actualizado, a la mayoría le parece excelente
    Mi regla personal es que el .gitignore dentro del repositorio debería usarse solo para elementos propios del repositorio, como artefactos de build o carpetas de dependencias; la mayoría de las herramientas de usuario deberían ir en la configuración personal de cada quien

    • El hecho de que haya que recordar tan seguido la configuración global de .gitignore es una consecuencia natural del principio de usar el .gitignore del repositorio solo para elementos propios del repositorio
      Si queremos ahorrar tiempo a todo el mundo, es mejor simplemente poner esos archivos en el .gitignore de todos los proyectos
    • Siempre los he puesto en el .gitignore del proyecto para evitar que alguien, por desconocimiento, agregue esos archivos al proyecto
      Al final se van a volver a quitar de Git y esa persona la va a pasar mal, así que era una forma de ser amable y prevenirlo. Tal vez en adelante sea menos amable
    • Prefiero la opción de gitignore porque sobrevive aunque reconstruyas el contenedor de desarrollo
      Si hay que evitar gitignore, se puede restaurar o conservar la configuración con scripts de generación o volúmenes, pero eso ya requiere scripts extra o configuración de mounts en devcontainer en vez de una sola línea en .gitignore
    • ¿No se contradice un poco tener una regla estricta que prohíbe explícitamente la forma más fácil de corregir un comportamiento erróneo que sigues viendo una y otra vez?

  • Para la configuración global de Git y los archivos ignorados, me parece más correcto usar ~/.config/git/ignore y ~/.config/git/config que crear ~/.gitignore_global y cambiar la configuración
    Si aprovechas ~/.config/ para varias cosas, reduces bastante la cantidad de dotfiles en el nivel raíz
    La razón de que Git exclude se use menos es que no se commitea en el repositorio, así que hay que recrearlo cada vez que quieres usarlo. No digo que sea malo; solo que esa es la razón de su menor uso

    • Además, si pones el directorio ~/.config bajo control de versiones, luego puedes modificarlo y compartirlo más fácilmente
    • También podrías usar ~/.cvsignore para otras herramientas que utilicen el mismo archivo

  • No sé dónde lo aprendí, pero agregué attic al ignore global de Git
    Así puedes crear un directorio attic en cualquier proyecto para guardar cosas varias que jamás deberían commitearse. Hasta ahora no me he topado con ningún repositorio que revise si existe un directorio así

    • También se puede hacer algo parecido al revés, aunque hay que hacerlo caso por caso
      Si tienes un directorio como attic, puedes crear attic/.gitignore y poner /**; entonces se ignorará ese directorio y todo lo que tenga dentro, incluido el propio archivo ignore
      Normalmente yo le pongo como nombre a mi versión de ese directorio un solo carácter U+1F4A9, pero HN no permite ponerlo en los comentarios
    • En mi caso uso aux
      Le pongo dentro un .gitignore con solo un asterisco *, y así se ignora a sí mismo y todo lo que haya dentro
    • Yo también hago esto, solo que le pongo .local
    • El mío es scratch/
      Hasta ahora no me ha dado problemas

  • Sobre los ignores por usuario, en macOS se suele decir que lo ideal es poner .DS_Store ahí, pero eso implica que todos los usuarios de Mac del proyecto hagan lo mismo
    Si ya son dos o más, quizá sea mejor no dejarlo al criterio de cada quien

    • No sé bien de dónde salió, pero en mis dos Mac (una con Ventura y otra con Sequoia) existe una entrada .DS_Store en el archivo ~/.gitignore_global, y en la configuración global de Git también está la opción para ignorar lo que haya en ese archivo
      La fecha de ese archivo en la Mac nueva es de dos días antes de que la pidiera, y no recuerdo haberlo configurado yo, así que parece que ya venía por defecto. Supongo que en la Mac vieja sería parecido y, viendo las versiones de macOS, esto podría venir así por defecto desde hace bastante tiempo
      Así que quizá ya quedó atrás la época en que había que agregar .DS_Store/ al .gitignore
    • Es una forma bastante curiosa de ver a la minoría y la mayoría. Si una sola persona usuaria de macOS trabaja en diez proyectos, ¿de verdad hay que agregar esa línea en los diez proyectos, o no será mejor resolverlo una vez del lado de esa persona?

  • Vaya, ¿cómo no sabía esto? Llevo 20 años como desarrollador profesional de software y siempre he usado solo .gitignore
    Me doy cuenta de que nunca me pregunté si habría una forma mejor que llenar .gitignore de exclusiones que solo me importan a mí. Simplemente acepté el mundo tal como se veía
    Hoy el mundo es un poquito mejor

  • Uso muchísimo .git/info/exclude. Va muy bien para scripts o Makefile que solo sirven localmente y que los colaboradores no necesitan, o ni siquiera podrían usar

    • Me da curiosidad qué ejemplos habría de scripts que otros colaboradores no podrían usar. ¿Te refieres, por ejemplo, a scripts para un flujo de trabajo de PR?
    • Desde hace bastante tiempo uso una función de shell que mete en .git/info/exclude todos los archivos sin seguimiento que aparecen en git status
      Normalmente lo aplico después de hacer add y commit de lo que sí quiero guardar en el repositorio

  • En directorios de proyecto que contienen varios repositorios, uso archivos de excludes de esta forma para aplicar configuración de Git por proyecto distinta
    https://laszlo.nu/blog/project-level-git-config.html

  • Tengo estos alias relacionados
    assume = update-index --assume-unchanged
    unassume = update-index --no-assume-unchanged
    assumed = "!git ls-files -v | grep ^h | cut -c 3-"
    unassumeall = "!git assumed | xargs git update-index --no-assume-unchanged"
    assumeall = "!git st -s | awk {'print $2'} | xargs git assume"

  • Para archivos que ya están siendo rastreados, también existe git update-index --[no]-skip-worktree
    Puede servir para experimentos locales, pero como no es algo que Git deje muy visible, da un poco de flojera usarlo. Tienes que acordarte de que lo activaste y, si se te olvida, puede bloquear otras operaciones como hacer checkout