Ekip Workflow'u

Giriş — Yalnız Değilsin

Git'i tek başına kullanmak ile bir ekiple kullanmak arasındaki fark, tek başına piyano çalmak ile bir orkestrada çalmak arasındaki fark gibidir. Tek başınayken istediğin nota'yı istediğin zaman çalabilirsin — kimse sana karışmaz. Ama bir orkestrada herkesin aynı partitura'dan çalması, aynı tempoda ilerlemesi ve birbirini dinlemesi gerekir. Aksi halde ortaya müzik değil, gürültü çıkar.

Profesyonel yazılım geliştirme de tam olarak böyledir. Bir startup'ta 3 kişilik bir ekip veya büyük bir şirkette 50 kişilik bir organizasyon — Git'i ekip olarak kullanmanın kendine has kuralları, gelenekleri ve "görgü kuralları" vardır. Bu derste, bir ekibin Git ile nasıl uyumlu çalışabileceğini, branch isimlendirmeden commit mesajlarına, PR süreçlerinden günlük workflow'lara kadar her şeyi ele alacağız.

Neden Workflow Gerekli?

Diyelim ki bir evde 5 kişi yaşıyorsunuz ve buzdolabı paylaşıyorsunuz. Herkes istediği yere istediği şeyi koyarsa, üç gün içinde buzdolabı kaosa döner — biri diğerinin yoğurdunu yer, süt dökülür, sebzeler çürür. Ama "alt raf ortak, ortalar kişisel, üst raf atıştırmalık" gibi basit bir kural koyarsanız, herkes rahat eder.

Bir yazılım ekibinde de durum aynıdır:

• Kimse hangi branch'te çalışacağını bilemez

• Commit mesajları anlamsız olur ("fix", "asdf", "wip")

• PR'lar reviewsız merge edilir

• Production'da bug çıkınca "kim yaptı bunu?" sorusu cevapsız kalır

İşte workflow, bu kaosu düzene çeviren sosyal sözleşmedir.

Branch Naming Convention — İsimlendirme Sanatı

Neden Önemli?

Bir ekipte 20 branch olduğunu düşünün. Eğer branch isimleri test, deneme, fix2, ahmet-branch gibi anlaşılmaz isimlerden oluşuyorsa, kimse hangi branch'in ne iş yaptığını anlayamaz. Ama feature/user-authentication, bugfix/login-timeout, hotfix/payment-crash gibi isimler görürseniz, hiçbir açıklama okumadan bile ne olduğunu anlarsınız.

Standart Prefix'ler

Endüstri standardı haline gelmiş prefix (önek) yapısı şöyledir:

feature/   → Yeni özellik
bugfix/    → Bug düzeltme (geliştirme sürecinde)
hotfix/    → Acil production fix
release/   → Release hazırlığı
chore/     → Teknik bakım, tooling, config
docs/      → Dökümantasyon
refactor/  → Kod iyileştirme (davranış değişmez)
test/      → Test ekleme/düzeltme

Naming Kuralları

İyi bir branch ismi şu kurallara uyar:

# ✅ İyi branch isimleri
feature/user-authentication
bugfix/cart-total-calculation
hotfix/payment-gateway-timeout
release/v2.3.0
chore/upgrade-react-19
docs/api-endpoint-reference

# ❌ Kötü branch isimleri
new-feature
fix
test123
ahmet
my-branch

Altın kurallar:

• Küçük harf kullan (case sensitivity sorunlarından kaçınmak için)

• Kelimeler arası tire (-) kullan (alt çizgi veya boşluk değil)

• Kısa ama açıklayıcı ol (max 3-4 kelime)

• Ticket/issue numarası ekle (varsa)

Ticket Numarası ile Kullanım

Çoğu profesyonel ekip, Jira, Linear veya GitHub Issues kullanır. Branch isminin başına veya sonuna ticket numarası eklemek, her branch'in hangi iş kalemine ait olduğunu netleştirir:

# Jira ticket ile
feature/PROJ-1234-user-authentication
bugfix/PROJ-5678-cart-calculation

# GitHub issue ile
feature/42-user-authentication
bugfix/108-login-timeout

# Branch oluşturma
git checkout -b feature/PROJ-1234-user-authentication

💡 İpucu: Birçok proje yönetim aracı, commit mesajlarındaki ve branch isimlerindeki ticket numaralarını otomatik olarak algılar ve ilgili kart/issue ile ilişkilendirir. Jira'da PROJ-1234 yazdığınızda, o issue'nun altında ilgili branch ve commit'leri görebilirsiniz.

Otomatik Branch İsimlendirme

GitHub, issue sayfasında "Create a branch" butonu sunar. Bu, doğru formatta branch ismi otomatik oluşturur:

# GitHub'ın otomatik oluşturduğu format
# Issue #42: "Add user authentication"
42-add-user-authentication

# Bunu kendi convention'ınıza göre düzenleyebilirsiniz
feature/42-add-user-authentication

Commit Convention — Anlamlı Commit Mesajları

Sorun: Anlamsız Commit Geçmişi

Şu git log'a bir bakın:

$ git log --oneline
a3f2c1d fix
b7e4a2f updated
c9d1b3e wip
d2f5c4a changes
e8a7d6b bug
f1c3e5d stuff

Bu commit geçmişinden hiçbir şey anlaşılmıyor. Bir hafta sonra siz bile neyi neden değiştirdiğinizi hatırlayamazsınız. Şimdi buna karşılık:

$ git log --oneline
a3f2c1d feat: add user registration form
b7e4a2f fix: resolve cart total rounding error
c9d1b3e docs: update API authentication guide
d2f5c4a refactor: extract payment logic to service
e8a7d6b test: add unit tests for user validation
f1c3e5d chore: upgrade dependencies to latest versions

Bu çok daha okunaklı, değil mi? İşte bunu mümkün kılan şey Conventional Commits standardıdır.

Conventional Commits Formatı

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Type (Tip) — Zorunlu

feat:     → Yeni özellik (MINOR versiyon artışı trigger'lar)
fix:      → Bug düzeltme (PATCH versiyon artışı trigger'lar)
docs:     → Dökümantasyon değişikliği
style:    → Kod formatı (boşluk, noktalı virgül — davranış değişmez)
refactor: → Kod iyileştirme (ne feat ne fix)
test:     → Test ekleme veya düzeltme
chore:    → Build, CI, tooling değişiklikleri
perf:     → Performans iyileştirme
ci:       → CI/CD pipeline değişiklikleri
build:    → Build system veya bağımlılık değişiklikleri
revert:   → Önceki commit'i geri alma

Scope (Kapsam) — Opsiyonel

Değişikliğin hangi modülü/bileşeni etkilediğini belirtir:

feat(auth): add OAuth2 support
fix(cart): resolve quantity update bug
docs(readme): add installation section
refactor(api): simplify error handling middleware

Description (Açıklama) — Zorunlu

• Emir kipi (imperative mood) kullanılır: "add" (added değil), "fix" (fixed değil)

• Küçük harfle başlar

• Sonunda nokta yok

• Max 72 karakter

# ✅ Doğru
feat(auth): add two-factor authentication
fix(payment): handle timeout for slow connections

# ❌ Yanlış
feat(auth): Added two-factor authentication.
fix: Fixed the bug
feat: New feature that I worked on for a very long time and it does many things at once

Body (Gövde) — Opsiyonel

Daha fazla açıklama gerektiğinde, boş satırdan sonra gövde eklenir:

git commit -m "fix(auth): handle expired JWT tokens gracefully

Previously, expired tokens caused a 500 error and the user
saw a blank page. Now the user is redirected to the login
page with a friendly message.

Closes #234"

Breaking Changes

API'da geriye dönük uyumsuz değişiklik yaptığınızda:

# Yöntem 1: ! işareti ile
feat(api)!: change authentication header format

# Yöntem 2: Footer'da
feat(api): change authentication header format

BREAKING CHANGE: Authorization header now uses Bearer scheme
instead of Token scheme. All API clients need to update.

Commit Mesajı Şablonu

Ekibiniz için bir şablon oluşturabilirsiniz:

# ~/.gitmessage dosyası oluşturun
cat > ~/.gitmessage << 'EOF'
# <type>(<scope>): <description>
#
# [body]
#
# [footer]
#
# Types: feat, fix, docs, style, refactor, test, chore, perf, ci, build, revert
# Scope: auth, cart, payment, user, api, ui, db, config
# Description: imperative mood, lowercase, no period, max 72 chars
# Body: explain WHY, not WHAT (the diff shows what)
# Footer: BREAKING CHANGE, Closes #issue, Refs #issue
EOF

# Git'e şablonu tanıtın
git config --global commit.template ~/.gitmessage

⚠️ Dikkat: Conventional Commits sadece bir "güzel görünsün" meselesi değildir. semantic-release gibi araçlar, bu commit mesajlarını otomatik olarak parse ederek versiyon numarası belirler, changelog oluşturur ve release yapar. Yani commit mesajınız aslında bir otomasyon komutudur.

Commitlint ile Zorlama

Kuralları sadece "rica" etmek yetmez — otomatize etmek gerekir:

# commitlint kurulumu
npm install -D @commitlint/cli @commitlint/config-conventional

# commitlint.config.js
echo "module.exports = { extends: ['@commitlint/config-conventional'] };" \
  > commitlint.config.js

# Husky ile pre-commit hook
npx husky add .husky/commit-msg 'npx --no -- commitlint --edit ${1}'

Artık kurala uymayan commit mesajları reddedilir:

$ git commit -m "yaptım bi şeyler"
⧗   input: yaptım bi şeyler
✖   subject may not be empty [subject-empty]
✖   type may not be empty [type-empty]

✖   Found 2 problems, 0 warnings

PR (Pull Request) Etiquette — Görgü Kuralları

PR Boyutu: Küçük Tutun

Bir PR'ın en önemli özelliği boyutudur. Araştırmalar gösteriyor ki:

• < 200 satır değişiklik: Review kalitesi yüksek, hızlı merge

• 200-400 satır: Kabul edilebilir

• 400+ satır: Review kalitesi düşer, bug gözden kaçar

• 1000+ satır: Kimse düzgün review yapamaz

PR Boyutu vs Review Kalitesi:

Kalite
  ▲
  │ ████
  │ ████████
  │ ████████████
  │ ████████████████
  │ ████████████████████
  │ ████████████████████████
  └────────────────────────────► Satır sayısı
   100  200  400   800  1000+

💡 İpucu: Büyük bir feature geliştiriyorsanız, onu mantıksal parçalara bölün. Örneğin bir "kullanıcı kayıt sistemi" için: - PR #1: Veritabanı migration ve model - PR #2: API endpoint'leri - PR #3: Frontend formu - PR #4: Email doğrulama

>

Her PR kendi başına mantıklı, test edilebilir ve review edilebilir olmalıdır.

PR Template Oluşturma

Her PR'da neyin değiştiğini, neden değiştiğini ve nasıl test edileceğini belirtmek büyük önem taşır. Bunu otomatize etmek için PR template kullanabilirsiniz:

<!-- .github/pull_request_template.md -->

## Açıklama
<!-- Bu PR ne yapıyor? Neden gerekli? -->

## Değişiklik Türü
- [ ] 🐛 Bug fix
- [ ] ✨ Yeni özellik
- [ ] 💥 Breaking change
- [ ] 📝 Dökümantasyon
- [ ] ♻️ Refactoring
- [ ] 🧪 Test

## İlgili Issue
<!-- Closes #issue_number -->

## Test
<!-- Bu değişikliği nasıl test ettiniz? -->
- [ ] Unit testler eklendi/güncellendi
- [ ] Manuel test yapıldı
- [ ] E2E testler eklendi/güncellendi

## Ekran Görüntüsü (UI değişikliği varsa)
<!-- Öncesi/sonrası screenshot -->

## Checklist
- [ ] Kod self-review yapıldı
- [ ] Yorum eklenmesi gereken yerlere yorum eklendi
- [ ] Dökümantasyon güncellendi
- [ ] Değişiklik geriye dönük uyumlu

Draft PR — Erken Geri Bildirim

Bir feature'ın yarısını bitirdiniz ama genel yaklaşımınız hakkında geri bildirim almak istiyorsunuz. İşte bunun için Draft PR var:

# Önce branch'e push edin
git push origin feature/user-auth

# GitHub'da PR açarken "Create draft pull request" seçin
# veya GitHub CLI ile:
gh pr create --draft --title "feat: user authentication" \
  --body "WIP - Feedback appreciated on the approach"

Draft PR'ların özellikleri:

• Merge edilemez (kazara merge'i önler)

• Reviewer'lara "henüz bitmedim ama bakabilirsin" mesajı verir

• Hazır olunca "Ready for review" butonuyla aktifleştirilir

Review Sürecinde İletişim

PR review'da iletişim tonu çok önemlidir. Kod eleştirmek kişisel algılanabilir — dikkatli olmak gerekir:

# ❌ Kötü review yorumu
"Bu kod çok kötü."
"Neden böyle yazdın?"
"Yanlış."

# ✅ İyi review yorumu
"Bu yaklaşım işe yarar ama şunu düşünür müsün: X pattern burada
daha bakımı kolay bir yapı sağlayabilir. Ne dersin?"

"Küçük bir öneri: Bu fonksiyon 50 satır olmuş.
Extract edersek test yazması da kolaylaşır."

"Soru: Bu null check burada yeterli mi? Y durumunda
hâlâ exception fırlatabilir gibi görünüyor."

Profesyonel review'da kullanılan etiketler:

# Zorunlu düzeltme
🔴 [MUST] Bu security açığı oluşturur, mutlaka düzeltilmeli.

# Güçlü öneri
🟡 [SHOULD] Bu yaklaşım yerine X pattern daha uygun olur.

# Opsiyonel iyileştirme
🟢 [NIT] Ufak bir isimlendirme önerisi: getUserData → fetchUserProfile

# Soru
❓ [QUESTION] Bu timeout değeri nereden geliyor? Config'den mi almalıyız?

# Övgü (bunu unutmayın!)
🎉 [PRAISE] Bu refactoring harika olmuş, çok daha okunabilir!

⚠️ Dikkat: Review'da sadece sorun bulmak yetmez. İyi yapılmış şeyleri de belirtmek, ekip moralini yükseltir ve iyi pratiklerin yaygınlaşmasını sağlar.

Günlük Ekip Workflow'u

Sabah Rutini

Güne başlarken ilk yapılacak şey, ana branch'i güncellemektir:

# 1. Ana branch'e geç
git checkout main

# 2. Remote'dan çek
git pull origin main

# 3. Çalışma branch'ine dön
git checkout feature/user-auth

# 4. Main'deki değişiklikleri al (rebase tercih edilir)
git rebase main

# Conflict varsa çöz, yoksa çalışmaya devam

Feature Geliştirme Döngüsü

┌──────────────────────────────────────────────────────────────┐
│                    Feature Development Cycle                  │
│                                                              │
│  1. Issue al  ──►  2. Branch oluştur  ──►  3. Geliştir      │
│       │                    │                      │          │
│       ▼                    ▼                      ▼          │
│   "PROJ-42"    feature/42-user-auth     commit, commit...    │
│                                                   │          │
│  6. Merge  ◄──  5. Review & Fix  ◄──  4. PR Aç   │          │
│       │                │                    ▲     │          │
│       ▼                ▼                    │     │          │
│  Branch sil     Geri bildirim         Push ──┘    │          │
│                  uygula                           │          │
│                    │                              │          │
│                    └──────── commit ──────────────┘          │
└──────────────────────────────────────────────────────────────┘

Detaylı Adımlar

# 1. Issue'yu al ve branch oluştur
git checkout main
git pull origin main
git checkout -b feature/42-user-auth

# 2. Küçük, anlamlı commit'ler yap
# ... kod yaz ...
git add src/auth/
git commit -m "feat(auth): add login form component"

# ... daha kod yaz ...
git add src/auth/validators.ts
git commit -m "feat(auth): add email validation logic"

# ... test yaz ...
git add tests/auth/
git commit -m "test(auth): add unit tests for login"

# 3. Push et
git push -u origin feature/42-user-auth

# 4. PR oluştur (GitHub CLI ile)
gh pr create \
  --title "feat(auth): add user authentication (#42)" \
  --body "Closes #42" \
  --reviewer teammate1,teammate2

# 5. Review geri bildirimi geldi, düzelt
git add .
git commit -m "fix(auth): address review feedback - add input sanitization"
git push

# 6. Approve aldıktan sonra merge (genelde GitHub UI'dan)
# Squash merge tercih edilirse tüm commit'ler tek commit olur

İletişim Protokolü

Ekip çalışmasında Git teknik bilgisi yetmez — iletişim de önemlidir:

┌─────────────────────────────────────────────┐
│           Ekip İletişim Kuralları            │
├─────────────────────────────────────────────┤
│                                             │
│  🚫 Force push → Ekibi bilgilendir          │
│  🔀 Main'e merge → CI'ın geçtiğinden emin ol│
│  💬 Review iste → Spesifik reviewer belirle  │
│  ⏰ Review yap → 24 saat içinde yanıtla     │
│  🚨 Hotfix → Ekip kanalına bildir           │
│  📦 Release → Changelog paylaş              │
│                                             │
└─────────────────────────────────────────────┘

Squash, Merge, Rebase — PR Merge Stratejileri

GitHub'da bir PR'ı merge ederken üç seçenek vardır. Her birinin farklı bir kullanım senaryosu var:

1. Merge Commit (Create a merge commit)

feature:  A --- B --- C
               /         \
main:    M ------- N ------- Merge Commit --- ...

• Tüm commit'ler korunur

• Merge commit eklenir

• Branch geçmişi tamamen görünür

• Ne zaman: Detaylı geçmiş önemli olduğunda

2. Squash and Merge

feature:  A --- B --- C  (bu commit'ler ezilir)
                            ↓
main:    M --- N --- "feat: user auth (#42)" --- ...

• Tüm PR commit'leri tek commit'e sıkıştırılır

• Temiz, lineer geçmiş

• PR detayları commit mesajında

• Ne zaman: Feature branch'lerde WIP commit'ler varsa (çoğu ekipte varsayılan)

3. Rebase and Merge

feature:  A --- B --- C
                         ↓ (rebase edilir)
main:    M --- N --- A' --- B' --- C' --- ...

• Commit'ler main üzerine yeniden uygulanır

• Merge commit yok, lineer geçmiş

• Her commit korunur ama SHA değişir

• Ne zaman: Her commit anlamlı ve atomik olduğunda

Ekip İçin Önerilen Strateji

Çoğu profesyonel ekip Squash and Merge kullanır çünkü:

# Feature branch'te WIP commit'ler olabilir:
abc1234 wip
def5678 fix typo
ghi9012 actually fix the thing
jkl3456 ok now it really works

# Squash merge sonrası main'de tek temiz commit:
mno7890 feat(auth): add user authentication (#42)

Bu stratejiyi GitHub repository ayarlarından zorunlu kılabilirsiniz:

Repository → Settings → General → Pull Requests
  ☐ Allow merge commits
  ☑ Allow squash merging  (Default)
  ☐ Allow rebase merging

GitHub CLI ile Workflow Otomasyonu

Modern ekip workflow'unun vazgeçilmez aracı GitHub CLI'dır:

# PR listele
gh pr list

# PR oluştur (interaktif)
gh pr create

# PR'ı review et
gh pr review 42 --approve
gh pr review 42 --request-changes --body "Lütfen X'i düzelt"

# PR merge et
gh pr merge 42 --squash --delete-branch

# Issue oluştur
gh issue create --title "Bug: Login timeout" --label "bug"

# Repo klonla
gh repo clone owner/repo

# Workflow çalıştır
gh workflow run deploy.yml

# PR checkout et (review için local'e çekmek)
gh pr checkout 42

💡 İpucu: gh pr checkout 42 komutu, bir PR'ı local'inize çekmenin en hızlı yoludur. Review yaparken kodu çalıştırıp test edebilirsiniz. İnceleme bittikten sonra gh pr review 42 --approve ile onaylayın.

Alias'lar ile Hız Kazanma

Ekip workflow'unda sürekli tekrarlanan komutları kısaltmak zaman kazandırır:

# Sık kullanılan Git alias'ları
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.lg "log --oneline --graph --all --decorate"
git config --global alias.last "log -1 HEAD"
git config --global alias.unstage "restore --staged"

# Günlük workflow alias'ları
git config --global alias.sync '!git checkout main && git pull && git checkout -'
git config --global alias.fresh '!git checkout main && git pull && git checkout -b'
git config --global alias.done '!git push -u origin HEAD && gh pr create --fill'

Kullanımı:

# Yeni feature başlat
git fresh feature/new-dashboard

# ... geliştir, commit et ...

# PR'ı aç
git done

# Ana branch'e sync ol
git sync

Ekip Onboarding Checklist'i

Yeni bir ekip üyesi geldiğinde, Git konusunda şu adımlar izlenmelidir:

## 🚀 Git Onboarding

### İlk Gün
- [ ] Git ve GitHub CLI kurulumu
- [ ] SSH key oluşturma ve GitHub'a ekleme
- [ ] Organization'a davet
- [ ] Repo'yu klonlama
- [ ] Branch protection kurallarını anlama
- [ ] PR template'i inceleme

### İlk Hafta
- [ ] Commit convention öğrenme
- [ ] İlk PR açma (küçük bir görev)
- [ ] İlk code review yapma
- [ ] CI pipeline'ı anlama
- [ ] Ekip workflow'u dökümantasyonu okuma

### İlk Ay
- [ ] Complex PR review
- [ ] Merge conflict çözme
- [ ] Release sürecine katılma
- [ ] Hotfix süreci deneyimi

Gerçek Dünya Senaryosu: Bir Sprint'in Anatomisi

İki haftalık bir sprint'te tipik bir ekip Git workflow'u şöyle işler:

Sprint Başlangıcı (Pazartesi)
│
├── Dev 1: feature/42-user-profile
│   ├── Day 1-2: Geliştirme
│   ├── Day 3: PR açma, Draft
│   ├── Day 4: Review feedback, düzeltme
│   └── Day 5: Approve → Squash Merge
│
├── Dev 2: bugfix/38-cart-total
│   ├── Day 1: Geliştirme + Test
│   ├── Day 2: PR açma, Review
│   └── Day 2: Approve → Squash Merge
│
├── Dev 3: feature/45-notification-system
│   ├── Day 1-3: Geliştirme
│   │   ├── PR #1: DB migration (Day 2 merge)
│   │   ├── PR #2: API endpoints (Day 3 merge)
│   │   └── PR #3: Frontend (Day 5 merge)
│   └── Day 4-5: Review + Fix
│
├── QA: Testing on staging
│   └── Bug bulursa → bugfix branch → PR → merge
│
└── Sprint Sonu (Cuma)
    ├── Release branch oluştur: release/v2.4.0
    ├── Son testler
    ├── Tag: v2.4.0
    └── Deploy to production

Acil Durum: Hotfix

Production'da kritik bug bulundu! Sprint ortasında acil müdahale:

# 1. Hotfix branch'i main'den oluştur
git checkout main
git pull
git checkout -b hotfix/payment-crash

# 2. Düzelt
# ... minimum değişiklik yap ...
git commit -m "fix(payment): handle null response from gateway

The payment gateway occasionally returns null instead of
an error object. Added null check to prevent crash.

Fixes #99"

# 3. Hızlı PR
git push -u origin hotfix/payment-crash
gh pr create --title "🚨 hotfix: payment crash fix" \
  --label "hotfix,urgent" \
  --reviewer senior-dev

# 4. Expedited review (senior dev hemen bakmalı)

# 5. Merge ve deploy
# 6. Hotfix'i develop/main'e de merge et

Yaygın Hatalar ve Çözümleri

1. Main Branch'e Direkt Commit

# ❌ Yanlış — main'e direkt push etmek
git checkout main
git commit -m "feat: new feature"
git push  # Branch protection varsa reddedilir

# ✅ Doğru — her zaman feature branch kullan
git checkout -b feature/new-feature
git commit -m "feat: new feature"
git push -u origin feature/new-feature
# → PR aç → Review → Merge

2. Büyük, Tek Seferde PR

# ❌ Yanlış — 3 haftalık işi tek PR'da göndermek
# 2000+ satır değişiklik, kimse review yapamaz

# ✅ Doğru — küçük, bağımsız PR'lar
# Her PR 100-300 satır arası
# Her PR kendi başına mantıklı ve test edilebilir

3. Güncelliğini Yitirmiş Branch

# ❌ Yanlış — 2 haftadır main'den sync olmamak
# Merge ederken 50 conflict çıkar

# ✅ Doğru — her gün main ile sync ol
git fetch origin
git rebase origin/main
# Küçük conflict'leri erken çözmek, büyük conflict'ten iyidir

4. Commit Mesajı Disiplinsizliği

# ❌ Yanlış
git commit -m "fix"
git commit -m "."
git commit -m "asdfgh"

# ✅ Doğru
# commitlint + husky zorlasın
# PR'da squash merge yapılsa bile, PR başlığı önemlidir

Özet

Bu derste ekip çalışmasının Git boyutunu ele aldık. İşte hatırlanması gereken ana noktalar:

• 🌿 Branch naming convention ekibin ortak dili — type/ticket-description formatını kullanın

• 📝 Conventional Commits (feat, fix, docs...) hem okunabilirlik sağlar hem otomasyon tetikler

• 🔍 PR etiquette — küçük PR'lar, açıklayıcı description, yapıcı review yorumları

• 🔄 Günlük sync — her gün main'den güncelleme alın, conflict'leri erken çözün

• 🤝 İletişim — force push öncesi bilgilendir, review'lara 24 saat içinde yanıt ver

• ⚡ Squash merge — çoğu ekip için en temiz strateji, PR başına tek commit

• 🛡️ Otomasyon — commitlint, PR template, GitHub CLI workflow'u otomatize eder

Bir sonraki derste, Monorepo vs Multi-repo stratejilerini ve büyük projelerin kod organizasyonunu inceleyeceğiz.