💼 Git ve GitHub Mülakat Soruları

Git ve GitHub Mülakat Soruları: Git mülakatında komut saymak, bir şoföre trafik levhalarını ezberden okutmaya benzer: levhaları bilmek gereklidir ama kimse bu yüzden onu yola çık

Git mülakatında komut saymak, bir şoföre trafik levhalarını ezberden okutmaya benzer: levhaları bilmek gereklidir ama kimse bu yüzden onu yola çıkarmaz — asıl merak edilen, sıkışık bir kavşakta hangi kararı vereceğidir. Peki `git revert` ile `git reset`’in ne yaptığını zaten biliyorsan, mülakatta bunu söylemek neden yetmiyor? Çünkü soru aslında "hangisi doğru" değil, "paylaşılan bir branch’te geçmişi ezmenin ekibe maliyetini görüyor musun" sorusudur — teknik bilgi eşiktir, ayrıştırıcı olan muhakemedir. Java tarafında da fark buna benzer: `HashMap`’in nasıl çalıştığını anlatmak orta seviyedir, `equals`/`hashCode` sözleşmesi bozulduğunda production’da neyin sessizce kaybolacağını anlatmak kıdemli seviyedir. QA açısından ölçülen yetkinlik nettir: sen yalnızca kendi commit’lerinden değil, ekibin history’sinden, rollback yapılabilirliğinden ve bir regresyonun kökeninin altı ay sonra kanıtlanabilmesinden de sorumlusun. Bu yüzden her cevabı üç ayakla kur: ne yaptığın, neden o yolu seçtiğin ve yanlış giderse nasıl geri döneceğin.

🎬 Senaryo Sorusuna Güçlü Cevap Anatomisi

Mülakatçı soruyor: "Yanlışlıkla main'e commit attın, henüz push etmedin — ne yaparsın?" Bu filmde aynı soruya iki cevabın — ezber ile yapılandırılmış cevabın — farkını izleyeceksin.

Zayıf refleks: "git reset kullanırım." Hangi reset? İş kaybolur mu? Push edilmiş olsaydı ne değişirdi? Komut adı ezberlemek Google'da arama yapabilmekle eşdeğerdir — mülakatçı derinliği burada GÖREMEZ.

Güçlü cevabın 1. katmanı — durumu TESPİT et: "Önce `git status` ve `git log --oneline -3` ile neyin commit'lendiğini ve push edilip edilmediğini doğrularım. Push yoksa tarih hâlâ sadece bende — hareket alanım geniş."

2. katman — komut + GEREKÇE: "`git reset --soft HEAD~1` derim, çünkü commit'i geri alırken işi staging'de KORUR. `--hard` da commit'i geri alırdı ama emeği silerdi." Alternatifi neden SEÇMEDİĞİNİ söylemek, komutun kendisinden daha değerlidir.

3. katman — TAKIM güvenliği: "Commit push edilmiş OLSAYDI reset kullanmazdım; paylaşılan tarihi yeniden yazmak takımın referanslarını bozar. Orada `git revert` ile geri alma commit'i eklerdim." Bu cümle, gerçek takım tecrübesinin kanıtıdır.

4. katman — Java köprüsü: "reset --soft, IDE'deki 'undo commit'e benzer — değişiklik durur, kayıt geri alınır; revert ise muhasebedeki ters kayıt gibi bir compensating transaction'dır: tarihi silmez, düzelten yeni bir kayıt ekler." Bildiğin dünyaya köprü kurmak cevabı kalıcı yapar.

Final — formül: durum tespiti → komut + gerekçe → takım güvenliği/risk → Java analojisi. Aşağıdaki her mülakat sorusunda cevabını bu 4 katmandan geçir; sıralı düşünen aday, komut ezberleyeni her zaman geçer.

Adım Adım: Senaryo Cevabı Kurma

Cevaba kosullari netlestirerek basla: push edildi mi, kac commit var, kimler etkilenir? Mulakatci bu sorulari sordugunu duymak ister — gercek iste de ilk adim budur.

Kanıt komutlarını söyle

"Once `git status` ve `git log` ile gorurum" de — korkusuzca komut listelemek degil, KANIT toplama refleksini gostermek puandir.

Secilen komutu NEDENiyle soyle ve reddettigin alternatifi ekle: "--soft isi korur, --hard silerdi". Gerekce yoksa cevap ezberden ayirt edilemez.