Yazılım Geliştirme & GitHub — Index Grup Eğitim Portalı

1. Makinen Hazır mı?

Yazılı Anlatım

İlk günlerdeki hedefin, kod yazmaya hazır bir makineye sahip olmak: araçlar kurulu, depolara erişim açık, ana proje yerelde çalışıyor. Aşağıdaki tablo başlangıç için beklenen araç setini gösterir.

Kategori	Araç	Not
IDE / Editör	Visual Studio Code + proje eklentileri	Mentorun proje özelindeki eklentileri gösterir
Sürüm kontrolü	Git + GitHub	Depo erişimi yetkiyle açılır; her iş branch + PR ile ilerler
Programlama dilleri	JavaScript/TypeScript, SQL ve projeye göre .NET	İlk hedef dili ezberlemek değil, projeyi çalıştırmaktır
Veritabanı araçları	SSMS veya DBeaver	Yalnızca geliştirme/test veritabanlarına bağlan
API test	Postman veya benzeri API istemcisi	Ortak koleksiyonları mentorundan iste
İş takibi	GitHub Issues, Azure DevOps veya Jira	Görev, açıklama, durum ve test notları burada tutulur
AI araçları	Şirketin onayladığı AI asistanları	Bkz. AI Araçları modülü

Ortam kavramları

Kod, canlıya çıkana kadar birden fazla ortamdan geçer. Bu ayrımı ilk günden öğren:

Geliştirme (dev): Kendi makinen. Burada her şeyi deneyebilirsin.
Test / Staging: Canlıya benzeyen ortak ortam; değişiklikler burada doğrulanır.
Canlı (production): Bayilerin ve çalışanların gerçekten kullandığı sistem. Canlıya doğrudan müdahale edilmez; her değişiklik süreçten geçer.

İlk günden kural Geliştirme yaparken asla canlı veritabanına bağlanma ve gerçek müşteri/bayi verisiyle test etme. Test için maskelenmiş veya sentetik veri kullanılır — bkz. KVKK konusu.

İlk hafta hedefi Ana projeyi klonla, README'deki adımlarla yerelde ayağa kaldır ve küçük bir değişikliği çalışır halde gör. Takıldığın her adımı not et — o notlar README'yi iyileştirmek için birinci sınıf malzemedir ve ilk katkın (pull request'in) bu iyileştirme olabilir.

Derinlemesine öğren

roadmap.sh Yazılımcı yol haritaları — hangi teknoloji nereye götürür EN

2. Git: Kodun Zaman Makinesi

Yazılı Anlatım

Git, kodun tüm değişiklik tarihini tutan sürüm kontrol sistemidir. "Dün çalışıyordu"nun kanıtı, yanlışlıkla silinenin sigortası ve ekipçe aynı kod üzerinde çakışmadan çalışmanın altyapısıdır. Okulda kullandıysan bile, ekip içinde kullanımın kendine özgü disiplinleri var.

Temel kavramlar

Kavram	Anlamı
Repository (repo)	Projenin kod deposu — kodun ve tüm geçmişinin bulunduğu yer
Commit	Yaptığın değişikliğin anlamlı bir mesajla kaydedilmiş "fotoğrafı"
Branch (dal)	Ana koddan ayrılan çalışma kopyası; işini burada yaparsın
Merge	Bir daldaki değişikliklerin başka dala birleştirilmesi
Pull / Push	Uzak depodan güncellemeleri alma / kendi commit'lerini gönderme
Conflict (çakışma)	İki kişinin aynı satırı değiştirmesi; elle çözülür, panik gerektirmez

Günlük döngün

git pull — güne ana dalın son haliyle başla.
git checkout -b feature/is-adi — işin için yeni dal aç.
Kodla; mantıklı adımlarda git add + git commit yap.
git push — dalını GitHub'a gönder ve pull request aç (sonraki konu).

İyi commit mesajı

Commit mesajı, altı ay sonra o değişikliğe bakacak kişiye (muhtemelen sana) yazılmış nottur. "düzeltme", "son hali", "asdf" mesaj değildir. İyi mesaj ne değiştiğini ve nedenini söyler: "Bayi sipariş listesinde tarih filtresinin saat dilimi hatası giderildi".

Küçük commit, sık commit Bir günde tek dev commit yerine, her mantıklı adımda küçük commit yap. Hata arandığında hangi değişikliğin sorun çıkardığını bulmak dakikalar sürer; dev commit'te saatler.

Derinlemesine öğren

Learn Git Branching Git'i oyunlaştırılmış görsel egzersizlerle öğren TR Pro Git Kitabı Git'in resmi kitabı — Türkçe çevirisi TR

3. PR Kültürü: GitHub'da Ekip İşi

Video + Özet

Kodumuz şirketin GitHub organizasyonunda barınır ve tüm ekip çalışması pull request (PR) akışı üzerinden yürür. Bu akış ekranda görerek en hızlı öğrenilen konu olduğu için videolu anlatılıyor: dal açmaktan PR açmaya, review yorumlarına cevap vermekten merge'e kadar örnek bir akış.

Akışın özeti

Issue/görev al: Her iş bir kayıtla başlar; hangi işi neden yaptığın her zaman izlenebilir olmalı.
Dal aç: Ana daldan (main) feature/… veya fix/… önekiyle dal açılır. Ana dala doğrudan push kapalıdır.
Pull request aç: İş bitince PR açılır; açıklamaya ne yaptığını, neden yaptığını ve nasıl test ettiğini yaz.
Code review: En az bir ekip arkadaşının onayı gerekir. Yorumlar koda yapılır, kişiye değil — savunmaya geçme, öğren ve düzelt.
Merge & temizlik: Onaylanan PR ana dala birleştirilir, dal silinir; değişiklik test ortamına otomatik/elle dağıtılır.

Code review kültürümüz

Review, hata bulmak kadar bilgi paylaşmak içindir — yeni biri olarak PR'ları okumak, kod tabanını öğrenmenin en hızlı yoludur.
Review'a gönderilen PR küçük ve odaklı olmalı; 1.000 satırlık PR'ı kimse sağlıklı inceleyemez.
Aldığın her yorum bir hediyedir: kıdemli birinin zamanını senin koduna ayırması, ekibin sana yaptığı yatırımdır.

Depoya asla girmeyecekler Parolalar, API anahtarları, bağlantı dizeleri (connection string) ve müşteri verileri asla commit'lenmez — "sonra silerim" işe yaramaz, Git geçmişi hatırlar. Gizli değerler için ekipteki standart yöntemi (ör. ortam değişkenleri, secret yönetimi) mentorundan öğren. Yanlışlıkla bir gizli değer push ettiysen hemen bildir: değer değiştirilir, geçmiş temizlenir.

Derinlemesine öğren

GitHub Docs — Pull Requests PR akışının resmi dokümantasyonu EN GitHub Skills İnteraktif, uygulamalı GitHub kursları EN

4. Talepten Canlıya

Yazılı Anlatım

Kod yazmak sürecin sadece bir halkası. Bir işin talepten canlıya yolculuğu şöyle işler temel akış şöyledir:

Talep ve analizİş birimlerinden gelen ihtiyaç kayda alınır, geliştirme yöneticisi ve analistlerle netleştirilir: ne isteniyor, neden, kimin için?
Planlamaİş; sprint planında önceliklendirilir, tahminlenir ve bir geliştiriciye atanır.
GeliştirmeDal aç → kodla → test yaz → commit'le. Takıldığında 15 dakika kuralı burada da geçerli.
Review ve testPR + code review; ardından test/staging ortamında doğrulama. Gerekirse iş birimi de burada onay verir.
Canlıya çıkış (deploy)Onaylı değişiklik planlı pencerede canlıya alınır; çıkış sonrası izlenir. Sorun çıkarsa geri alma (rollback) planı hazırdır.

Yeni başlayan biri olarak senden beklenenler

Sana atanan işlerin kapsamını netleştirmeden kodlamaya başlama — "neyi çözdüğünü" bilmeden yazılan kod, iki kez yazılır.
Test edilmemiş kodu review'a gönderme; "bende çalışıyor" bir test raporu değildir.
Canlı sistemlere dokunan her adımda (deploy, veritabanı script'i) mutlaka yetkili birinin gözetiminde ol.
Öğrendiklerini dokümante et: README'ler, wiki sayfaları ve kod yorumları da üründür.

Neden bu kadar süreç? Değer zincirini hatırla: yazdığın kod, binlerce bayinin sipariş verdiği sistemlerde koşuyor. Süreç bürokrasi değil; o ölçekte hata yapmamanın sigortasıdır.