Cómo configuro mi identidad de Git

• En un entorno donde tanto los repositorios personales como los de trabajo están en ~/workspace, es más preciso dividir la identidad de Git según la URL remota que según la ubicación de la carpeta
• El includeIf de Git puede cargar configuraciones por ruta con gitdir, pero si se mezclan repositorios de varias cuentas dentro del mismo directorio de trabajo, la ramificación basada en rutas llega a su límite
• Si usas la condición hasconfig:remote.*.url:, puedes incluir archivos de configuración separados según patrones de URL remota, como GitHub, GitLab, SourceHut o una organización específica de GitHub
• Las claves SSH deben administrarse por separado en ~/.ssh/config con Host, Hostname, User e IdentityFile, y si quieres usar claves distintas por organización incluso en el mismo github.com, necesitas un alias de Host
• Si configuras también url.<base>.insteadOf, puedes seguir usando [e-mail]:orgname/project como siempre, pero internamente se reemplazará por gh-work:orgname, haciendo que se aplique la configuración SSH correcta

---

Separar la configuración de Git según la URL remota

• Los ejemplos tradicionales de includeIf incluyen distintos archivos de configuración según la ruta del directorio local, por ejemplo gitdir:~/code/** o gitdir:~/work/**
  • Debajo de ~/code puedes cargar ~/.config/git/personal, y debajo de ~/work, ~/.config/git/work
  • Los archivos incluidos normalmente contienen la identidad de Git y la clave de firma, como user.name, user.email y user.signingkey
• Si todo tu código está en ~/workspace, los repositorios personales, work-1 y work-2 pueden quedar mezclados en la misma estructura de rutas, así que resulta difícil separarlos como quieres usando solo condiciones basadas en ruta
• Si usas hasconfig:remote.*.url: de Git, puedes incluir un archivo de configuración solo cuando el repositorio actual tenga una URL remota específica
  • Si coincide con [e-mail]:*/**, usa ~/.config/git/config-gh
  • Si coincide con [e-mail]:orgname/**, usa ~/.config/git/config-gh-org
  • Si coincide con [e-mail]:*/**, usa ~/.config/git/config-gl
  • Si coincide con [e-mail]:*/**, usa ~/.config/git/config-srht
• Git incluye la última configuración que haga match, así que el orden de las condiciones es importante
  • La condición github.com:orgname/** debe ir debajo de la condición general github.com:*/** para que la configuración exclusiva de la organización no quede sobrescrita por la configuración general de GitHub
• Como resultado, los repositorios que tengan un remote github.com:orgname/** usarán config-gh-org, y los demás repositorios de GitHub usarán la configuración general de GitHub

Ajustar la información de conexión por organización con claves SSH e insteadOf

• Además de la identidad de Git, necesitas configurar claves SSH para poder hacer pull y push al remote
  • En ~/.ssh/config, puedes asignar ~/.ssh/gitlab.id_ed25519 a gitlab.com
  • Y ~/.ssh/github.id_ed25519 a github.com mediante IdentityFile
• Dependiendo de cómo tengas configurado ssh-agent, puede ser recomendable agregar IdentitiesOnly yes debajo de IdentityFile en cada Host
• Si quieres usar claves distintas por organización en el mismo Hostname, github.com, necesitas darle valores distintos a Host
  • La configuración tendría la forma Host gh-work, Hostname github.com, User git, IdentityFile ~/.ssh/work.id_ed25519
• Si en la configuración de Git usas url "gh-work:orgname" junto con insteadOf = [e-mail]:orgname, Git puede reemplazar la URL automáticamente
  • El usuario escribe algo como git clone [e-mail]:orgname/project
  • Git reemplaza la parte github.com:orgname por gh-work:orgname y usa la configuración gh-work de ~/.ssh/config
• Este método es un truco tomado de SSH and multiple Git credentials, y también se consultaron los siguientes artículos
  • https://fundor333.com/post/2021/advance-git-config-and-ssh-config/
  • https://www.kenmuse.com/blog/ssh-and-multiple-git-credentials/#git
  • https://garrit.xyz/posts/2023-10-13-organizing-multiple-git-identities
  • https://stevenharman.net/configure-ssh-keys-for-multiple-github-accounts

[GN⁺]

Opiniones en Hacker News

• En vez de usar insteadOf, clonar el repositorio como gh-work:org/repo y poner en la configuración de Git includeIf "hasconfig:remote.*.url:gh-work:**/**"
  Así, los repositorios clonados con la identidad SSH definida bajo gh-work toman automáticamente la configuración de gh-work.inc, que contiene la identidad de Git y la clave de firma, como la configuración SSH
  Al final, el nombre gh-work se vuelve el criterio para distinguir la identidad SSH y la identidad de Git, lo que lo hace más fácil de entender

  • La solución del artículo me dejaba incómodo porque parecía tener más grados de libertad de los necesarios, pero esto parece una forma elegante de reducir los parámetros en tiempo de ejecución a uno solo
  • includeIf distingue mayúsculas y minúsculas, y en la prioridad gana la última configuración
    Para comprobar si funciona correctamente, basta con ejecutar git remote get-url origin y git config --get user.email
  • Este enfoque podía romper scripts que esperaran que la URL del repositorio remoto tuviera una forma específica

• Creo que una mejor forma es poner alias por identidad en .gitconfig dentro de HOME y, justo después de inicializar o clonar un repositorio, ejecutar git config-company o git config-personal
  Activas user.useConfigOnly = true y, en los alias, configuras user.email, user.name y core.sshCommand del repositorio local con las claves SSH personales/de la empresa, respectivamente

  • El problema es cómo hacer el clon inicial sin la configuración SSH correcta desde el principio
    La ventaja del enfoque del artículo parece ser que, si clonas desde la organización, simplemente funciona

• Antes, en una startup había una persona que cambiaba su identidad todos los días por algún nombre de cuento de hadas
  Los commits del lunes eran de Mr. Bunnymann, los del martes de Doctor Funtime, y así, por lo que era muy molesto al hacer forense de control de versiones
  Si se mira con generosidad, quizá intentaba recordarnos que cualquiera puede poner cualquier valor en la configuración de identidad, así que no deberíamos confiar demasiado en ese dato

  • En una cultura sin culpas, en el forense de control de versiones habría sido más importante cuándo ocurrió y alrededor de qué cambios, que quién lo hizo
    Aun así, saber quién lo hizo ayuda para preguntar detalles o anticipar estilo y experiencia
    Si se exigen firmas GPG en los commits y se registran las identidades GPG permitidas, se puede identificar al autor real por la firma en vez de por los metadatos de autor/committer
    Claro que “simple” y las firmas GPG no siempre van de la mano
  • Basta con confiar en eso tanto como confías en los documentos o firmas que escribe un empleado
    Si no puedes confiar en que un empleado identifique correctamente sus propios commits, creo que deberías despedirlo
  • Si se mira con generosidad, me pregunto si usaba la misma clave de firma
  • Sorprende que le pagaran por esas bromas
  • Git tiene soporte integrado para separar autor y committer, y probablemente solo cambiaba el atributo de autor

• Sin tocar ~/.ssh/config, basta con poner core.sshCommand = /usr/bin/ssh -o IdentitiesOnly=yes -i ~/.ssh/IdentityFile2 -a en ~/.gitconfig o, como en el artículo, en ~/.config/git/personal
  Así los submódulos se vuelven más fáciles incluso sin insteadOf

  • Queda la pregunta de qué hacer si hay más de una identidad SSH

• Desde hace tiempo uso includeIf basado en directorios (https://www.bobek.cz/til/git-identities/), pero hasconfig:remote es realmente impecable
  También funciona al clonar repositorios

• includeIf es bastante bueno
  Por ahora dejo la complejidad de SSH en ~/.ssh y tengo un include para cada cliente/proyecto/identidad
  Para cosas como GitHub, que no tienen un hostname único, pongo un alias de host como customer-github y lo configuro con HostName github.com, IdentityFile ~/.ssh/customer_rsa, User git
  Después, en git clone, solo uso ese alias y listo

  • Hace 12 años creé una herramienta para gestionar varias identidades SSH de GitHub y todavía la mantengo: https://github.com/dolmen/github-keygen

• Tuve el mismo problema y ahora, por así decirlo, ya hay una solución
  Si usas NixOS y home-manager en Linux y Mac, esta configuración se vuelve sencilla
  En programs.git.includes, pon condition = "hasconfig:remote.*.url:[e-mail]:/**" junto con la configuración de user.email
  Referencia: https://nix-community.github.io/home-manager/options.xhtml#opt-programs.git.includes

  • Parece menos sencillo que escribirlo directamente en .gitconfig
    Es la misma condición y configuración que en el artículo, pero además agrega una etapa de build/plantilla y aprender un nuevo lenguaje de programación con una sintaxis peculiar

• Ya estaba separando la configuración de trabajo y personal con includeIf: "gitdir", pero hasconfig:remote cambia totalmente las reglas del juego

  • No puedo creer que esta joya haya estado escondida como borrador durante 3 años

• A los consultores siempre les recomiendo firmemente usar una máquina separada para el trabajo o, como mínimo, un usuario de SO separado
  Si usas una máquina personal para trabajar, corres el riesgo de meterte en grandes problemas

  • “Usar una máquina personal para trabajar” abarca un rango muy amplio
    Puede ser una empresa remote-first donde tú consigues la laptop y cada 2 o 3 años recibes dinero para comprar una nueva, pero sigue siendo tu laptop personal; o puede tratarse de un contratista temporal
    Habría que explicar con más detalle en qué situaciones y por qué se vuelve un problema
    Los riesgos son reales, pero si no puedes enumerarlos, se parece más a difundir FUD que a educar

• Es una herramienta que hice para cambiar fácilmente la identidad de Git por proyecto: https://github.com/cquintana92/git-switch-user
  Después de configurar las identidades, ejecutas $ git su Personal o $ git su Work, y se configuran en .git/config del repositorio el correo, el nombre, la clave SSH y, opcionalmente, también la clave PGP
  Me ahorró mucho tiempo

  • También hay una herramienta para gestionar identidades de GitHub para acceso Git por SSH: https://github.com/dolmen/github-keygen
    Es una herramienta de 12 años, pero sigue con mantenimiento activo