Git push rejected hatası nasıl çözülür? Adım adım rehber

Kısa yanıt

Git push rejected hatası, uzak depodaki dal sizin yerel kopyanızda olmayan commit’ler içerdiğinde ortaya çıkar; Git, geçmişi kaybetmemek için push işlemini durdurup “failed to push some refs” mesajını gösterir. Çözüm genellikle basittir: önce git pull ile uzak değişiklikleri alıp birleştirmek, sonra tekrar push etmektir.

Bu yazıda git push rejected hatasının altında yatan nedeni, hata mesajını doğru okuma yöntemini ve pull, rebase ile force-with-lease seçeneklerinden hangisinin ne zaman kullanılacağını adım adım anlatıyoruz.

Git push rejected hatası neden oluşur

Git, her dalın (branch) doğrusal bir commit geçmişi olmasını beklediği için, push işlemi sırasında yerel dalınızın uzak dalın tam olarak neyin üzerine inşa edildiğini kontrol eder. Uzak dalda sizde olmayan yeni commit’ler varsa — örneğin bir takım arkadaşınız sizden önce push yaptıysa veya GitHub üzerinden doğrudan bir dosya değiştirdiyseniz — Git bu push’u “non-fast-forward” olarak sınıflandırır ve reddeder. Amaç, sizin push’unuzun o commit’leri sessizce silmesini engellemektir.

Pratikte git push rejected hatası neredeyse her zaman şu üç durumdan birinde karşınıza çıkar:

• Aynı dalda birden fazla kişi çalışıyor ve biri sizden önce push yaptı
• Uzak depoda, yerel geçmişinizde olmayan bir commit GitHub arayüzünden (ör. bir pull request birleştirmesi veya doğrudan dosya düzenlemesi) eklendi
• Yerel geçmişinizi git rebase, git commit --amend veya git reset ile değiştirdiniz ve artık uzak dalla aynı çizgide değil

Tam hata mesajını okuyun

Terminalde gördüğünüz mesaj genellikle şuna benzer:

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

Bu mesajın en önemli kısmı “fetch first” ipucudur; Git size doğrudan ne yapmanız gerektiğini söylüyor: önce uzak depodaki değişiklikleri indirin, sonra push edin. “Updates were rejected because the tip of your current branch is behind” şeklinde bir varyasyon görüyorsanız da anlam aynıdır — sizin dalınız uzak daldan geride kalmıştır.

Sık görülen git push rejected mesajları

Mesaj	Tipik neden	İlk çözüm
! [rejected] main -> main (fetch first)	Uzak dalda sizde olmayan yeni commit’ler var	git pull (veya git pull --rebase)
Updates were rejected because the tip of your current branch is behind	Yerel dal, uzak daldan geride kalmış	git fetch ile durumu kontrol edip git pull çalıştırın
Updates were rejected because the remote contains work that you do not have locally	Başka biri sizden önce push yaptı	git pull --rebase ile geçmişi düzenli tutun
! [rejected] main -> main (non-fast-forward)	Yerel geçmiş rebase/amend ile değişti, uzak dalla ayrıştı	Durumu değerlendirip --force-with-lease kullanın
error: failed to push some refs to '...' (dal adı uyuşmazlığı)	Yanlış uzak dala push deneniyor	git branch -vv ile takip ilişkisini kontrol edin

Git push rejected hatası nasıl çözülür? Adım adım

Git push rejected hatasını çözmenin sırası, hangi senaryoda olduğunuza bağlı olsa da, aşağıdaki adımlar büyük çoğunlukla işe yarar.

1. Önce git pull ile uzak değişiklikleri alın

En güvenli ve en sık işe yarayan çözüm, doğrudan tekrar push denemek yerine önce git pull çalıştırmaktır. Bu komut, uzak dalı yerel kopyanıza indirir ve varsayılan olarak yerel değişikliklerinizle otomatik bir merge commit’i oluşturur. Çakışma çıkmazsa, bu commit’i tekrar push etmeniz yeterlidir. Çakışma çıkarsa klasik bir merge conflict ile karşılaşırsınız; bu durumu git merge conflict nasıl çözülür rehberimizde ayrıntılı olarak anlatıyoruz.

2. Geçmişi temiz tutmak istiyorsanız git pull --rebase kullanın

Merge commit’lerinin geçmişi dallandırmasını istemiyorsanız, git pull --rebase komutu uzak değişiklikleri indirir ve sizin commit’lerinizi bunların üzerine, sanki en baştan onlardan sonra yazılmış gibi yeniden uygular. Sonuç, tek bir doğrusal geçmiştir; ancak rebase sırasında da çakışma çıkabilir ve her commit için ayrı ayrı çözülmesi gerekebilir. Ekip içinde ortak bir kural olarak “merge mi, rebase mi” sorusunu baştan netleştirmek, git push rejected hatasıyla ne sıklıkla karşılaşacağınızı da etkiler.

3. Force push’u yalnızca gerçekten gerekliyse kullanın

git push --force, uzak dalı zorla sizin yerel geçmişinizle değiştirir; bu, uzak depodaki, sizde olmayan commit’lerin kalıcı olarak kaybolması anlamına gelir. Bu komutu yalnızca o dalda tek başınıza çalıştığınızdan eminseniz veya bilinçli olarak geçmişi (ör. bir rebase sonrası) yeniden yazdıysanız kullanın. Paylaşılan bir dalda (özellikle main veya master) force push, takım arkadaşlarınızın çalışmasını sessizce silebilir.

Daha güvenli bir orta yol, git push --force-with-lease kullanmaktır. Bu komut, yalnızca siz son kez fetch ettiğinizden beri uzak dalda başka kimse push yapmadıysa zorla push’a izin verir; aksi halde işlemi durdurup sizi uyarır. Force push gerektiren neredeyse her durumda --force-with-lease, düz --force’tan daha güvenli bir seçimdir.

Yanlış dala push etmek de rejected hatasına yol açabilir

Bazı durumlarda git push rejected hatasının nedeni geçmiş çakışması değil, basitçe yanlış bir uzak dal adına push etmeye çalışmaktır — örneğin yerel main dalınızı, artık master olarak yeniden adlandırılmış bir uzak dala göndermeye çalışmak. git branch -vv komutuyla yerel dalınızın hangi uzak dalı takip ettiğini kontrol edin; eşleşme yoksa git push -u origin <dogru-dal-adi> ile takip ilişkisini yeniden kurun.

CI/CD boru hatlarında görülen push rejected hataları

Git push rejected hatası yalnızca geliştiricinin kendi makinesinde değil, otomatik dağıtım (CI/CD) boru hatlarında da sık görülür. Bir GitHub Actions iş akışı, örneğin bir sürüm etiketi veya değişiklik günlüğü dosyasını otomatik commit’leyip geri push etmeye çalıştığında, aynı anda başka bir iş akışı veya geliştirici deposu güncellemişse push reddedilir. Bu senaryoda çözüm genellikle iş akışının push’tan hemen önce bir git pull --rebase adımı çalıştırması veya push’ların sıraya alınmasıdır; aksi halde paralel çalışan iş akışları birbirini bloke edebilir.

Ekip halinde çalışırken bu hatayı azaltmanın yolları

Git push rejected hatasının kendisi tehlikeli değildir — asıl risk, bu uyarıyı görmezden gelip düşünmeden --force kullanmaktır. Ekip içinde şu üç alışkanlık, hatanın sıklığını ve yol açtığı riski büyük ölçüde azaltır:

• Push etmeden önce git fetch ile uzak dalın durumunu kontrol etmek
• Uzun süre açık kalan dallarda düzenli olarak git pull --rebase çalıştırmak
• Paylaşılan dallarda force push’u tamamen yasaklayıp yalnızca kişisel özellik dallarında izin vermek

Sık yapılan hatalar

• Mesajı okumadan doğrudan --force denemek. Bu, sorunu “çözer” ama uzak depodaki gerçek çalışmayı sessizce siler; ilk adım her zaman mesajı okumak ve nedeni anlamak olmalıdır.
• pull ile pull --rebase arasındaki farkı bilmeden birini seçmek. İkisi de push rejected hatasını çözer ama sonuçtaki geçmiş farklıdır; ekip kuralına uymayan seçim sonraki push’larda kafa karışıklığı yaratabilir.
• Force push’u paylaşılan bir dalda denemek. main gibi dallarda force push, başka birinin commit’lerini geri dönüşü zor biçimde kaybettirebilir.
• Takip ilişkisini (upstream) hiç kontrol etmemek. Yanlış dala push denemesi, gerçek bir geçmiş çakışması olmadan da rejected hatası verebilir.

Kontrol listesi

• Hata mesajını tam olarak okudunuz mu, “fetch first” mü yoksa “non-fast-forward” mesajı mı?
• git fetch ile uzak dalın güncel durumunu kontrol ettiniz mi?
• Ekibinizin merge mi rebase mi tercih ettiğine karar verdiniz mi?
• Force push gerekiyorsa --force-with-lease kullanmayı değerlendirdiniz mi?
• Yerel dalınızın doğru uzak dalı takip ettiğini git branch -vv ile doğruladınız mı?

Sonraki adım

Git push rejected hatası, çoğu zaman birkaç dakika içinde ve veri kaybı yaşamadan çözülebilecek, sürüm kontrolünün doğal bir parçasıdır; asıl dikkat edilmesi gereken nokta, hatayı görmezden gelip düşünmeden force push’a başvurmamaktır. Ekibinizin git iş akışını daha sağlam bir temele oturtmak veya özel bir yazılım projesinde sürüm kontrolü ve dağıtım süreçlerini baştan kurmak isterseniz, grup şirketimiz Web Tasarım Ofisi web ve yazılım projelerinde teknik altyapı kurulumu konusunda destek veriyor.

Sürüm kontrolü ve dağıtım süreçlerinizi kapsayan özel bir yazılım projesini birlikte değerlendirmek için özel yazılım hizmetimizi inceleyebilir ya da bizimle iletişime geçebilirsiniz. Git tabanlı ekip çalışmasında sık karşılaşılan diğer bir sorunu git merge conflict nasıl çözülür rehberimizde ele alıyoruz.

Kaynaklar

• GitHub Docs — Dealing with non-fast-forward errors — non-fast-forward push hatalarının resmî açıklaması ve önerilen çözümler