Git “fatal: not a git repository” Hatası Nasıl Çözülür?

Git “fatal: not a git repository” hatası, komutu çalıştırdığın klasörde Git deposu bulunmadığında ortaya çıkar. Çözüm çoğu zaman terminalde doğru proje klasörüne cd ile geçmek, proje henüz Git deposu değilse dosyaların bulunduğu klasörde git init çalıştırmaktır. İlk adım olarak terminalin hangi klasörde olduğunu ve o klasörde proje dosyalarının bulunup bulunmadığını kontrol etmelisin.

Bu hata Git için ne anlama gelir?

Bu hata, Git’in mevcut çalışma dizininde ve üst dizinlerde bir .git klasörü bulamadığını anlatır. Çalışma dizini, terminalde komut yazdığın klasördür. Git deposu, proje dosyalarının Git tarafından izlenmesini ve geçmiş değişikliklerin tutulmasını sağlayan yapıdır. Bu yapının temel bilgileri genellikle projenin en üst klasöründeki .git dizininde bulunur.

Terminal ise bilgisayarındaki klasörlere geçip Git komutlarını çalıştırdığın metin tabanlı ortamdır. Git, komut çalıştırıldığında önce bulunduğun klasörü değerlendirir. Ardından üst klasörleri kontrol ederek bir Git deposunun parçası olup olmadığını anlamaya çalışır.

Örneğin proje klasörünün içinde src adında bir alt klasör varsa ve terminalde proje/src konumundaysan, Git üst klasörlerdeki depo bilgilerini bulabilir. Bu durumda git status gibi komutlar çoğunlukla çalışır. proje klasörünün bulunduğu dizinin yanındaki başka bir klasördeysen Git, o projenin deposunu kendiliğinden kullanmaz.

Bu nedenle bilgisayarında proje klasörünün bulunması tek başına yeterli değildir. Terminalin gerçekten o klasörde veya onun bir alt klasöründe açılmış olması gerekir. Yanlış klasörde git init çalıştırmak, asıl proje yerine üst klasörü ayrı bir depo hâline getirebilir. Bu yüzden önce konumu doğrula, ardından projenin Git deposu olup olmadığına karar ver.

Çalışma dizinini terminalde nasıl doğrularsın?

Doğru klasörü doğrulamak, bu hatayı teşhis etmenin en güvenli başlangıç adımıdır. Git Bash ve PowerShell farklı komut adları kullansa da amaç aynıdır: mevcut konumu görmek, klasör içeriğini incelemek ve proje klasörüne geçmek.

Git Bash kullanıyorsan şu kısa akışla başlayabilirsin:

pwd
ls -la
cd proje-klasoru
git status

PowerShell’de karşılığı şöyledir:

Get-Location
Get-ChildItem -Force
cd proje-klasoru
git status

ls veya Get-ChildItem çıktısında projenin dosyalarını görmüyorsan sorun Git’ten önce klasör seçimindedir. Dosyaları gördüğün hâlde git status çalışmıyorsa, bu klasör henüz Git deposu olmayabilir. Bu noktada doğrudan git init yazmadan önce klasörün gerçekten yeni projenin kök klasörü olduğundan emin ol.

Windows’ta Git Bash, PowerShell ve Visual Studio Code’un tümleşik terminali farklı başlangıç klasörleriyle açılabilir. VS Code, varsayılan olarak Explorer’da açılan çalışma alanının klasöründe terminal başlatır; ancak terminal.integrated.cwd ayarı başlangıç konumunu değiştirebilir. Bu nedenle editörde gördüğün klasör ile terminalin çalışma dizinini Get-Location veya pwd ile ayrıca kontrol et.

git clone sonrasında doğru klasöre nasıl girersin?

git clone komutundan sonra git status komutunu, klonlanan çalışma dizininin içinde çalıştırmalısın. Klonlama komutunu çalıştırdığın üst klasörde kalırsan Git, o konumda bir depo bulamayabilir ve hata verebilir.

Örneğin, önce depoyu klonlayıp ardından bulunduğun klasörü kontrol edebilirsin:

git clone <DEPO_ADRESİ>
git status
ls
cd <KLONLANAN_PROJE_KLASÖRÜ>
git status

PowerShell kullanıyorsan ls yerine Get-ChildItem yazabilirsin. İlk git status komutu üst klasörde çalıştırıldığı için hata verebilir. ls veya Get-ChildItem komutunun çıktısında oluşan proje klasörünü gördükten sonra, klasör adına göre cd ile içine geçmelisin.

Hedef klasörünü git clone komutunda ayrıca belirtmediysen Git, depo adından yararlanarak yeni bir klasör oluşturur. Bu nedenle klasör adını tahmin etmek yerine klonlama sonrası terminal çıktısını veya dizin listesini kontrol etmek daha güvenlidir. Doğru klasöre geçtiğinde git status, deponun dalı ve çalışma ağacındaki değişiklikler hakkında bilgi verir. Git clone belgeleri bu davranışın ayrıntılarını açıklar.

Yeni projede Git deposunu nasıl başlatırsın?

git init komutunu yalnızca Git ile izlenecek projenin kök klasöründe çalıştırmalısın. Bu komut, bulunduğun klasörü bir Git deposu olarak tanımlar ve depo bilgilerini burada oluşturur.

Aşağıdaki örnekte yeni bir proje klasörü oluşturuluyor, README dosyası hazırlanıyor ve ilk commit kaydediliyor:

mkdir yeni-proje
cd yeni-proje
git init
printf "# Yeni Projen" > README.md
git status
git add README.md
git status
git commit -m "İlk commit"
git status

mkdir proje klasörünü oluşturur, cd çalışma dizinini bu klasöre taşır ve git init depo yapısını başlatır. README dosyasının git add komutundan önce oluşturulması gerekir. İlk git status kontrolünde dosyanın henüz commit'e alınmadığını, git add README.md sonrasında ise ilk commit için hazırlandığını görebilirsin.

git commit -m komutu, hazırlanan dosyanın o anki durumunu proje geçmişine kaydeder. Commit tamamlandıktan sonra tekrar çalıştırılan git status, yeni bir değişiklik yapılmadıysa çalışma ağacının durumunu temiz olarak gösterir. PowerShell kullanıyorsan README dosyasını oluşturmak için Set-Content README.md "# Yeni Proje" komutunu kullanabilirsin.

İlk commit sırasında kullanıcı adı veya e-posta yapılandırması istenirse Git kimlik bilgilerini ayrıca yapılandırman gerekir. Bu ayar, dosyaların hazırlanmasından ayrı bir Git yapılandırma konusudur. git init komutunu ev dizininde veya proje dışı bir klasörde çalıştırmamaya dikkat et; Git, komutun çalıştırıldığı konumu depo kökü olarak kabul eder. Git init belgelerinde başlatma, dosya ekleme ve ilk commit akışı örneklenir.

.git klasörü görünmüyorsa ne yapmalısın?

.git klasörünün görünmemesi, yanlış klasörde bulunmandan, noktayla başlayan öğelerin normal listelemede gösterilmemesinden veya .git klasörünün silinmiş olmasından kaynaklanabilir.

Git Bash kullanıyorsan önce bulunduğun konumu ve gizli öğeleri birlikte kontrol et. ls komutunun -a seçeneği, noktayla başlayan dosya ve klasörleri de listeler.

pwd
ls -la

PowerShell'de konumu görmek için Get-Location, gizli ve sistem öğelerini listelemek için Get-ChildItem -Force kullanabilirsin. PowerShell, gizli öğeleri varsayılan listelemede göstermeyebilir; -Force seçeneği bu öğeleri görünür kılar.

Get-Location
Get-ChildItem -Force

Listede .git görünüyorsa klasöre elle müdahale etme. Bu dizin, deponun Git tarafından kullanılan yönetim bilgilerini içerir. Yeni bir depoda git init çalıştırıldığında bu yapının oluşturulması, Git'in çalışma mantığının bir parçasıdır.

.git görünmüyorsa önce yanlış klasörde olup olmadığını ve bu klasörde daha önce Git deposu başlatılıp başlatılmadığını ayır. Klonlanmış bir projede, üst klasörde değil klonlama sırasında oluşturulan proje klasöründe olabilirsin. Yeni bir projede ise henüz git init çalıştırılmamış olabilir.

.git klasörünün silindiğini düşünüyorsan yerel Git geçmişinin kendiliğinden geri geleceğini varsayma. Mevcut proje dosyalarını koru, uzak depoya erişimin veya bir yedeğin olup olmadığını kontrol et ve durumu ayrı bir kopya üzerinde değerlendir. .git klasörünü elle kopyalamak ya da silmek, ayrıca dosya kaybına yol açabilecek komutları denemek yerine önce depo yapısını anlamaya çalış.

Hangi hatalar çözümü zorlaştırır?

Çözümü zorlaştıran temel hatalar, yanlış klasörde git init çalıştırmak, terminali proje dışından açmak ve .git klasörüne elle müdahale etmektir. Özellikle mevcut bir depoda rastgele yeniden git init çalıştırmak, kayıp geçmişi geri getirmez; yalnızca bulunduğun konumda yeni bir Git yapısı oluşturabilir.

Kontrolü şu sırayla yapmak, aynı komutu farklı klasörlerde tekrar tekrar denemekten daha sağlıklıdır:

1. Git Bash'te pwd, PowerShell'de Get-Location ile çalışma dizinini göster.
2. Proje dosyalarını ls veya Get-ChildItem ile listele.
3. Gizli öğeleri Git Bash'te ls -la, PowerShell'de Get-ChildItem -Force ile kontrol et.
4. .git varsa mevcut depoda olduğunu değerlendir. Yeni bir proje değilse yeniden git init çalıştırma.
5. Proje klonlandıysa, klonlanan alt klasöre geç.
6. Sonucu git status ile doğrula.

Bu son kontrolde git status, çalışma ağacındaki değişiklikleri ve izlenmeyen dosyaları gösterir. Komutu proje kökünde çalıştırmak, klasör yapısını anlamayı kolaylaştırır.

Karar verirken durumu dört başlıkta düşün: mevcut depo, yeni proje, klonlanmış depo veya silinmiş.git durumu. Hangi gruba girdiğini belirlemeden komut çalıştırmak yerine klasör yolunu ve depo yapısını yeniden incele.

Sık Sorulan Sorular

git status komutunu hangi klasörde çalıştırmalıyım?

git status komutunu projenin Git deposu olan klasörde veya onun alt klasörlerinde çalıştırmalısın. Teşhis sırasında proje köküne geçmek, .git klasörünü ve temel dosyaları aynı yerde görmeni sağlar.

git init ile git clone arasındaki fark nedir?

git init mevcut bir klasörde yeni ve başlangıçta boş bir Git deposu oluşturur; git clone ise var olan bir depoyu yeni bir klasöre kopyalar ve uzak depo bilgilerini kurar. Bu nedenle yeni proje ile daha önce oluşturulmuş bir projeyi bilgisayara alma işlemi aynı komutla yapılmaz.

.git klasörü silindiyse proje dosyaları da silinir mi?

.git klasörünün silinmesi, proje dosyalarının da otomatik olarak silineceği anlamına gelmez; ancak yerel Git geçmişi ve depo yapılandırması etkilenebilir. Dosyaları koruyarak uzak depo veya yedeklerle karşılaştırma yapmak gerekir.

Git Bash, PowerShell ve VS Code terminalinde klasör konumu neden farklı görünebilir?

Git Bash, PowerShell ve VS Code terminali kendi oturumlarını farklı çalışma dizinlerinde başlatabilir. Her terminalde pwd veya Get-Location çalıştırarak komutları uygulamadan önce gerçek konumu karşılaştırmalısın.

Önce klasörü doğrulayıp sonra .git durumunu kontrol ettiğinde, hatayı rastgele komutlarla değil doğru depo yapısı üzerinden çözebilirsin.