Git Push Rejected Hatası Nasıl Çözülür?

git push komutunu çalıştırırken rejected hatası alıyorsanız Git uzak repository'ye göndermek istediğiniz değişiklikleri kabul etmemiştir. En yaygın neden, GitHub'daki branch'in yerel bilgisayarınızdaki branch'ten daha yeni commit'lere sahip olmasıdır.

Bu durumda doğrudan --force kullanmak yerine önce yerel ve uzak repository arasındaki farkı kontrol etmek gerekir.

1. Hata mesajını dikkatlice okuyun

Yaygın bir hata örneği şöyledir:

! [rejected] main -> main (non-fast-forward)

veya:

Updates were rejected because the remote contains work that you do not have locally.

Bu mesaj genellikle uzak repository'de sizin yerel projenizde bulunmayan commit'ler olduğunu gösterir.

2. Doğru branch üzerinde olduğunuzu kontrol edin

Aktif branch'i görmek için:

git branch

kullanabilirsiniz.

Daha ayrıntılı durum için:

git status

komutunu çalıştırın.

Örneğin yerelde master, GitHub'da ise main kullanılıyorsa yanlış branch'e push etmeye çalışıyor olabilirsiniz.

3. Remote repository adresini kontrol edin

Şu komutu çalıştırın:

git remote -v

Gösterilen adresin gerçekten değişiklik göndermek istediğiniz repository olduğundan emin olun.

Yanlış repository'ye push yapmak da beklenmeyen hatalara neden olabilir.

4. Uzak değişiklikleri kontrol edin

Remote üzerindeki güncel bilgileri almak için:

git fetch origin

kullanabilirsiniz.

git fetch, uzak repository'deki değişiklikleri indirir ancak bunları doğrudan mevcut branch'inizle birleştirmez.

Bu nedenle önce uzaktaki durumu görmek istediğinizde kullanışlıdır.

5. Uzak değişiklikleri yerel projeye alın

Uzak branch'teki değişiklikleri de korumak istiyorsanız uygun durumda:

git pull origin main

kullanılabilir.

Bu işlem uzak değişiklikleri alarak mevcut branch ile birleştirmeye çalışır.

Projenizin çalışma şekline göre rebase tabanlı bir akış da kullanılabilir:

git pull --rebase origin main

Rebase kullanımı commit geçmişini farklı şekilde düzenlediği için özellikle ortak projelerde ekibin kullandığı Git çalışma modeline uygun hareket edin.

6. Merge conflict oluşursa ne yapılmalı?

Hem siz hem başka biri aynı dosyanın aynı bölümlerini değiştirdiyse Git otomatik birleştirme yapamayabilir.

Bu durumda merge conflict oluşur.

Öncelikle:

git status

ile çakışan dosyaları bulun.

Dosyalardaki conflict bölümlerini inceleyerek hangi kodun kalacağına karar verin.

Çakışmaları çözdükten sonra kullanılan merge veya rebase işlemine uygun şekilde süreci tamamlayın.

Conflict işaretlerini anlamadan dosyaları doğrudan commit etmek kodun bozulmasına neden olabilir.

7. Değişiklikleri aldıktan sonra tekrar push yapın

Uzak değişiklikleri başarıyla yerel projenizle birleştirdikten ve varsa conflict'leri çözdükten sonra:

git push origin main

komutunu tekrar deneyebilirsiniz.

8. GitHub'da README oluşturduktan sonra hata oluşabilir

Yeni GitHub repository oluştururken README, lisans veya .gitignore dosyası eklediyseniz GitHub tarafında başlangıç commit'i oluşmuş olabilir.

Aynı zamanda bilgisayarınızdaki projeyi ayrı bir Git geçmişiyle oluşturduysanız iki tarafın geçmişi birbirinden bağımsız olabilir.

Bu durumda doğrudan push reddedilebilir.

Önce her iki tarafta korunması gereken dosyaları ve commit geçmişlerini kontrol edin. Mevcut verileri anlamadan zorla push yapmak doğru çözüm değildir.

9. Force push kullanmalı mıyım?

İnternette şu komutla sık karşılaşabilirsiniz:

git push --force

Bu komut uzak branch geçmişinin üzerine yazılmasına neden olabilir.

Sonuç olarak GitHub'da bulunan ve sizin yerel branch'inizde olmayan commit'ler kaybolabilir.

Bu nedenle özellikle:

- Ekip projelerinde

- Production projelerinde

- Başkasının commit'leri bulunan repository'lerde

- Önemli kodların bulunduğu branch'lerde

ne yaptığınızı tam olarak bilmiyorsanız force push kullanmayın.

10. Force push gerçekten gerekiyorsa daha güvenli seçenekleri araştırın

Commit geçmişini bilinçli olarak yeniden yazdığınız özel durumlarda force push gerekebilir.

Böyle durumlarda --force-with-lease, düz --force kullanımına göre uzaktaki beklenmeyen değişikliklerin üzerine yazılmasını önlemeye yardımcı olabilir.

Ancak bu seçenek de yanlış kullanıldığında problem oluşturabilir. Commit geçmişini neden yeniden yazdığınızı bilmiyorsanız kullanmayın.

11. Protected branch nedeniyle push reddedilebilir

GitHub repository'sinde main gibi önemli branch'ler koruma kuralları altında olabilir.

Bu durumda doğrudan push yapılmasına izin verilmeyebilir.

Projenin çalışma düzenine göre:

1. Yeni branch oluşturulur.

2. Değişiklikler bu branch'e gönderilir.

3. Pull request açılır.

4. İnceleme ve gerekli kontrollerden sonra ana branch'e birleştirilir.

Bu durum non-fast-forward hatasından farklıdır. Hata mesajında repository veya branch kurallarından bahsediliyorsa GitHub tarafındaki kuralları kontrol edin.

12. Permission hatası ile rejected hatasını karıştırmayın

Hata:

Permission denied

şeklindeyse kimlik doğrulama veya repository yetkisiyle ilgili olabilir.

Hata:

rejected ... non-fast-forward

şeklindeyse genellikle Git geçmişlerinin durumu araştırılmalıdır.

Hata mesajının tamamını okumak bu nedenle önemlidir.

13. Önce durumunuzu kontrol etmek için kullanabileceğiniz komutlar

Push hatası aldığınızda rastgele komut çalıştırmak yerine şu bilgilerle başlayabilirsiniz:

git status

git branch

git remote -v

git fetch origin

Bunlar mevcut repository yapısını anlamanıza yardımcı olur.

Commit geçmişini incelemek de yerel ve uzak branch'lerin nerede ayrıldığını anlamayı kolaylaştırabilir.

En güvenli yaklaşım nedir?

Uzak repository'de korunması gereken değişiklikler varsa temel mantık şöyledir:

1. Yerel değişikliklerinizi güvenceye alın.

2. Doğru branch ve repository'de olduğunuzu kontrol edin.

3. Uzak değişiklikleri alın.

4. Yerel ve uzak değişiklikleri uygun yöntemle birleştirin.

5. Conflict varsa çözün.

6. Projenin çalıştığını kontrol edin.

7. Ardından tekrar push yapın.

git push rejected hatasının çözümü her durumda aynı değildir. Özellikle --force, reset --hard veya geçmişi değiştiren diğer Git komutlarını hata mesajını anlamadan kullanmak veri kaybına neden olabilir.

Forumda yardım isterken git status, git branch, git remote -v çıktısını hassas bilgileri gizleyerek ve git push sonrasında aldığınız hata mesajının tamamını paylaşmanız sorunun daha hızlı çözülmesini sağlar.