Git mülakat soruları: cevaplarıyla 25 soru

Git, neredeyse her yazılımcı, test uzmanı ve DevOps mülakatında sorulur: bazen ayrı bir bölüm olarak, bazen de lafın arasında («kötü bir sürümü nasıl geri alırsınız?»). Mülakatçı komutların bayraklarını ezberlemenizden çok modeli anlamanızla ilgilenir: commit nedir, branch nereyi gösterir, geçmişi ne yeniden yazar. Aşağıda en sık sorulan 25 soru ve iyi bir izlenim bırakacak düzeyde cevaplar var.

Sorular temelden ileriye doğru sıralanmıştır. Cevaplarken mümkünse kısa bir pratik örnek verin; bu, dokümantasyonu aktarmaktan daha çok takdir görür.

Temel sorular

1. Git nedir ve dağıtık versiyon kontrol sistemi merkezi sistemden nasıl ayrılır?

Git dağıtık bir versiyon kontrol sistemidir: proje geçmişini saklar ve birden çok kişinin aynı proje üzerinde paralel çalışmasını sağlar. Merkezi sistemlerde (örneğin SVN) tüm geçmiş tek bir sunucuda durur, geliştiricide yalnızca çalışma kopyası bulunur. Git'te ise her klon tüm geçmişi içerir; bu yüzden commit'ler, branch'ler, geçmişe bakmak ve birleştirmeler yerelde ve ağa ihtiyaç duymadan çalışır.

Pratik avantajları: yüksek hız, çevrimdışı çalışma ve tek bir arıza noktasının olmaması. GitHub ya da GitLab gibi bir sunucu, Git açısından «ana» kopya konusunda ekibin anlaşmasından ibarettir; teknik bir zorunluluk değildir.

2. Git ile çalışmanın üç alanı nedir?

Çalışma dizini (diskteki dosyalar), indeks ya da staging area (bir sonraki commit'in hazırlanmış görüntüsü) ve yerel depo (.git klasöründeki geçmiş). git add değişiklikleri çalışma dizininden indekse, git commit ise indeksten depoya taşır.

Güzel bir ek bilgi olarak dördüncü alanı, uzak depoyu ve onunla çalışan git push ile git fetch komutlarını da anabilirsiniz.

3. Commit sırasında doğrudan commit yapılabilirken indeks neden var?

İndeks, commit'i bilinçli biçimde oluşturmanızı sağlar: on değiştirilmiş dosyadan yalnızca aynı göreve ait üçünü commit edip kalanı bırakabilirsiniz. git add -p ile bir dosyanın içindeki tek tek parçaları bile seçebilirsiniz.

Bu, atomik commit'lerin temelidir: bir commit, bir mantıksal değişiklik. Böyle bir geçmiş okunması, incelenmesi, revert ile geri alınması ve cherry-pick ile taşınması kolay bir geçmiştir.

4. Git'in iç yapısında bir commit nedir?

Commit, proje dosyalarının tamamının anlık görüntüsünü tutan bir ağaca (tree) referans verir; ayrıca üst commit'lere referansları, yazarı, committer'ı, tarihleri ve mesajı içerir. Tüm içeriğinden hesaplanan SHA-1 hash'iyle tanımlanır (yeni sürümlerde deneysel SHA-256 desteği de vardır).

Anahtar fikir: Git farkları değil anlık görüntüleri saklar. Değişmeyen dosyalar çoğaltılmaz; ağaç aynı blob'a işaret eder. Hash ebeveyne bağlı olduğu için, eski bir commit'i değiştirip sonraki tüm hash'leri aynı bırakmak mümkün değildir.

5. Branch nedir, HEAD nedir?

Branch, bir commit'e işaret eden hareketli bir işaretçidir; içinde hash bulunan küçük bir dosyadır (.git/refs/heads/ altında). Bu yüzden branch oluşturmak anlıktır ve hiçbir şeyi kopyalamaz. Yeni bir commit yapıldığında mevcut branch'in işaretçisi o commit'e ilerler.

HEAD ise şu anda bulunduğunuz yeri gösterir; genellikle bir branch'e işaret eder (ref: refs/heads/main). Doğrudan bir commit'e ya da etikete geçerseniz HEAD o commit'i gösterir: bu, detached HEAD durumudur.

6. Detached HEAD nedir ve neden tehlikelidir?

HEAD bir branch yerine doğrudan bir commit'i gösterdiğinde oluşan durumdur; örneğin git switch --detach v1.0 ya da git checkout a1b2c3d sonrasında. Kodu incelemek ve commit yapmak mümkündür, ama yeni commit'ler hiçbir branch'e ait olmaz.

Bu durumdan bir branch'e geçerseniz, bu commit'ler erişilemez hâle gelir ve zamanla çöp toplayıcı tarafından silinir. İşinizi korumak için bir branch oluşturun: git switch -c fix-from-detached. Zaten ayrıldıysanız hash'i git reflog içinde bulabilirsiniz.

7. git fetch ile git pull arasındaki fark nedir?

git fetch, yeni commit'leri indirir ve origin/main gibi uzak izleme branch'lerini günceller, ama yerel branch'lerinize ve dosyalarınıza dokunmaz. git pull ise fetch artı entegrasyondur: varsayılan olarak merge, --rebase bayrağı ya da pull.rebase=true ayarıyla rebase.

Deneyimli geliştiriciler çoğu zaman fetch'i ayrı çalıştırır, git log HEAD..origin/main ile bakar ve ancak ondan sonra değişiklikleri nasıl birleştireceklerine karar verir.

8. .gitignore nasıl çalışır ve eklediğim hâlde bir dosya neden hâlâ izleniyor?

.gitignore, Git'in eklemeyi önermemesi gereken dosya kalıplarını tanımlar: bağımlılıklar, derleme çıktıları, günlükler, gizli bilgi içeren yerel yapılandırmalar. Kurallar yalnızca izlenmeyen dosyalar için geçerlidir.

Dosya daha önce commit edilmişse, ignore kuralı ona etki etmez. Dosyayı diskte bırakarak indeksten çıkarmanız gerekir: git rm --cached config.local.php ve bu silmeyi commit edin. Hangi kuralın devreye girdiğini görmek için git check-ignore -v yol kullanılır.

Branch'ler, birleştirme ve çakışmalar

9. Fast-forward merge nedir?

Hedef branch, ayrıldığı noktadan beri ilerlemediyse Git birleştirmede yalnızca işaretçiyi birleştirilen branch'in son commit'ine taşır; yeni commit oluşturmaz. Geçmiş doğrusal kalır.

--no-ff bayrağı, bu durumda bile bir merge commit'i oluşturur: böylece commit grubunun ayrı bir özellik olduğu geçmişte görünür. --ff-only ise yalnızca fast-forward'a izin verir ve gerçek bir birleştirme gerekiyorsa reddeder.

10. Birleştirme çakışması nasıl oluşur ve nasıl çözülür?

Çakışma, iki branch'te aynı satırlar değiştirildiğinde (ya da bir dosya bir tarafta silinip diğerinde değiştirildiğinde) ve Git bunu otomatik çözemediğinde oluşur. Git birleştirmeyi durdurur ve yerleri <<<<<<<, =======, >>>>>>> işaretleriyle gösterir.

git status                 # çakışan dosyaların listesi
# dosyaları düzenleyin, doğru sürümü bırakın
git add app.js
git commit                 # merge için; rebase için git rebase --continue

İyi bir cevap önlemi de içermelidir: küçük branch'ler, ana branch'ten sık çekme (pull) ve biçimlendirme konusunda anlaşma. Geri çekilmek gerekirse git merge --abort de bilinmelidir.

11. merge ile rebase arasındaki fark nedir?

merge, iki branch'i birleştirip iki ebeveyni olan bir merge commit'i oluşturur; mevcut commit'ler değişmez, geçmiş paralel çalışmayı dürüstçe gösterir. rebase, branch'inizin commit'lerini başka bir branch'in üzerine yeniden uygular ve yeni hash'li kopyalar oluşturur; geçmiş doğrusal olur.

Genel kural: rebase'i yayımlamadan önce kendi yerel branch'inizi düzenlemek için, merge'ü ise ortak branch'lere entegrasyon için kullanın. Başkalarının üzerinde çalıştığı yayımlanmış commit'leri rebase etmek kopyalara ve karışıklığa yol açar.

12. İnteraktif rebase nedir ve ne işe yarar?

git rebase -i HEAD~5, son beş commit'i listeleyen bir editör açar; her biri için bir işlem seçebilirsiniz: pick — bırak, reword — mesajı değiştir, edit — dur ve düzenle, squash ve fixup — bir öncekiyle birleştir, drop — sil. Satırları yer değiştirerek sırayı da değiştirebilirsiniz.

Tipik kullanım: pull request açmadan önce «wip», «fix typo», «bir düzeltme daha» gibi commit'leri iki üç anlamlı commit'e dönüştürmek. Kullanışlı bir ikili: git commit --fixup=<hash> ve ardından git rebase -i --autosquash.

13. Squash merge nedir ve ne zaman tercih edilir?

Squash merge'de branch'in tüm commit'leri hedef branch'te tek bir commit'e sıkıştırılır (git merge --squash ya da GitHub/GitLab'deki düğme). Ana branch özellik başına tek commit alır.

Artısı, main'in temiz bir geçmişe sahip olmasıdır. Eksisi, özelliğin içindeki ayrıntılı geçmişin kaybolması ve Git'in kaynak branch'i birleştirilmiş saymaması; bu yüzden git branch -d -D olmadan silmeyi reddeder.

14. cherry-pick nedir ve ne zaman uygundur?

git cherry-pick <hash>, tek bir commit'in değişikliklerini mevcut branch'e uygular ve aynı içerikli ama farklı hash'li yeni bir commit oluşturur. Klasik örnek, develop'taki bir hata düzeltmesini bir release ya da hotfix branch'ine taşımaktır.

Aşırı kullanmamak gerekir: aynı düzeltme iki commit'te yaşar ve sonraki birleştirmelerde çakışma çıkabilir. -x bayrağı, mesaja kaynak commit'in bağlantısını ekler.

Geri alma ve kurtarma

15. git reset --soft, --mixed ve --hard arasındaki fark nedir?

Mod	Branch işaretçisi	İndeks	Çalışma dizini
--soft	geri gider	değişmez	değişmez
--mixed (varsayılan)	geri gider	sıfırlanır	değişmez
--hard	geri gider	sıfırlanır	sıfırlanır, düzenlemeler kaybolur

git reset --soft HEAD~3, son üç commit'i tek bir commit olarak yeniden yapmak için kullanışlıdır. --hard ise commit edilmemiş düzenlemeler için tehlikelidir: bunları reflog bile geri getiremez.

16. git revert, git reset'ten nasıl farklıdır?

reset, branch işaretçisini geriye taşır ve fiilen geçmişi yeniden yazar. revert ise belirtilen commit'in değişikliklerini geri alan yeni bir commit oluşturur ve hiçbir şeyi yeniden yazmaz.

Bu yüzden ortak branch'te yayımlanmış bir commit için doğru cevap revert'tir: meslektaşların geçmişi bozulmaz, geri alma logda görünür kalır. Merge commit'i için ana ebeveyni belirtmek gerekir: git revert -m 1 <hash>.

17. Yanlışlıkla git reset --hard yaptıysam commit'leri nasıl geri getiririm?

git reflog ile: Git, HEAD'in ve branch'lerin hareketlerini yerel olarak tutar (varsayılan olarak kayıtlar yaklaşık 90 gün yaşar). Hatalı komuttan önceki kaydı bulup oraya dönersiniz:

git reflog
# a1b2c3d HEAD@{0}: reset: moving to HEAD~2
# 9f8e7d6 HEAD@{1}: commit: Ödeme ekle
git reset --hard 9f8e7d6

Önemli bir çekince: reflog yalnızca commit edilmiş şeyleri kurtarır. Hiç commit'e (ya da en azından stash'e) girmemiş değişiklikleri Git ile geri getirmek mümkün değildir.

18. Bir dosyadaki değişiklikleri nasıl geri alır ve dosyayı indeksten nasıl çıkarırım?

Güncel komutlar: git restore app.js (dosyayı indeks durumuna döndürür) ve git restore --staged app.js (indeksten çıkarır, düzenlemeleri korur). Eskiden bunun için git checkout -- app.js ve git reset HEAD app.js kullanılırdı; bunlar hâlâ çalışır.

19. git stash nedir ve hangi tuzakları vardır?

git stash, commit edilmemiş değişiklikleri geçici olarak saklar ve çalışma dizinini temizler; örneğin acilen bir hotfix'e geçmek için. Geri almak için git stash pop ya da apply kullanılır.

Tuzaklar: varsayılan olarak izlenmeyen dosyalar saklanmaz (-u gerekir); pop sırasında çakışma çıkarsa kayıt listeden silinmez; stash'i unutmak kolaydır. Uzun süren işler için ayrı bir branch'e commit yapmak daha iyidir.

İleri düzey sorular ve ekip çalışması

20. Hatayı hangi commit'in getirdiğini nasıl bulursunuz?

git bisect ile: geçmişte ikili arama yapar. Kötü ve iyi bir commit belirtirsiniz; Git sizi aralığın ortasına yerleştirir ve suçluyu log2(N) adımda bulana kadar devam eder.

git bisect start
git bisect bad                 # şu anki sürüm bozuk
git bisect good v2.3.0         # burada her şey çalışıyordu
# kontrol edip good/bad yanıtı verin, Git commit'i söyleyene kadar
git bisect reset

Bir kontrol betiğiniz varsa süreç otomatikleşir: git bisect run npm test.

21. git push --force neden tehlikelidir ve yerine ne kullanılmalıdır?

--force, uzak branch'i sizin sürümünüzle ezer; meslektaşlarınızın göndermiş olduğu commit'ler sunucudan kaybolur. Daha güvenli olan git push --force-with-lease'tir: branch yalnızca son fetch'te gördüğünüz durumdaysa üzerine yazar.

Force push, rebase sonrası kendi feature branch'iniz için normaldir; main ve diğer ortak branch'lerde ise sunucudaki branch koruması ile genellikle yasaktır.

22. Hangi Git workflow'larını biliyorsunuz?

GitHub Flow: her zaman deploy'a hazır tek bir ana branch ve inceleme ile CI'dan geçtikten sonra pull request ile birleşen kısa feature branch'leri. Git Flow: main ve develop ile birlikte feature/*, release/* ve hotfix/* branch'leri; sürümlü ürünler için uygundur. Trunk-based development: herkes trunk'a çok sık entegre olur, tamamlanmamış işler feature flag'lerle gizlenir.

Güçlü bir cevap seçimi gerekçelendirir: sürekli deploy yapan bir web servisi için Git Flow genellikle fazladır; birden çok sürümü destekleyen bir kütüphane için ise haklı çıkar.

23. Pull request nedir ve içinde neler kontrol edilir?

Pull request (GitLab'de merge request) bir branch'in birleştirilmesi için yapılan istektir; birleşmeden önce kod incelemesi ve otomatik CI kontrollerinden geçer. Bu, Git'in değil GitHub, GitLab ya da Bitbucket gibi platformların bir özelliğidir.

İyi bir PR küçüktür, tek bir görevi çözer, açık bir açıklamaya sahiptir ve görev takipçisindeki işe bağlıdır. İnceleyen kişi doğruluğa, okunabilirliğe, testlere ve PR'a yanlışlıkla eklenmiş dosyalar ya da gizli bilgiler olup olmadığına bakar.

24. Hangi kurallara uyarak commit mesajı yazarsınız?

Kısa bir başlık (50–72 karakter civarı), emir kipinde — «E-posta doğrulaması ekle» — ardından boş bir satır ve «ne»yi değil «neden»i açıklayan bir gövde. «Ne değişti» zaten diff'te görünür. Birçok ekip Conventional Commits kullanır: feat:, fix:, docs:, refactor:.

Bu tür mesajlar değişiklik günlüğü (changelog) üretmeyi, git log --grep ile hızlı arama yapmayı ve yıllar sonra değişikliğin nedenini anlamayı kolaylaştırır.

25. Yanlışlıkla bir şifreyi depoya push ettiyseniz ne yaparsınız?

İlk iş, sırrı iptal edip yenisini üretmektir: bir dakika sonra silseniz bile sızmış kabul edilir (klonlar, fork'lar, önbellek). Sonra dosyayı izlemeden çıkarın, .gitignore'a ekleyin ve gerekirse git filter-repo gibi araçlarla geçmişi temizleyin; ardından force push ve ekibe bilgilendirme yapın.

Mülakatçı burada önceliği ölçer: geçmişi yeniden yazmaya başlayıp anahtarın iptalini unutan aday yanlış cevap vermiş olur.

Nasıl hazırlanılır

En güvenilir yol cevapları ezberlemek değil, her senaryoyu test bir depoda elinizle denemektir: bir çakışma yaratıp çözmek, reset --hard yapıp reflog ile geri dönmek, interaktif rebase ile commit'leri birleştirmek. Git mülakatlarında çoğu zaman pratik bir görev verilir ya da bir komuttan önce ve sonra commit grafiğini çizmeniz istenir; bunları kendiniz yaptıysanız cevap kendiliğinden gelir.

Kendinizi test etmek için kısa bir Git bilgi testi de işe yarar: yardım almadan, git rebase main ya da git revert HEAD sonrasında geçmişin nasıl değişeceğini söyleyebiliyor musunuz? «Üç alanda neler değişir?» sorusuna emin olarak cevap verebiliyorsanız temeliniz sağlamdır.

Kısaca

Git mülakatları neredeyse her zaman üç konuya iner: veri modeli (commit, branch, HEAD, indeks), değişiklikleri birleştirme (merge, rebase, çakışmalar, fetch ve pull) ve güvenli geri alma (reset, revert, reflog). Bunlara ekip workflow'u ve pull request bilgisini eklediğinizde soruların büyük çoğunluğunu yanıtlayabilirsiniz. Bu senaryoların tamamı, ekip çalışması ve ileri araçlar dahil, Git kursunda uygulamalı olarak çalışılmaktadır.