Git kimliği ayarlarımı nasıl yönetiyorum

• Hem kişisel hem de iş depolarını ~/workspace altında tutulan bir ortamda, Git kimliğini klasör konumuna göre değil remote URL temelinde ayırmak daha doğru olur
• Git'in includeIf özelliği gitdir ile yol bazlı ayarları yükleyebilir, ancak aynı çalışma dizini içinde farklı hesaplara ait depolar karışıyorsa yol temelli dallanma sınırlarına ulaşır
• hasconfig:remote.*.url: koşulu kullanılırsa GitHub, GitLab, SourceHut veya belirli bir GitHub organizasyonu gibi remote URL desenlerine göre ayrı yapılandırma dosyaları dahil edilebilir
• SSH anahtarları ~/.ssh/config içinde Host, Hostname, User, IdentityFile ile ayrıca yönetilmelidir; aynı github.com üzerinde bile organizasyona göre farklı anahtar kullanmak için Host takma adı gerekir
• url.<base>.insteadOf birlikte ayarlanırsa her zamanki gibi [e-mail]:orgname/project kullanırken içeride bunun gh-work:orgname biçimine çevrilmesi ve doğru SSH yapılandırmasının devreye girmesi sağlanır

---

Git ayarlarını remote URL'e göre ayırmak

• Mevcut includeIf örnekleri, gitdir:~/code/**, gitdir:~/work/** gibi yerel dizin yollarına göre farklı yapılandırma dosyalarını dahil eder
  • ~/code altında ~/.config/git/personal, ~/work altında ise ~/.config/git/work yüklenebilir
  • Dahil edilen dosyalarda genellikle user.name, user.email, user.signingkey gibi Git kimliği ve imza anahtarı ayarları bulunur
• Tüm kodu ~/workspace altında tutarsanız kişisel, work-1, work-2 depoları aynı yol yapısı içinde karışabilir; bu yüzden yalnızca yol tabanlı koşullarla istenen ayrımı yapmak zorlaşır
• Git'in hasconfig:remote.*.url: özelliği kullanılırsa, mevcut depoda belirli bir remote URL bulunduğunda yapılandırma dosyası yalnızca o zaman dahil edilebilir
  • [e-mail]:*/** ile eşleşirse ~/.config/git/config-gh
  • [e-mail]:orgname/** ile eşleşirse ~/.config/git/config-gh-org
  • [e-mail]:*/** ile eşleşirse ~/.config/git/config-gl
  • [e-mail]:*/** ile eşleşirse ~/.config/git/config-srht
• Git son eşleşen yapılandırmayı dahil ettiğinden koşul sırası önemlidir
  • github.com:orgname/** koşulu, genel github.com:*/** koşulunun altında yer almalıdır; aksi halde organizasyona özel ayar genel GitHub ayarı tarafından ezilebilir
• Sonuç olarak github.com:orgname/** remote'una sahip depolar config-gh-org kullanır; diğer GitHub depoları ise genel GitHub yapılandırmasını kullanır

SSH anahtarları ve insteadOf ile organizasyon bazlı bağlantı bilgilerini eşleştirmek

• Git kimliğinden ayrı olarak, remote'a pull ve push yapabilmek için SSH anahtarı yapılandırması gerekir
  • ~/.ssh/config içinde gitlab.com için ~/.ssh/gitlab.id_ed25519
  • github.com için ise ~/.ssh/github.id_ed25519 gibi IdentityFile belirtilebilir
• ssh-agent ayarına bağlı olarak her Host için IdentityFile altına IdentitiesOnly yes eklemek faydalı olabilir
• Aynı Hostname olan github.com üzerinde organizasyona göre farklı anahtarlar kullanmak istiyorsanız Host değerlerini farklı vermelisiniz
  • Yapılandırma Host gh-work, Hostname github.com, User git, IdentityFile ~/.ssh/work.id_ed25519 biçimindedir
• Git ayarlarında url "gh-work:orgname" ve insteadOf = [e-mail]:orgname kullanılırsa Git URL'si otomatik olarak dönüştürülebilir
  • Kullanıcı git clone [e-mail]:orgname/project gibi bir komut girer
  • Git, github.com:orgname kısmını gh-work:orgname olarak değiştirir ve ~/.ssh/config içindeki gh-work ayarını kullanır
• Bu yöntem, SSH and multiple Git credentials yazısındaki bir hileden alınmıştır; birlikte başvurulan diğer yazılar şunlardır
  • 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⁺]

Hacker News yorumları

• insteadOf yerine depoyu gh-work:org/repo olarak klonlayıp Git ayarlarına includeIf "hasconfig:remote.*.url:gh-work:**/**" koyuyor
  Böylece gh-work altında tanımlı SSH kimliği ile klonlanan depo, içinde Git kimliği ve SSH ayarlarıyla aynı imza anahtarı bulunan gh-work.inc ayarlarını otomatik olarak alıyor
  Sonuçta gh-work adı SSH kimliği ile Git kimliğini ayıran ölçüt oluyor ve anlaması daha kolay hale geliyor

  • Yazıdaki çözüm, gerekenden fazla serbestlik derecesi varmış gibi geldiği için içime sinmemişti; çalışma zamanı parametresini bire indiren zarif bir yöntem gibi görünüyor
  • includeIf büyük/küçük harfe duyarlıdır ve öncelikte en son ayar kazanır
    Düzgün çalışıp çalışmadığını kontrol etmek için git remote get-url origin ve git config --get user.email çalıştırılabilir
  • Bu yöntem, uzak depo URL’sinin belirli bir biçimde olduğunu varsayan betikleri bozabilir

• Daha iyi yöntemin, HOME altındaki .gitconfig içinde kimliğe göre alias’lar tanımlayıp depoyu başlattıktan veya klonladıktan hemen sonra git config-company ya da git config-personal çalıştırmak olduğunu düşünüyorum
  user.useConfigOnly = true açılıp alias içinde yerel deponun user.email, user.name, core.sshCommand değerleri sırasıyla kişisel/şirket SSH anahtarına ayarlanabilir

  • Başlangıçtaki klonlamanın en baştan doğru SSH ayarları olmadan nasıl yapılacağı sorun olarak kalıyor
    Yazıdaki yöntemin, organizasyondan klonlayınca doğrudan çalışması avantaj gibi görünüyor

• Eskiden bir startup’ta her gün kimliğini masal karakteri gibi rastgele bir ada çeviren biri vardı
  Pazartesi commit’leri Mr. Bunnymann, salı commit’leri Doctor Funtime gibiydi; sürüm kontrol forensiği yaparken çok zahmetliydi
  İyi niyetle bakarsak, herkes kimlik ayarına herhangi bir değer koyabildiği için bu değere fazla güvenilmemesi gerektiğini hatırlatmaya çalışıyor olabilir

  • Suçlama içermeyen bir kültürde, sürüm kontrol forensiğinde kimin yaptığı değil; ne zaman ve hangi değişikliklerin etrafında olduğu daha önemli olurdu
    Yine de ayrıntı sormak veya stil ve uzmanlığı öngörmek için kimin yaptığını bilmek faydalıdır
    Commit’lerde GPG imzası zorunlu tutulup izin verilen GPG kimlikleri kaydedilirse, yazar/committer meta verileri yerine imza üzerinden gerçek yazar tanımlanabilir
    Tabii “basitçe” ile GPG imzası her zaman iyi anlaşmaz
  • Bir çalışanın yazdığı belgeye ya da imzasına ne kadar güveniyorsanız buna da o kadar güvenebilirsiniz
    Çalışanın kendi commit’lerini düzgün tanımlayacağına güvenemiyorsanız, bence işten çıkarmalısınız
  • İyi niyetle bakınca, aynı imza anahtarını kullanıp kullanmadığını merak ediyorum
  • Böyle bir şaka için para almış olması şaşırtıcı
  • Git’te yazar ve committer’ı ayırmak için yerleşik destek var; muhtemelen yalnızca author niteliğini değiştirmiştir

• ~/.ssh/config dosyasına dokunmaya gerek kalmadan, ~/.gitconfig içine ya da yazıdaki gibi ~/.config/git/personal içine core.sshCommand = /usr/bin/ssh -o IdentitiesOnly=yes -i ~/.ssh/IdentityFile2 -a koyabilirsiniz
  Böylece insteadOf olmadan da submodule işleri kolaylaşır

  • Birden fazla SSH kimliği varsa ne yapılacağı sorusu kalıyor

• Uzun süredir dizin tabanlı includeIf kullanıyordum (https://www.bobek.cz/til/git-identities/); hasconfig:remote gerçekten çok temiz
  Depo klonlanırken de çalışıyor

• includeIf oldukça iyi
  Şu anda SSH karmaşıklığını ~/.ssh altında tutuyor, her müşteri/proje/kimlik için bir include kullanıyorum
  GitHub gibi benzersiz host adı olmayan yerlere customer-github gibi host alias’ı verip HostName github.com, IdentityFile ~/.ssh/customer_rsa, User git şeklinde ayarlıyorum
  Sonrasında git clone içinde sadece o alias’ı kullanmak yeterli

  • Birden fazla GitHub SSH kimliğini yönetmek için 12 yıl önce bir araç yapmıştım ve hâlâ bakımını sürdürüyorum: https://github.com/dolmen/github-keygen

• Aynı sorunu yaşıyordum ve artık bir çözüm çıkmış oldu
  NixOS ve home-manager’ı Linux ve Mac’te kullanırsanız bu ayar basitleşiyor
  programs.git.includes içine condition = "hasconfig:remote.*.url:[e-mail]:/**" ve user.email ayarını koymak yeterli
  Referans: https://nix-community.github.io/home-manager/options.xhtml#opt-programs.git.includes

  • Doğrudan .gitconfig içine yazmaktan daha az basit görünüyor
    Yazıdakiyle aynı koşul ve ayar; buna bir de build/şablon aşaması ve tuhaf söz dizimine sahip yeni bir programlama dili öğrenmek ekleniyor

• Zaten includeIf: "gitdir" ile iş ve kişisel ayarlarımı ayırıyordum; hasconfig:remote ise oyunun kurallarını tamamen değiştiren bir özellik

  • Bu cevherin 3 yıl boyunca taslak olarak saklı kalmış olmasına inanamıyorum

• Danışmanlara her zaman iş için ayrı bir makine kullanmalarını ya da en azından ayrı bir OS kullanıcısı kullanmalarını güçlü şekilde öneririm
  Kişisel makineyi iş için kullanmak ciddi sıkıntı yaşama riski doğurur

  • “Kişisel makineyi iş için kullanmak” çok geniş bir kapsam
    Remote-first bir şirkette dizüstü bilgisayarı kendiniz temin edip 2-3 yılda bir yeni cihaz alma parası almanıza rağmen bunun hâlâ kişisel laptop olduğu durumlar da var; geçici sözleşmeli çalışan da olabilirsiniz
    Hangi durumda neden sorun olduğunu daha somut açıklamak gerekir
    Risk gerçekten var, ama sıralayamıyorsanız bu eğitimden çok FUD yaymaya yaklaşır

• Proje bazında Git kimliğini kolayca değiştirmek için yaptığım araç: https://github.com/cquintana92/git-switch-user
  Kimliği ayarladıktan sonra $ git su Personal veya $ git su Work çalıştırınca e-posta, ad, SSH anahtarı ve isteğe bağlı olarak PGP anahtarı da deponun .git/config dosyasına yazılıyor
  Bana çok zaman kazandırdı

  • SSH üzerinden Git erişimi için GitHub kimliği yönetimi aracı da var: https://github.com/dolmen/github-keygen
    12 yıllık bir araç ama hâlâ aktif olarak bakımı yapılıyor