Push yapmak — nedir, git push nasıl çalışır ve ne zaman gerekir

Git'te Push Nedir

Git push, commit'leri yerel depodan uzak depoya aktaran bir komuttur. Değişiklikleri yalnızca geliştiricinin yerel makinesinde kaydeden commit'in aksine, push bu değişiklikleri tüm ekip için yayınlar. Push, Pull Request oluşturma ve dağıtımdan önce zorunlu bir adımdır.

Git'in mimarisi, her geliştiricinin kendi yerel deposunda çalıştığını varsayar. Commit'ler yerel olarak oluşturulur ve geliştirici push yapmaya karar verene kadar birikir. Bu özgürlük sağlar: birçok yerel commit yapabilir, deneyebilir ve iş arkadaşlarını etkilemeden geçmişi yeniden yazabilirsiniz.

# Origin remote'e, main dalına push
git push origin main

# Geçerli dalı upstream ile remote'a push
git push -u origin feature/new-dashboard

# Eşleşen adlara sahip tüm dalları push
git push --all origin

# Kiralı force push (güvenli force push)
git push --force-with-lease

Push'tan sonra, uzak depo ref'leri (dal referansları) yeni commit'leri gösterecek şekilde günceller. Diğer geliştiriciler bu değişiklikleri git pull veya git fetch aracılığıyla alabilir. Bu commit alışverişi, işbirlikçi geliştirmenin temelini oluşturur.

Git push Nasıl Çalışır

Git push komutu, yerel ve uzak dalları karşılaştırır ve yalnızca eksik commit'leri aktarır. Git tüm dosyaları yeniden göndermez — yalnızca delta'yı aktarır, bu da büyük depolarda bile push'u hızlı yapar. Git Protokolü, iletilen veri miktarını en aza indiren akıllı aktarım kullanır.

Uzak dal, yerel olarak bulunmayan commit'ler içeriyorsa, push reddedilecektir. Bu, değişiklik kaybını önleyen koruyucu bir mekanizmadır. Bu durumda, geliştirici önce git pull'u çalıştırmalı, değişiklikleri birleştirmeli ve ancak ondan sonra tekrar push yapmalıdır. Bir alternatif, uzak dalın üzerine yazan force push'tur, ancak dikkatli kullanılmalıdır.

Uzak depoları anlamak, doğru push'un anahtarıdır. Genellikle origin, varsayılan uzak depo adıdır. Git remote -v komutu, uzak depoları ve URL'lerini listeler. Birden çok remote ekleyebilirsiniz (örneğin, ana depo için origin ve fork için upstream).

Değişiklikler Ne Zaman Push'lanmalı

Temel kural: mantıksal olarak tamamlanmış her çalışma aşamasından sonra push yapın. Bir geliştirici bir görevi veya bir kısmını tamamladıysa — push zamanı gelmiştir. Ancak, derlemeyi bozan tamamlanmamış işi push'lamak önerilmez. Derlemenin bozulmaması, herhangi bir dala push yapmak için minimum gerekliliktir.

Ekip geliştirmede şu ritim benimsenir: sabah — iş arkadaşlarının değişikliklerini almak için git pull, gün içinde — birkaç commit ve bir veya iki push, akşam — tamamlanan tüm görevlerin son push'u. Geliştirici ne kadar sık push yaparsa, birleştirme çakışmaları riski o kadar düşük ve çalışma ilerlemesi o kadar şeffaf olur.

• Bir görevi tamamladıktan sonra — commit yapın ve nihai çözümü özellik dalına push'layın
• İşten ayrılmadan önce — tamamlanmamış işi özellik dalına push'layın (main'e değil!)
• PR oluşturmadan önce — tüm commit'lerin push'landığından ve incelemeye hazır olduğundan emin olun
• Rebase'den sonra --force-with-lease ile kendi özellik dalınıza push yapın

Güvenli Push Kuralları

Güvenli push, ekipte veri kaybını ve çakışmaları önleyen bir dizi kuraldır. İlk ve en önemli kural: projede doğrudan dağıtım yapılandırılmamışsa, asla doğrudan main veya master dalına push yapmayın. Modern ekiplerde, main dalı koruması GitHub dal koruması düzeyinde yapılandırılır.

İkinci kural: push yapmadan önce uzak dalla senkronize olun. Birleştirme sırasında birleştirme commit'lerinden kaçınmak için git pull --rebase çalıştırın. Bu, geçmişi basitleştirir ve doğrusal hale getirir. Push reddedilirse — çıplak force push kullanmayın, önce uzak dalda hangi commit'lerin göründüğünü anlayın.

Üçüncü kural: göndermeden önce otomatik olarak testleri ve lint'leri çalıştıran pre-push hook'ları ayarlayın. Testler başarısız olursa — push engellenir. Bu hook'lar Husky veya Git hook'ları (.git/hooks içindeki pre-push dosyası) aracılığıyla yapılandırılır.

Dördüncü kural: büyük ikili dosyaları push'lamayın. Git, ikili yapıtları depolamak için tasarlanmamıştır — depoyu şişirir ve işlemleri yavaşlatır. Büyük dosyalar için Git LFS (Large File Storage) kullanın. Bir ikili dosya zaten push'lanmış ve geçmişteyse, git filter-branch ile kaldırılmalıdır.

Push Başarısız Olursa Ne Yapmalı

Push başarısızlığının en yaygın nedeni, uzak dalın yerel olarak bulunmayan commit'ler içermesidir. Bu, başka bir geliştiricinin aynı dala değişikliklerini push'laması durumunda olur. Çözüm: git pull çalıştırın, çakışmaları çözün ve tekrar push yapın.

# Push reddedildi — önce fetch ve rebase yapın
git fetch origin
git rebase origin/main
# Çakışmaları çözün, ardından:
git push --force-with-lease

# Veya uzak değişiklikleri birleştirin
git pull origin main
git push

İkinci neden — dala yazma izinlerinin olmaması. Main dalı dal koruma kurallarıyla korunuyorsa, doğrudan push'lar yasaktır. Çözüm: bir özellik dalına push yapın ve bir Pull Request oluşturun. Koruma ayarları genellikle GitHub ayarları veya GitLab korumalı dalları aracılığıyla yönetilir.

Üçüncü neden — kimlik doğrulama sorunları. Eski kimlik bilgileri, SSH'ye geçiş veya kişisel erişim belirtecinin değişmesi. Çözüm: uzak URL'yi (git remote -v) kontrol edin ve kimlik bilgilerini güncelleyin. 2021'den beri GitHub, HTTPS için parola kimlik doğrulamasını kaldırdı — kişisel bir belirteç veya SSH anahtarı kullanın.