Git Push Force: Nasıl Çalışır ve Güvenle Nasıl Kullanılır

Geliştirici olarak muhtemelen bunu yaşadınız: Son commit’inizde kodunuzda bir sorun olduğunu fark ettiniz. Bu hatayı geri almak için bazı komutlar çalıştırıp yerel geçmişinizi yeniden yazdınız. Her şeyi temizlemek için git push --force çalıştırdığınızda, ekip arkadaşlarınız bazı commit’lerin eksik olduğunu veya boru hattınızda (pipeline) derlemelerin bozulduğunu bildiriyor.

Bu yazıda, git push --force komutunun gerçekte ne yaptığını, ne zaman kullanmanız gerektiğini ve hatalardan nasıl kaçınacağınızı anlatacağım. Git’e yeni başlıyorsanız, sürüm kontrolünü öğrenmek için bizim Introduction to Git kursumuzu almanızı öneririm. Ayrıca, indirip başvurabileceğiniz Git Cheat Sheet en yaygın Git terimlerini ve komutlarını içerdiği için yararlı bir başvuru kaynağıdır.

git push --force'a İhtiyacınız Olduğunu Düşünebileceğiniz Durumlar

Diyelim ki çalışmanızı itmeden önce yerel commit geçmişinizi temizliyorsunuz. Birleştirmeden önce commit geçmişinizi toparlamak için git rebase -i main çalıştırıyorsunuz. Yerelde her şey kusursuz görünüyor, bu yüzden uzak dalınızı basit bir git push ile güncellemeyi deniyorsunuz. Ancak olağan başarı mesajı yerine Git bir hata gösteriyor.

Başka bir durumda, yanlışlıkla hassas verileri commit edip uzağa itmiş olabilirsiniz; örneğin bir API anahtarı veya parola. İhlal eden commit’i kaldırmak için yerelde geçmişi yeniden yazdıktan sonra, normal bir push’un uzak depoyu güncellemediğini ve hassas verinin kaldığını görürsünüz. Bunun yerine bir hata mesajı alırsınız.

! [rejected]        main -> main (non-fast-forward)
error: failed to push some refs to 'origin'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.,
hint: 'git pull ...') before pushing again.Altyapı:

Bu “non-fast-forward” hatası Git’in güvenlik ağıdır; geçmişinizde sunucudakine uymayan bir şeyler olduğu konusunda uyarıdır. Bu noktada, bu hatayı atlamak için git push --force çalıştırmak cazip gelebilir.

Dalda tek başına çalışıyorsanız bu sorun çıkarmayabilir. Ancak paylaşılan projelerde kolayca kafa karışıklığına neden olabilir veya bir başkasının çalışmasını silebilir.

git push --force Gerçekte Ne Yapar

Genelde Git, yerel dalınız uzak depodaki her şeyi (yeni commit’leriniz dahil) içeriyorsa değişikliklerinizi itmenize izin verir. Ancak bazen commit geçmişinizi git rebase, squash yaparak veya hassas verileri kaldırarak yeniden yazabilirsiniz. Bunu yaptığınızda yerel dalınız uzak daldan farklı olacaktır. Ardından yeni bir commit itmeye çalıştığınızda, Git uzak dalı iş kaybına karşı koruyan bu hatayı gösterir.

git push --force kullanmak, Git’e güvenlik kontrolünü atlamasını ve uzak dalı yerel dalınızdaki içerikle üzerine yazmasını söyler. 

Bu şöyle görünür:

git push --force origin mainAltyapı:

Bu, uzak depodaki main dalını yerel main’inizle eşleyecek ve yerel dalınızda olmayan commit’leri silecektir. 

Şimdi Git dalınızı, ekibinizle birlikte yazdığınız ortak bir kitaptaki bir bölüm gibi düşünün. Standart bir push, bölümün sonuna yeni paragraflar eklemek gibidir. Ancak git push --force daha güçlüdür; mevcut bölümü söküp tamamen sizin sürümünüzle değiştirir. 

git push --force kullanmanın riski, iş birliği yapanların, sizin az önce sildiğiniz commit’ler üzerine değişiklik yapmışlarsa çalışmalarını kaybetmeleridir. Sonraki bölümde, --force komutuyla çalışırken alınacak önlemlere bakacağız.

Bu Neden Ekibiniz İçin Her Şeyi Bozabilir

Değişikliklerinizi main veya develop gibi paylaşılan bir dala zorla iterseniz, büyük olasılıkla şunları yaşarsınız:

• Diğerlerinin yerel dalları eşzamanlılığını kaybeder: Ekip arkadaşlarınız, uzaktan sildiğiniz eski commit’leri çektiyse, yerel geçmişleri artık sunucuyla eşleşmez. Dalları “kaybolmuş” commit’lere referans verir, bu da kafa karışıklığına yol açar ve 
• Çekme işlemi kafa karıştırıcı birleştirmelere veya hatalara yol açar: Siz zorla itme yaptıktan sonra biri git pull denediğinde, Git yeniden yazılmış geçmişi yereldeki commit sıralarıyla nasıl uzlaştıracağını bilemez. Bu genellikle tuhaf birleştirme commit’lerine, anlaşılması güç hatalara veya ekip arkadaşlarının git fetch, git reset ile elle müdahale etmeye ya da dalı yeniden klonlamaya yönlendirildiği durumlara yol açar.
• CI/CD boru hatları başarısız olabilir: Boru hatları sıklıkla tutarlı commit hash’lerine ve doğrusal geçmişe güvenir. Zorla itme, testlerin başarısız olmasına, yanlış kodun yeniden dağıtılmasına veya güncel olmayan commit’ler üzerinde yeniden derleme yaparken çökmesine neden olabilir.

CI/CD iş akışlarının nasıl kurulacağını anlamak için CI/CD for Machine Learning kursumuza göz atın. Ayrıca, veri sürümleme ile kod sürümleme arasındaki farkı öğrenmek için Introduction to Data Versioning with DVC kursumuzu almanızı öneririm.

Bunu şöyle somutlaştıralım: Bir ekip arkadaşınızla birlikte feature dalındasınız. Yerel geçmişinizi temizler ve ardından git push --force çalıştırırsınız. Dakikalar sonra, ekip arkadaşınız değişikliklerini iter. Git’te hatalar görür. Çektiğinde birleştirme çatışmaları ve darmadağın bir commit geçmişiyle karşılaşır. Bu arada, eksik commit’ler nedeniyle CI boru hattınız başarısız olur. Artık ekip arkadaşınız dalı çözmek için zaman kaybeder ve dağıtım gecikir.

Tek bir zorla itme bunların hepsini tetikler.

Daha Güvenli Seçenek: git push --force-with-lease

Bu tür sorunlardan kaçınmak için git push --force-with-lease kullanmanızı öneririm. Bu komut, beklenmedik commit’leri önlemek için uzağa itme sırasında bir güvenlik kontrolü ekler.

git push --force-with-lease origin mainAltyapı:

--force-with-lease’i “atlamadan önce etrafın güvenli olup olmadığını sormak” gibi düşünün. Bir şey yapmadan önce, başka hiç kimsenin dalı değiştirmediğinden emin olur. Her şey son gördüğünüz gibiyse geçmişiniz güncellenir. Ancak haberiniz olmayan yeni değişiklikler varsa, Git sizi durdurur ve önce durumu gözden geçirmenizi ister. Böylece bu komut, iş arkadaşlarını istenmeyen üzerine yazmalardan her zaman korur.

Kötü Bir Zorla İtmeden Nasıl Kurtulunur

Bazı commit’leri kaybederseniz endişelenmeyin; yine de kurtarabilirsiniz. Git, geçerli commitle ilgili değişikliklerin, yeniden yazmalar dahil, kaydını her zaman tutar ve bunu reflog’da saklar.

Kaybolan commit’leri böyle kurtarabilirsiniz:

Adım 1: Kaybolan commit’leri bulmak için git reflog kullanın

Dal geçmişinizi görüntülemek için git reflog çalıştırın.

git reflogAltyapı:

Commit’leriniz şöyle görünebilir:

abc1234 HEAD@{1}: push: force push
def5678 HEAD@{2}: commit: add new featureAltyapı:

Adım 2: Kaybolan commit’i geri yükleyin

Geri almak istediğiniz commit hash’ini belirlediğinizde, belirli dal durumuna geçmek için aşağıdaki komutu kullanın.

git checkout def5678Altyapı:

Adım 3: Yeni bir dal oluşturun

Dosyaları güvenle kurtarmak için yeni bir git dalı oluşturun.

git checkout -b recovery-branchAltyapı:

Adım 4: Uzak dalı geri yükleyin

Şimdi kurtarılan commit’leri dala itin:

git push origin recovery-branchAltyapı:

Reflog verilerinin yalnızca yerel makinelerde bulunduğunu unutmayın. Bu nedenle, ekip arkadaşlarınızdan hiçbiri bunları yerel ortamında saklamadıysa kaybolan commit’leri kurtaramayabilirsiniz.

Git’te iş birliği ve dallarla çalışmayla ilgili daha fazlasını öğrenmek için Intermediate Git kursumuzu almanızı öneririm.

git push --force'u Güvenle Kullanmak İçin En İyi Uygulamalar

Sorun çıkarma olasılığını azaltmak için şu iyi alışkanlıkları izleyin:

• --force yerine --force-with-lease’i tercih edin:  Bu yöntem, son fetch’inizden beri uzak dalın değişmediğini kontrol eden daha güvenli bir seçenektir. Ekip arkadaşlarınızı kazara üzerine yazmalardan korumaya yardımcı olur.

• Paylaşılan dallara zorla itmekten kaçının: main, master, develop veya release gibi paylaşılan dallara asla zorla itmeyin. Aksaklıkları önlemek için yalnızca tek katkıcısı olduğunuz özellik (feature) dallarınıza zorla itin.

• Zorla itmeden önce ekibinizi bilgilendirin: Paylaşılan bir dala mutlaka zorla itmeniz gerekiyorsa, ekibinize haber verin. Böylece çalışmalarını kaydetmelerini ve kayıpları önlemelerini sağlar.

• Korumalı dallar kullanın: GitHub, GitLab ve Bitbucket gibi platformlarda dallarınız için koruma da etkinleştirebilirsiniz. Bu, doğrudan düzenlemeleri kısıtlar ve önemli dallara kazara zorla itmeleri önler.

Özel depoları yönetme hakkında daha fazla bilgi edinmek isterseniz, GitHub üzerinde iş birliği yaparken çekme isteklerinin nasıl inceleneceğini anlamak için Introduction to GitHub Concepts kursumuza göz atın.

Sonuç

git push --force, commit’leri temizlemek veya hassas verileri kaldırmak gibi durumlarda deponuzun geçmişini yeniden yazmak için yararlı bir yöntem sunar. Bu komutu kullanırken ekibinizin iş akışını bozmamak için daima dikkatli olun.

Mümkün olan her durumda --force-with-lease kullanın. Başkalarının çalışmalarını riske atmadan size daha fazla kontrol sağlar. Biraz özen ve iletişimle, ekibiniz için sorun çıkarmadan Git geçmişinizi temiz tutabilirsiniz.

Git’in her yönünde uzmanlaşmak için Git Fundamentals ve GitHub Foundations beceri yollarımıza göz atmanızı öneririm.