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ı…
Tam burada pratik tavsiye:
Eğer yeni başladıysanız önce tek dosyada çalışın.
Sonra commit atın.
Ardından push edin.
Üç adımı ayrı ayrı görmek zihni toparlıyor.
Aksi hâlde her şeyi aynı anda yapmaya kalkınca nerede hata olduğunu bulmak zorlaşıyor… ciddi şekilde zorlaşıyor aslında.”
Kullanışlı akış nasıl kurulmalı?
”
“
Hani, “Benim önerim şu olurdu:
untracked → stage → commit → push sırasını ezberlemeyin sadece;
bunun mantığını anlayın.
stage alanı mutfakta hazırlanan tezgâh gibi düşünün…
yemeği direkt servis etmiyorsunuz önce toparlıyorsunuz.”
”
“
# Temel akış
git status
git add.
git commit -m "İlk düzenleme"
git push origin main
"”
“
“Terminal komutlarını bilmek yine faydalıdır çünkü UI bozulursa eliniz kolunuz bağlanmaz.
amma dürüst olayım,
kendime sorarsam günlük kullanımda VS Code üzerinden ilerlemek bana vakit kazandırıyor.”
“
“
Dikkat edilmesi gerekenler”
”“
“Commit mesajlarını boş geçmeyin.
‘test’ ya da ‘update’ yazıp bırakmak ileride kâbus olur.
Ben bunu log inceleyen ekiplerde defalarca gördüm.
Ne yaptığın belli olmazsa geri dönüş pahalıya patlar.”
“
“Branch isimlerini de insanca tutun.
feature/login-page gibi okunabilir isimler iyidir.
Şaka yok yanı,
yarın sabah o branch’e dönecek kişi sız olmayabilirsiniz.”
Zaman kazandıran küçük ipuçları”>
”“Ha bu arada…
VS Code’un built-in özelliklerini küçümsemeyin.
Diff görünümü,
merge conflict çözümü,
branch değiştirme menüsü…
bunların hepsi ayrı ayrı minik konfor.”
“
“Bir keresinde Nisan 2024’te Bursa’daki üretim odaklı bir müşteride merge conflict patlamıştı.
Takım iki saat terminalde debelenmişti;
sonra aynı işi VS Code diff ekranıyla on dakikada çözdüler.
Bazen doğru araç gerçekten fark yaratıyor.”
“
“Yine de her şeyi GUI’ye emanet etmeyin.
Sadece tıklayarak çalışan kişiler ortam bozulunca tamamen kilitlenebiliyor.
Bu yüzden ben yeni başlayanlara hem arayüzü hem temel komutları birlikte öğretiyorum.”
Sıkça Sorulan Sorular
VS Code ile Git kullanmak için GitHub hesabı şart mı?
Hayır, şart değil aslında (ciddiyim)
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder