Git ve GitHub: VS Code’da Başlarken İşin Püf Noktaları
İşin aslı şu ki, Git ile ilk tanışan ekiplerin çoğu aynı yere takılıyor: “Ben kodu yazıyorum. Bunu düzgün yönetmek neden bu kadar karışık?” Geçenlerde, 2025 Mart ayında İstanbul’daki bir finans müşterisinde tam da bunu konuştuk. Ekip kodu terminalden halletmeye çalışıyordu, sonra bir kısmı GitHub Desktop’a kaçıyor, bir kısmı da VS Code içinde kayboluyordu. Ortaya biraz dağınık bir tablo çıkmıştı. VS Code’un olayı burada devreye giriyor; çünkü editörün içinden çıkmadan repository açmak, branch değiştirmek, stage etmek, commit atmak. Push yapmak bayağı iş görüyor.
Ben açık konuşayım: 20+ yıllık sistemcilik ve bulut tarafında gördüğüm en büyük sorunlardan biri araç sayısının fazla olması değil, araçlar arasında zıplama ihtiyacı. Bir ekran başka şey söylüyor, terminal başka şey gösteriyor… sonra insanın dikkati dağılıyor. VS Code’un GitHub entegrasyonu bu karmaşayı azaltıyor. Mükemmel mi? Değil. Ama günlük işte fena hâlde pratik.
Git mi GitHub mı? Karıştırılan yer burası
Lafı gevelemeden söyleyeyim: Git, versiyon kontrol motoru gibi düşünülmeli; GitHub işe bunun üstüne kurulan paylaşım. Işbirliği katmanı. Yanı arabayı süren şey motor, yolculuğu organize eden şey de rota sistemi gibi. Birçok kişi bu ikisini aynı sanıyor ama değil.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
2019’da Ankara’da orta ölçekli bir yazılım ekibinde danışmanlık yaparken buna birebir şahit oldum. Geliştiriciler “GitHub’a commit attım” diyordu ama aslında kastettikleri şey local repoda değişiklikti. Commit başka şeydi, push başka şeydi… işte orada ufak ama can sıkıcı hatalar çıktı. Bu ayrımı netleştirmek başlangıçta çok kilit (kendi tecrübem)
Bence Türkiye’deki şirketlerde mesele sadece teknik bilgi eksikliği değil; süreç disiplini de eksik kalabiliyor. Mesela de küçük ajanslarda ya da hızlı büyüyen startup’larda herkes kendi yöntemini kullanınca branch isimleri bile saçma sapan hâle geliyor. Kurumsalda işe tersine fazla prosedür yüzünden hız düşüyor. Denge lazım.
VS Code neden bu kadar işe yarıyor?
VS Code’u sevmemin sebebi sadece ücretsiz olması değil; Git işlemlerini editörün içine gömmesi. Kodla uğraşırken ayrı pencereye geçmiyorsun, bağlam değişmiyor, kafa bölünmüyor. Bu küçük gibi görünen detay var ya… sahada bayağı fark ediyor.
Geçen yıl Kasım 2024’te İzmir’de bir e-ticaret ekibiyle çalışırken junior geliştiricilerin en çok zorlandığı nokta buydu: terminal komutlarını ezberlemek yerine görsel panelden ilerleyince daha az hata yaptılar (yanlış duymadınız). En çok da untracked dosya, staged alanı ve commit mesajı mantığını gözle görmek çok rahatlatıyor.
E tabi her güzel tarafın yanında birkaç pürüz de var (evet, doğru duydunuz). Çok büyük repolarda bazen Source Control paneli ağırlaşabiliyor; özellikle binlerce dosya varsa arayüz biraz hantallaşıyor (hani insan “bu kadarına gerek var mıydı?” diyor). O yüzden kurumsal yapılarda bazı işleri hâlâ terminalden yapmak daha temiz olabilir.
Peki neden?
Küçük ekip vs enterprise
Küçük ekipteyseniz hedef belli: hızlı başla, az sürtünme yaşa, herkes aynı akışı kullansın. VS Code burada iyi bir başlangıç sağlıyor çünkü öğrenme bariyeri düşük.
Bakın, Büyük kurumdaysanız olay değişiyor. Branch koruma kuralları, PR onayları, — itiraz edebilirsiniz tabi — commit standardı, secret taraması… bunlar olmadan iş yürümüyor zaten yürümemeli de! Ben AZ-104 ve AZ-305 çalışmalarında hep şunu düşündüm: teknik yetenek tek başına yetmez, süreç güvenliği de lazım.
Sıfırdan repository açmak: İlk adım neresi?
Aslında, Önce klasörü açıyorsun sonra Source Control ikonuna girip repository’yi initialize ediyorsun. Kulağa basit geliyor ama ilk kez yapan biri için bu an önemli; çünkü artık o klasör sıradan bir klasör olmaktan çıkıp takip edilen bir proje hâline geliyor.
Açık konuşayım, ilk denediğimde ben de ufak hata aldım: klasörü yanlışlıkla OneDrive senkronize dizinine koymuştum ve dosya durumları sürekli değişiyordu (klasik). Çözüm basit öldü: projeyi lokal ve sade bir dizine taşıdıktan sonra problem çözüldü.
Bir repo açarken en kritik nokta araç değil düzendir; yanlış klasör yapısı daha baştan sizi yorar.
Main dalının adıyla oynamak isteyenler Command Palette’i kullanabilir; Shift-Command-P veya Ctrl-Shift-P ile ulaşılırken “Git: Rename Branch” komutu hayat kurtarır gibi görünür ama aslında standartlaştırma sağlar.
| Aşama | Nerede Yapılır? | Neden Önemli? |
|---|---|---|
| Klasörü açma | Explorer paneli | Projeyi VS Code içine alırsın |
| Repository oluşturma | Source Control paneli | Git takibi başlar |
| Dallanma adı değiştirme | Command Palette | Ekip standardını korursun |
| Add / Commit / Push | Source Control içinden | Süreç tamamlanır |
Status harfleri ne anlatıyor?
Pek çok yeni kullanıcı “U” harfini görünce paniğe kapılıyor. Halbuki olay basit; — en azından ben öyle düşünüyorum — U = untracked demek yanı dosya henüz izlenmiyor demek oluyor. Dosyanın kötü olduğu anlamına gelmiyor… Neden önemli bu? sadece henüz Git’in radarına girmemiş oluyor.
Bana göre bu görsel göstergeler eğitim açısından çok değerli fakat tek başına yeterli değil.
Bir müşteri projesinde Şubat 2025’te bunu anlattığımızda geliştiriciler staging kavramını ancak birkaç örnek sonrası oturttu.
Mesela tüm dosyayı hemen stage etmek yerine yalnızca ilgili satırları seçerek gitmek daha kontrollü sonuç veriyor.
Bu yaklaşım özellikle enterprise tarafta audit açısından da daha temiz dürüyor.
- Mavi renk veya simge çoğu zaman değiştirilmiş dosyayı anlatır.
- U” genelde yeni eklenen ama takip edilmeyen dosyadır.
- M” işe modifiye edilmiş dosyaya işaret eder. — bunu es geçmeyin
- Tümünü tek seferde stage etmek bazen kolaydır ama risklidir!
Hmm, bunu nasıl anlatsamdı… Daha fazla bilgi için
Yanı sadece yerel repository üzerinde gayet rahat çalışabilirsin.
Commit ile push arasındaki fark nedir?
Açıkçası, Commit, değişikliği hani sadece kendi bilgisayarındaki geçmişe kaydediyor.
Push işe bunu uzak depoya gönderiyor. Bence bu ikisini karıştırmamak çok önemli, özellikle başta.
Yeni başlayan biri önce ne öğrenmeli?
Önce status mantığını kavra. Gerçekten temel bu.
Sonra add/commit/push sırasını öğrenirsen, tecrübeme göre geri kalan her şey çok daha kolay oturuyor.
VS Code mu terminal mi daha iyi?
Açıkçası ikisi de gerekli olabiliyor.
Başlangıçta VS Code seni çok rahatlatıyor; mesela her şeyi görsel olarak takip edebiliyorsun. Terminal işe zamanla daha derin bir kontrol sağlıyor.
Kaynaklar ve İleri Okuma
Azure DevOps Repos with Git documentation
Açıkçası, Visual Studio Code Source Control overview
Şöyle söyleyeyim, GitHub Docs — About Git
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
2 comments