Git ‘fatal: detected dubious ownership in repository’ hatası ve güvenli çözümü

Git dubious ownership hatasının nedenini belirleyin; depo sahipliğini düzeltin veya yalnızca doğruladığınız dizini safe.directory listesine ekleyin.

Git’in “fatal: detected dubious ownership in repository” hatası, depo klasörünün sahibiyle Git komutunu çalıştıran kullanıcı arasında beklenmeyen bir fark gördüğünde oluşur. Bu kontrol, başka bir kullanıcının hazırladığı depodaki config veya hook davranışlarının güvenilir kabul edilmesini önlemeye yardımcı olur.

En hızlı görünen safe.directory '*' ayarı bütün depolar için korumayı kapatır. Önce sahipliğin neden farklı olduğunu bulun; yalnızca gerçekten güvendiğiniz depo için dar kapsamlı bir çözüm uygulayın.

1. Komutu hangi kullanıcı çalıştırıyor?

whoami
id
git rev-parse --show-toplevel
ls -ld /path/to/repository

Linux ve macOS’ta depo dizininin sahibi ile aktif kullanıcıyı karşılaştırın. Windows’ta dosya Özellikleri içindeki Güvenlik/Gelişmiş bölümünü veya PowerShell’de Get-Acl çıktısını inceleyebilirsiniz. CI runner, Docker volume, WSL ya da sudo ile oluşturulmuş dosyalar bu farkın sık görülen nedenleridir.

2. Kişisel depoda sahipliği düzeltin

Depo gerçekten size aitse ve yanlış kullanıcıyla oluşturulduysa en temiz çözüm dosya sahipliğini doğru hesaba vermektir:

sudo chown -R "$USER":"$(id -gn)" /path/to/repository

Komutu çalıştırmadan önce yolu iki kez kontrol edin. Sunucuda uygulama dosyalarının servis kullanıcısına ait olması gerekiyorsa bütün dizini geliştirici hesabına çevirmek doğru olmayabilir. Paylaşılan veya üretim klasörlerinde sahiplik modelini sistem yöneticisiyle belirleyin.

3. Güvenilir paylaşımlı depo için safe.directory kullanın

Sahipliğin farklı olması tasarım gereğiyse ve depoyu doğruladıysanız yalnızca o mutlak yolu güvenli listeye ekleyin:

git config --global --add safe.directory /path/to/repository
git config --global --get-all safe.directory

Windows yolu için Git’in tanıdığı mutlak yolu kullanın:

git config --global --add safe.directory "C:/Projects/my-app"

Bu ayar depo içindeki yerel config’e yazılmaz; korumalı kapsamda, örneğin global config içinde değerlendirilir. Böylece güvenilmeyen bir depo kendisini güvenli ilan edemez.

4. Kapsamı gereksiz yere genişletmeyin

git config --global --add safe.directory '*' tüm depoları güvenli kabul eder. Tek kullanıcılı geçici bir ortamda bile bunun neyi devre dışı bıraktığını bilmeden kullanmayın. Yanlış eklenen kaydı kaldırmak için:

git config --global --unset-all safe.directory /path/to/repository

Birden fazla kayıt varsa --get-all ile listeyi önce görün. Sistem seviyesinde eklenmiş ayarları da git config --show-origin --get-all safe.directory ile kaynağıyla birlikte inceleyin.

5. Docker ve CI ortamında kalıcı çözüm

Host klasörü konteynere volume olarak bağlandığında UID/GID değerleri eşleşmeyebilir. Image içinde her çalıştırmada joker güven eklemek yerine konteyneri uygun kullanıcı kimliğiyle çalıştırın, volume sahipliğini kontrollü biçimde eşleştirin veya yalnızca workspace yolunu safe.directory olarak tanımlayın.

CI sisteminde çalışma klasörü runner hesabına ait olmalıdır. Root aşamasında checkout yapıp sonraki adımı düşük yetkili kullanıcıyla çalıştırmak sahiplik farkı oluşturur. Checkout ve build adımlarında aynı kullanıcı modelini korumak, hatayı her pipeline’da bastırmaktan daha kalıcıdır.

Çözümün çalıştığını doğrulayın

git status
git config --show-origin --get-all safe.directory

git status artık çalışmalı ve güvenilir liste yalnızca gerekli yolu içermelidir. Depo size ait değilse çalıştırmadan önce .git/config, hook dosyaları ve build script’leri gibi yürütülebilir davranışları gözden geçirin.