İçeriğe geç

Menü

Berk Akademi
Yorumlar Google yorumları Özel Ders Başvuru Ücretsiz ön görüşme Ana Sayfa

Git “failed to push some refs” Hatası Nasıl Çözülür?

git-failed-to-push-some-refs-hatasi-nasil-cozulur
Bu yazıda neler var?
  1. Bu hata neden alınır?
  2. Uzak değişiklikleri alıp push işlemini nasıl tekrarlarsın?
  3. Pull sırasında çakışma çıkarsa ne yapmalısın?
  4. Dal adı ve zorla gönderme konusunda nelere dikkat etmelisin?
  5. Sık Sorulan Sorular

Git “failed to push some refs” hatası, uzak depodaki dalda yerel kopyanda bulunmayan commitler olduğunda ortaya çıkabilir. Çözüm çoğu durumda uzak değişiklikleri alıp yerel commitinle birleştirmek, ardından git push komutunu yeniden çalıştırmaktır.

Uzak depo, projenin GitHub gibi bir sunucuda bulunan kopyasıdır. push, yerel commitlerini uzak depoya gönderir; pull ise uzak depodaki değişiklikleri alıp mevcut dalınla birleştirir.

Bu hata neden alınır?

Bu hata neden alınır?

Git, uzak daldaki geçmişi yanlışlıkla ezmemek için yalnızca güvenli fast-forward güncellemelerine izin verir. Uzak dalda senin yerel kopyanda olmayan bir commit varsa yerel dalın uzak dalın devamı sayılmaz ve push işlemi reddedilebilir. Bu davranış, Git’in geçmiş kaybını önleyen güvenlik kurallarından biridir. Git push belgeleri bu durumu non-fast-forward güncelleme olarak açıklar.

error: failed to push some refs satırı genellikle genel hata özetidir ve tek başına kesin nedeni göstermez. Asıl ipucu, bu satırın yakınındaki rejected, fetch first veya non-fast-forward ifadeleriyle birlikte verilen açıklamada bulunur.

! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'origin'
hint: Updates were rejected because the remote contains work
hint: that you do not have locally.

[rejected], Git’in ilgili dalı göndermeyi denemeden reddettiğini anlatır. fetch first ifadesi uzak değişiklikleri önce alman gerektiğine işaret ederken, non-fast-forward ifadesi yerel ve uzak commit geçmişlerinin aynı noktadan ilerlemediğini belirtir. Bu nedenle hata mesajının tamamını okumadan doğrudan zorla gönderme komutuna geçmemelisin.

Uzak değişiklikleri alıp push işlemini nasıl tekrarlarsın?

Aşağıdaki örnekte yerel ve uzak main dalları aynı depoya bağlıdır ve ortak bir geçmişe sahiptir. GitHub üzerindeki README dosyası web arayüzünden düzenlenip ayrı bir commit olarak kaydedilmiş, yerelde de README dosyasında değişiklik yapılmış ve bu değişiklik commitlenmiştir. GitHub’ın dosya düzenleyicisinde değişiklikler Commit changes adımıyla kaydedilebilir.

  1. Yerel değişikliğin commitlendiğinden emin ol:

git add README.md
git commit -m "README dosyasını güncelle"
  1. Yerel commitini uzak main dalına göndermeyi dene:

git push origin main

Uzak depoda yeni bir README commit’i bulunduğu için buna benzer bir çıktı görebilirsin:

! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'origin'
  1. Uzak değişiklikleri alıp mevcut dalınla birleştir:

git pull --no-rebase origin main

git pull önce uzak dalı alır, --no-rebase seçeneği ise alınan değişiklikleri mevcut dalınla merge yöntemiyle birleştirir. Bu örnekte çakışma yoksa uzak README commit’i ile yerel commit aynı geçmişte birleştirilir. Git’in çıktı biçimi kullanılan sürüme ve depo ayarlarına göre değişebilir, ancak işlem başarıyla tamamlandığında birleştirme işlemini belirten satırlar görürsün.

$ git pull --no-rebase origin main
From github.com:ornek/kod-projesi
 * branch            main       -> FETCH_HEAD
Merge made by the 'ort' strategy.

$ git push origin main
To github.com:ornek/kod-projesi.git
   abc1234..def5678  main -> main
  1. Birleştirme tamamlandıktan sonra push işlemini yeniden çalıştır:

git push origin main

Bu kez yerel dalın, uzak dalın devamı hâline geldiği için push kabul edilir. Pull sırasında çakışma oluşursa işlem tamamlanmadan durur ve dosyalardaki çakışmayı çözmek gerekir.

Pull sırasında çakışma çıkarsa ne yapmalısın?

Pull sırasında çakışma çıkarsa ne yapmalısın?

Pull işlemi uzak depodaki değişiklikleri yerel dalınla birleştirirken, aynı dosyanın aynı bölümünde farklı düzenlemeler varsa otomatik birleştirme durabilir. Git bu durumda çakışan dosyaları işaretler ve birleştirme tamamlanmadan önce senin karar vermeni bekler.

Önce hangi dosyaların çakıştığını görmek için aşağıdaki komutu çalıştır:

git status

Çıktıda Unmerged paths bölümü veya both modified gibi ifadeler görüyorsan bu dosyalar henüz çözülmemiştir. Git’in kısa durum gösteriminde U işareti de birleştirilmemiş yolu ifade edebilir.

Çakışan dosyayı açtığında Git, ilgili bölümleri genellikle <<<<<<<, ======= ve >>>>>>> işaretleriyle ayırır. Yerel değişikliği, uzak depodan gelen değişikliği veya ikisinin düzenlenmiş bir birleşimini koruyacak şekilde dosyayı düzenle. Ardından bu işaretlerin tamamını dosyadan kaldır ve kodun tutarlı olduğundan emin ol.

Dosyayı çözdükten sonra Git’e bu dosyadaki çakışmanın giderildiğini bildirmek için git add kullanılır:

git add dosya-adi.py
git status
git merge --continue

Birleştirme devam komutu kullanılamazsa git commit ile birleştirme commitini tamamlayabilirsin. Çakışan dosyalar çözülüp hazırlama alanına eklenmeden birleştirme commitinin tamamlanması mümkün değildir. Bir dosyanın hangi bölümünün korunacağı konusunda emin değilsen değişikliği yapan ilgili kişiyle kontrol etmek, yanlış içeriği göndermekten daha güvenlidir.

Birleştirme tamamlandıktan sonra uzak depoya gönderme işlemini yeniden dene:

git push origin dal-adi

Dal adı ve zorla gönderme konusunda nelere dikkat etmelisin?

Push işleminin doğru hedefe yapıldığını anlamak için önce etkin dalı, görünen dalları ve uzak depo adresini kontrol et. Bu üç komut, özellikle main ve master adlarının karıştırıldığı durumlarda başlangıç için yeterli bir kontrol sağlar:

git branch --show-current
git branch -a
git remote -v

git branch --show-current etkin yerel dalın adını gösterir. git branch -a yerel dallarla birlikte uzak takip dallarını listeler. git remote -v ise uzak deponun gönderme ve alma adreslerini gösterir. Bu komutların çıktısında örneğin main, master veya başka bir dal adı bulunabilir.

main ve master aynı adın farklı yazımları değildir; farklı dallara işaret edebilirler. Ancak yalnızca dal adlarının farklı olması her zaman failed to push some refs hatasına yol açmaz. Önce gerçekten hangi dalda olduğunu ve uzak depoda hangi dalın hedeflendiğini kontrol et, ardından doğru adı açıkça kullan:

git push origin main

Etkin dalın adı master ise komutta main yerine master yazılır. Uzak dalı değiştirmeden veya yeni bir hedef oluşturmadan önce komutun hangi uzak depoya ve hangi dala gönderim yapacağını doğrulamak, yanlış yere push etme riskini azaltır.

git push --force komutu, uzak daldaki geçmişi yerel geçmişle değiştirebilir. Bu işlem uzak depodaki bazı commitlerin normal dal geçmişinden kopmasına ve başkalarının yaptığı değişikliklere erişimin zorlaşmasına neden olabilir. Bu yüzden force push, reddedilen push için rutin bir çözüm olarak kullanılmamalıdır. Yalnızca kişisel, tek kullanıcılı bir depoda geçmişi bilerek yeniden yazıyorsan ve etkilerini açıkça anlıyorsan gündeme gelebilir.

Sık Sorulan Sorular

Git pull yaptıktan sonra push hâlâ reddediliyorsa ne kontrol edilmelidir?

Git pull sonrasında push hâlâ reddediliyorsa etkin dalı, uzak depo adresini ve uzak dalın adını kontrol etmelisin. git status ile tamamlanmamış bir birleştirme olup olmadığına, git branch -a ile hedef dalın doğru seçilip seçilmediğine ve git remote -v ile doğru depoya gönderim yapıldığına bak. Uzak depoda pull sonrasında yeni bir commit oluştuysa değişiklikleri tekrar alıp birleştirmen gerekebilir.

Git pull sırasında çakışan değişiklikleri korumak mümkün mü?

Git pull sırasında çakışan değişiklikleri korumak mümkündür; dosyada yerel ve uzak değişikliklerin hangi bölümlerinin kalacağına elle karar verip birleşik içeriği kaydetmen gerekir. Dosyayı düzenledikten sonra git add ile işaretle, birleştirmeyi tamamla ve push işlemini yeniden dene.

Bu adımlarda amaç, uzak ve yerel geçmişi kontrol ederek doğru dalda tutarlı bir birleşim oluşturmaktır. Çakışma çözümünü tamamlamadan yapılan yeni bir push denemesi aynı reddedilme sorununu sürdürebilir.

Bu içerik aradığın cevabı verdi mi?
Yanıtın, hangi yazıları geliştirmemiz gerektiğini anlamamıza yardımcı olur.
Bu içeriğin üretilmesinde yapay zeka araçlarından destek alınmıştır.

Bu konudan sonra ne okuyabilirsin?

Tüm yazılar

İlgili Eğitimler

Berk Keskin, yazılım geliştirici ve eğitmen
Yazar

Berk Keskin Kimdir?

Yazılıma 12 yaşında başladı; İzmir Ekonomi Üniversitesi'ni bölüm birincisi ve yüksek şeref öğrencisi olarak tamamladı. Bugün yalnızca eğitim vermekle kalmıyor, sektörde aktif olarak yazılım projeleri geliştiriyor ve gerçek dünya deneyimini birebir derslerine taşıyor. Ezberden uzak, mühendislik zihniyetini merkeze alan sürdürülebilir öğrenme sistemleri tasarlayarak sorgulayan, üreten ve problem çözebilen yeni nesil yazılımcılar yetiştiriyor.

Sektörel Deneyim & Projeler

  • Ticarify Entegrasyon Yazılım logosu CEO Ticarify Entegrasyon YazılımPazaryerleri ve e-ticaret sitelerine otomatik e-fatura kesimi, sipariş ve kargo takibi hizmetleri sunan e-Dönüşüm platformunun API mimarisini ve yazılım ekibini yönetmektedir.
  • Benim Düğünüm logosu CEO Benim DüğünümDijital etkinlik ve anı paylaşım platformu.
  • Siberdizayn logosu Yazılım Ekibi Lideri SiberdizaynYüksek anlık oyuncu trafiğine sahip oyun kontrol panelleri ve sunucu altyapıları geliştiren yazılım ekibine liderlik etmektedir.
  • MEDYOGRAFYA 360° Dijital Çözümler logosu Dijital Strateji Lideri MEDYOGRAFYA 360° Dijital ÇözümlerŞirketlerin dijital çözümlerde uzun vadede nasıl ilerlemesi gerektiği ve dijital dönüşüm süreçlerinin yönetilmesine destek olmaktadır.
  • İzmir Ekonomi Üniversitesi logosu Danışma Kurulu Üyesi İzmir Ekonomi ÜniversitesiMezun olduğu üniversitesinde, Bilgisayar Programcılığı bölümünün akademik müfredatını güncel sektör ihtiyaçlarına göre şekillendirmek adına Danışma Kurulu'nda görev almaktadır.
WhatsApp Hemen Ara