Git nedir: sürüm kontrolü ve CSS3 rehberi

Git Nedir ve Sürüm Kontrolü Nasıl Çalışır: Temel Kavramlar ve Avantajları

Git, dağıtık bir sürüm kontrol sistemidir; her geliştiricinin yerel makinesinde projenin tam geçmişini tutması, merkezi bir sunucuya bağımlı kalmadan çalışmayı mümkün kılar. 2005'te Linus Torvalds tarafından Linux çekirdeği geliştirme sürecini hızlandırmak için tasarlanmıştır. Git, dosya değişikliklerini anlık görüntüler (snapshot) olarak kaydeder, bu sayede herhangi bir noktaya anında dönmek mümkün olur. Profesyonel ekiplerde proje yönetiminin temel taşıdır çünkü paralel geliştirme, kod incelemesi ve hata izleme süreçlerini standartlaştırır. Cross-platform çalışma olanağı sunar; Windows, macOS ve Linux üzerinde aynı komut setiyle çalışır. Yapay zeka destekli kod tamamlama araçlarıyla entegre edildiğinde, commit geçmişi analiz edilerek olası hatalar önceden tespit edilebilir. Performans optimizasyonu açısından delta sıkıştırma ve içerik adreslenebilir depolama kullanarak büyük projelerde bile hızlı işlem yapar.

Temel Komutlar: Commit, Push, Pull Nasıl Kullanılır

Git'in günlük kullanımı üç temel komut üzerine kuruludur: commit, push ve pull. git add ile hazırlama alanına (staging area) alınan değişiklikler, git commit ile yerel depoya kaydedilir. Her commit benzersiz bir hash (SHA-1) ile tanımlanır ve değişmez. git push origin main komutu yerel commit'leri uzak depoya (remote) gönderirken, git pull origin main uzak depodaki güncellemeleri yerel çalışma alanına çeker. Agile süreçlerde günlük stand-up toplantılarından önce pull almak, takım arkadaşlarının değişiklikleriyle çakışmamak için kritik bir alışkanlıktır. Test edilebilirlik açısından her commit'in küçük ve atomik olması gerekir; böylece bir hata durumunda sadece ilgili commit geri alınabilir. CI/CD pipeline'ları genellikle her push işleminde otomatik testleri tetikler, bu yüzden push öncesi yerel test çalıştırma alışkanlığı edinilmelidir.

Commit Mesajı Yazma Standartları ve Örnekleri

İyi bir commit mesajı, kodun neden değiştiğini açıklar, neyin değiştiğini değil. Conventional Commits spesifikasyonu sektörde yaygın olarak benimsenmiştir: feat:, fix:, docs:, style:, refactor:, test:, chore: önekleri kullanılır. Mesaj 50 karakterlik özeti ve isteğe bağlı 72 karakterlik gövdeyi içermelidir. Örneğin: feat(api): add JWT authentication middleware veya fix(e-ticaret): resolve cart total calculation on discount apply. Profesyonel ekiplerde tutarlı commit mesajları, otomatik changelog oluşturma ve semantic versioning (semver) için zorunludur. Kullanıcı deneyimi iyileştirmeleri içeren commit'lerde ux: öneki kullanılabilir. Mobil uygulama geliştirmede platform belirtmek için feat(ios): veya fix(android): gibi kapsamlı etiketler tercih edilir.

Remote Ekleme, Push/Pull Çatışma Çözümü Nasıl Kullanılır

Birden fazla uzak depo ile çalışmak için git remote add upstream https://github.com/orijinal/repo.git komutu kullanılır. git remote -v mevcut remoteleri listeler. Push/pull çatışmaları genellikle iki geliştirici aynı dosyanın aynı satırlarını değiştirdiğinde ortaya çıkar. Çatışma çözümü adımları: önce git pull ile uzak değişiklikleri al, çatışma işaretçilerini (<<<<<<<, =======, >>>>>>>) düzenle, git add . ve git commit ile çözümü kaydet. SaaS projelerinde canlı ortama hızlı düzeltme göndermek gerektiğinde, git push --force-with-lease kullanımı daha güvenlidir; uzak dalın beklenmedik şekilde güncellenip güncellenmediğini kontrol eder. Cross-platform ekiplerde satır sonu karakterleri (CRLF/LF) nedeniyle çatışma yaşanmaması için git config core.autocrlf true ayarı yapılmalıdır.

Stash, Reset ve Revert ile Hata Geri Alma Senaryoları

git stash anlık değişiklikleri geçici olarak saklar; git stash push -m "wip: login form validation" ile isimlendirilmiş stash oluşturulabilir. git stash pop en son stash'i uygular ve listeden siler. git reset --soft HEAD~1 son commit'i geri alır ama değişiklikleri hazırlama alanında bırakır; --hard ise tüm değişiklikleri siler. git revert HEAD ise yeni bir commit oluşturarak değişikliği geri alır, bu yüzden paylaşılmış dallarda güvenlidir. E-ticaret projelerinde kritik bir hata tespit edildiğinde git revert kullanmak, geçmişi bozmadan hızlıca eski sürüme dönmeyi sağlar. API endpoint'lerinde yapılan hatalı bir değişiklik için:

git log --oneline -5
git revert a1b2c3d
git push origin main

Geçmiş ve Görselleştirme: Log, Diff ve Grafik Araçları

Git'in en güçlü yanlarından biri, proje geçmişini çeşitli formatlarda inceleme olanağı sunmasıdır. git log komutu sadece commit listesi değil, projenin evrimini anlamak için bir araçtır. Profesyonel ekiplerde kod incelemesi (code review) öncesi ilgili commit'leri incelemek, değişikliğin bağlamını kavramak açısından kritiktir. Performans optimizasyonu çalışmalarında hangi commit'lerin ne zaman eklendiğini görmek, regresyon analizi yapmayı kolaylaştırır. Agile metodolojide sprint retrospektiflerinde commit aktivitesi, takımın iş akışını değerlendirmek için kullanılabilir.

Git Log Formatları, --graph ve Kısa Özet Örnekleri

git log --oneline --graph --decorate --all komutu, tüm dalların birleşme noktalarını ASCII grafik olarak gösterir. Daha okunabilir formatlar için: git log --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short. Mobil uygulama geliştirmede feature branch'lerin main'e nasıl entegre edildiğini görsel olarak takip etmek, branch stratejisinin doğru uygulanıp uygulanmadığını kontrol eder. Kullanıcı deneyimi geliştirmeleri içeren commit'leri filtrelemek için git log --grep="ux:" --oneline kullanılabilir. CI/CD entegrasyonunda deployment öncesi son commit'leri hızlıca kontrol etmek için alias tanımlamak faydalıdır:

git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

Diff, Blame ve Patch ile Değişiklik İnceleme Teknikleri

git diff HEAD~1 HEAD son commit'teki değişiklikleri gösterir. git diff --cached hazırlama alanındaki değişiklikleri karşılaştırır. git blame -L 10,20 dosya.js belirli satırların kim tarafından ne zaman değiştirildiğini gösterir; hata ayıklamada vazgeçilmezdir. git format-patch -1 HEAD son commit'i e-posta patch'i olarak oluşturur; açık kaynak projelerde yaygın kullanılır. Test edilebilirlik açısından git diff çıktısını inceleyerek yanlışlıkla commitlenmemesi gereken dosyaların (örneğin API anahtarları, .env dosyaları) staging alanına alınıp alınmadığı kontrol edilmelidir. Cross-platform geliştirmede git diff --ignore-space-at-eol satır sonu farklarını görmezden gelerek gerçek değişiklikleri odaklanmayı sağlar.

Commit Görselleştirme İçin GUI ve CLI Araç Karşılaştırmaları

CLI araçlar hızlı ve scriptlenebilirken, GUI araçlar dallanma ve birleşme yapısını daha iyi görselleştirir. GitKraken, SourceTree ve GitHub Desktop popüler GUI seçenekleridir. Sektörde büyük projelerde GitKraken'in merge conflict çözüm arayüzü tercih edilirken, hızlı operasyonlar için CLI kullanılır. IDE entegrasyonları (VS Code, IntelliJ) hem CLI'nin hızını hem de GUI'nin görselleştirmesini bir arada sunar. Yapay zeka destekli araçlar (örneğin GitHub Copilot) commit mesajı önerileri ve kod incelemesi yaparak geliştirici deneyimini iyileştirir. Monorepo yapılarında GUI araçlar binlerce commit arasında gezinmeyi kolaylaştırır.

Branch Stratejileri ve Yerleşim: Feature, Release, Hotfix Örnekleri

Branch stratejileri, paralel geliştirme ve sürüm yönetiminin iskeletidir. Her strateji, projenin ölçeğine, takım yapısına ve release sıklığına göre seçilmelidir. E-ticaret projelerinde canlı ortamdaki kritik hataların hızla düzeltilmesi gerektiği için hotfix branch'leri zorunludur. SaaS uygulamalarında sürekli deployment (CD) yapıldığından, trunk-based workflow daha yaygındır. Profesyonel ekiplerde branch isimlendirme konvansiyonları (feature/TICKET-123-login-page, hotfix/v2.1.1-payment-bug) Jira gibi araçlarla entegre çalışır. Kullanıcı deneyimi iyileştirmeleri genellikle feature branch'lerinde geliştirilir, A/B test sonuçlarına göre main'e alınır.

Branch Oluşturma, Checkout ve Merge Akışları

Yeni feature branch'i oluşturmak için: git checkout -b feature/user-profile. Main dalındaki güncellemeleri feature branch'e entegre etmek için önce git checkout feature/user-profile, sonra git merge main veya git rebase main kullanılır. Merge sonrası gereksiz branch'leri silmek için git branch -d feature/user-profile (güvenli silme) veya git branch -D feature/user-profile (zorla silme). API geliştirmede versiyonlama branch'leri (api/v1, api/v2) kullanarak geriye dönük uyumluluk sağlanabilir. Responsive tasarım çalışmalarında mobil ve desktop değişiklikleri ayrı branch'lerde tutulup, test edildikten sonra birleştirilir:

git checkout -b feature/responsive-header
git add .
git commit -m "feat(ui): implement responsive navigation"
git checkout main
git merge feature/responsive-header

Git Flow, GitHub Flow ve Trunk-Based Workflow Karşılaştırması

Git Flow: main, develop, feature/*, release/*, hotfix/* dallarından oluşur. Düzenli release döngüsü olan projeler için uygundur. E-ticaret ve mobil uygulama geliştirmede yaygındır çünkü app store gönderimleri planlı release gerektirir.

GitHub Flow: Sadece main ve feature/* dalları vardır. Her feature tamamlandığında pull request açılır, review sonrası main'e merge edilir. SaaS ve web projelerinde tercih edilir; sürekli deployment ile uyumludur.

Trunk-Based Development: Tüm geliştiriciler main (trunk) üzerinde çalışır, feature branch'ler çok kısa ömürlüdür (maksimum birkaç saat/gün). Performans optimizasyonu gerektiren büyük ölçekli projelerde (Google, Facebook) kullanılır. Feature flag'ler ile tamamlanmamış özellikler canlıda gizli tutulur.

Protected Branch, Branch Politikaları ve Erişim Kontrolleri

GitHub ve GitLab'da main ve release/* dalları korunabilir (protected). Kurallar: doğrudan push yapılamaz, pull request/merge request zorunludur, en az bir onay (approval) gerekir, CI testleri geçmelidir. Sektörde güvenlik açısından force push ve branch silme işlemleri kısıtlanır. API endpoint'lerini değiştiren kritik commit'ler için ek güvenlik onayı (CODEOWNERS dosyası ile) ayarlanabilir. E-ticaret projelerinde ödeme modülü değişiklikleri için finans ekibi onayı zorunlu tutulabilir. Test edilebilirlik politikası kapsamında, coverage düşüşüne izin verilmeyen branch korumaları kurulur:

# GitHub CLI ile branch koruması
gh api repos/OWNER/REPO/branches/main/protection \
  --method PUT \
  --input - <<< '{"required_status_checks":{"strict":true,"contexts":["ci/tests"]},"enforce_admins":true,"required_pull_request_reviews":{"required_approving_review_count":1},"restrictions":null}'

Gelişmiş Sürüm Kontrolü: Rebase, Cherry-Pick ve Submodule Kullanımı

İleri seviye Git komutları, temiz ve anlaşılır bir commit geçmişi oluşturmayı sağlar. Profesyonel ekiplerde dağınık commit geçmişi yerine lineer, okunabilir bir history tercih edilir. Bu, hata ayıklamada git bisect kullanımını ve otomatik araçların geçmişi analiz etmesini kolaylaştırır. Cross-platform kütüphane geliştirmede submodule ve subtree ile bağımlılıkları yönetmek, projelerin bağımsız evrimini mümkün kılar. Yapay zeka destekli kod analiz araçları, rebase sırasında çatışma olasılığını önceden tahmin edebilir.

Rebase vs Merge Karar Kriterleri ve Çatışma Çözümü Örnekleri

git rebase main feature branch'ini main'in en güncel hali üzerine yeniden yazar; lineer geçmiş sağlar. git merge main ise birleşme commit'i oluşturur, branch geçmişini korur. Rebase tercih edilir: yerel, henüz paylaşılmamış feature branch'lerde; pull request öncesi history temizlemek için (interactive rebase: git rebase -i HEAD~3). Merge tercih edilir: paylaşılmış dallarda (rebase commit hash'lerini değiştirir); release branch'lerini main'e entegre ederken. Çatışma çözümü rebase sırasında adım adım yapılır; her commit için çatışma çözülüp git rebase --continue ile devam edilir. E-ticaret sepet modülünde yapılan değişikliklerin rebase edilmesi:

git checkout feature/cart-discount
git rebase -i main
# Çatışma çözümü
git add src/cart.js
git rebase --continue

Submodule ve Subtree ile Bağımlılık Yönetimi Nasıl Yapılır

Submodule: Harici depoyu belirli bir commit'e sabitler. git submodule add https://github.com/kutuphane/ortak.git libs/ortak ile eklenir. Ana proje ve bağımlılık bağımsız versiyonlanır. Dezavantajı: submodule güncellemeleri ayrı adımlar gerektirir, yeni geliştiriciler için öğrenme eğrisi vardır.

Subtree: Bağımlılığı ana projenin bir dizini olarak entegre eder. git subtree add --prefix=libs/ortak https://github.com/kutuphane/ortak.git main --squash ile eklenir. Tek depo yönetimi kolaydır, ancak bağımlılığın geçmişi ana depoya karışır.

Monorepo stratejilerinde subtree, paylaşılan kütüphaneleri yönetmek için tercih edilirken; bağımsız olarak geliştirilen API client'ları için submodule daha uygundur. CI/CD pipeline'larında submodule'lerin otomatik olarak çekilmesi için git submodule update --init --recursive adımı eklenmelidir.

Cherry-Pick, Bisect ve Etiketleme (Tag) Pratikleri

git cherry-pick a1b2c3d belirli bir commit'i başka bir dala uygular; hotfix'lerin release branch'lerine taşınmasında kullanılır. git bisect start, git bisect bad, git bisect good v1.2.0 ile ikili arama yaparak hatanın hangi commit'te ortaya çıktığı bulunur. Performans optimizasyonu regresyonlarını tespit etmek için idealdir. Etiketleme (tag) semantic versioning'e uygun yapılır: git tag -a v2.1.0 -m "Release version 2.1.0". E-ticaret projelerinde her canlıya alınan sürüm tag'lenir, rollback gerektiğinde git checkout v2.0.1 ile hızlıca dönülür. Mobil uygulama store gönderimleri tag ile ilişkilendirilir:

git tag -a v3.0.0 -m "feat: add AI-powered product recommendations"
git push origin v3.0.0

Performans ve Büyük Depo Yönetimi: LFS, Shallow Clone ve Monorepo Stratejileri

Büyük ölçekli projelerde Git'in varsayılan davranışları yetersiz kalabilir. Görseller, videolar, derlenmiş dosyalar ve uzun geçmişli depolar performans sorunlarına yol açar. Profesyonel ekiplerde bu sorunları çözmek için özel araçlar ve stratejiler geliştirilmiştir. Cross-platform oyun geliştirmede veya yapay zeka modelleriyle çalışan projelerde gigabaytlık dosyalar sıklıkla görülür. Kullanıcı deneyimi tasarım süreçlerinde Figma export'ları, yüksek çözünürlüklü asset'ler versiyonlanmalıdır. Test edilebilirlik için büyük test veri setlerinin (fixtures) depoda tutulması gerekebilir.

Git LFS ile Büyük Dosya Yönetimi ve Kullanım Örnekleri

Git Large File Storage (LFS), büyük dosyaların içeriğini ayrı bir sunucuda tutarak depoyu hafifletir. Kurulum: git lfs install, takip edilecek dosyaları belirtme: git lfs track "*.psd". .gitattributes dosyası otomatik oluşturulur. E-ticaret projelerinde ürün görselleri, SaaS uygulamalarında eğitim videoları LFS ile yönetilir. CI/CD pipeline'larında git lfs pull adımı eklenmelidir. Maliyet optimizasyonu için LFS bandwith limitleri göz önünde bulundurulmalıdır:

git lfs track "*.zip" "*.mov" "assets/models/*.fbx"
git add .gitattributes
git commit -m "chore: track large assets with LFS"

Shallow Clone, Fetch Optimizasyonu ve Ağ Maliyeti Azaltma

git clone --depth 1 https://github.com/proje/repo.git sadece son commit'i indirir; CI/CD pipeline'larında build süresini %90'a varan oranda kısaltır. git fetch --depth 1 origin main belirli bir dalın güncel halini çeker. git clone --filter=blob:none --no-checkout ile tree-only clone yapılabilir; dosya içerikleri ihtiyaç halinde lazy loading ile çekilir. Monorepo araçları (Nx, Turborepo, Bazel) ile büyük depolarda sadece değişen paketlerin bağımlılıkları indirilir. Ağ maliyeti azaltma stratejileri: git config --global core.compression 9 (maksimum sıkıştırma), git config --global http.postBuffer 524288000 (büyük push'lar için buffer artırma). Mobil uygulama geliştirmede CI runner'ların her build'de sıfırdan clone yapması yerine cache kullanması kritiktir:

# CI'de shallow clone
git clone --depth 1 --branch $BRANCH_NAME $REPO_URL .
git fetch --depth 1 origin $COMMIT_SHA
git checkout $COMMIT_SHA

Monorepo Araçları, Subrepo ve Paket Sınırlandırma Teknikleri

Monorepo'da birden fazla proje/uygulama tek depoda tutulur. Nx: Angular ekosisteminden çıkmış, bağımlılık grafiği analizi ve etkilenen projelerin akıllıca build/test edilmesini sağlar. Turborepo: Vercel tarafından geliştirilmiş, remote caching ile build sürelerini minimize eder. Bazel: Google'ın build sistemi, herkesin aynı sonucu almasını garanti eden (hermetic) build'ler sunar. Paket sınırlandırma: her uygulama/kitaplık kendi package.json ve bağımlılıklarını tutar, paylaşılan kodlar internal paketlere çıkarılır. API ve frontend aynı depoda tutularak versiyon uyumsuzluğu riski azaltılır. Sektörde mikro-frontend mimarilerinde monorepo, tutarlı UI/UX bileşenleri geliştirmek için tercih edilir.

Uyumluluk ve Entegrasyon: CI/CD, Hooks ve Otomasyon Senaryoları

Git, modern yazılım geliştirme yaşam döngüsünün merkezinde yer alır. CI/CD pipeline'ları, kod kalitesi kontrolleri ve otomasyon senaryoları Git olayları üzerine kuruludur. Profesyonel ekiplerde manuel adımların minimize edilmesi, hata oranını düşürür ve teslimat hızını artırır. Agile süreçlerde her commit'in otomatik olarak test edilmesi, "broke the build" kültürünü önler. Cross-platform geliştirmede farklı işletim sistemlerinde tutarlı davranış sağlamak için hook'lar ve CI script'leri standartlaştırılır. Yapay zeka destekli araçlar, kod incelemesi ve güvenlik taramasını otomatikleştirir.

Pre-Commit, Pre-Push Hook Örnekleri ve Kod Kalitesi Kontrolleri

Git hook'ları, belirli olaylar öncesinde/sonrasında çalışan script'lerdir. .git/hooks/pre-commit dosyasına yerleştirilir (takım için paylaşılması için Husky kullanılır). Pre-commit hook örneği: lint, format ve test kontrolü. Pre-push hook: uzak repoya göndermeden önce entegrasyon testlerini çalıştırır. E-ticaret projelerinde ödeme modülü değişiklikleri öncesi güvenlik taraması (secrets detection) zorunlu tutulabilir. Test edilebilirlik garantisi için coverage eşiği konulabilir. Husky + lint-staged yapılandırması:

# package.json
{
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged",
      "pre-push": "npm run test:ci"
    }
  },
  "lint-staged": {
    "*.{js,ts}": ["eslint --fix", "prettier --write", "git add"]
  }
}

CI Pipeline Tetikleme, Merge Request Onayları ve Otomatik Test Entegrasyonu

GitHub Actions, GitLab CI, CircleCI gibi araçlar Git olaylarına (push, pull request, tag) yanıt olarak pipeline çalıştırır. .github/workflows/ci.yml dosyası ile yapılandırılır. Pipeline aşamaları: install dependencies → lint → unit tests → build → integration tests → deploy (staging/production). Merge request onayları: en az bir reviewer onayı, tüm CI check'lerinin geçmesi, branch güncel olma zorunluluğu. Otomatik test entegrasyonu: Jest, Cypress, Playwright gibi araçlar CI'de headless modda çalıştırılır. SaaS projelerinde her pull request için otomatik olarak preview environment (Vercel, Netlify Deploy Preview) oluşturulur. Performans optimizasyonu için Lighthouse CI ile her PR'de performans skoru kontrolü yapılır. Mobil uygulama geliştirmede EAS Build (Expo) ile otomatik binary oluşturma:

# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm ci
      - run: npm run lint
      - run: npm run test:coverage
      - run: npm run build

Webhook, API ve Üçüncü Taraf Entegrasyonları ile İş Akışı Otomasyonu

GitHub/GitLab webhook'ları, depo olaylarını (push, PR oluşturma, merge) harici sistemlere bildirir. Slack/Discord entegrasyonu: build hataları ve deployment bildirimleri otomatik olarak kanala düşer. Jira entegrasyonu: commit mesajlarındaki TICKET-123 referansları otomatik olarak ilgili issue'ya bağlanır. API entegrasyonları: GitHub REST/GraphQL API ile özel dashboard'lar oluşturulabilir, contributor istatistikleri çekilebilir. Yapay zeka destekli code review bot'ları (CodeRabbit, PR-Agent) otomatik yorumlar ve iyileştirme önerileri sunar. E-ticaret projelerinde deployment sonrası otomatik smoke test ve monitoring alert entegrasyonu kurulur. Kullanıcı deneyimi araştırma süreçlerinde Figma webhook'ları ile tasarım değişiklikleri takım kanalına düşer:

# GitHub webhook oluşturma (API)
curl -X POST \
  -H "Authorization: token $GITHUB_TOKEN" \
  -H "Accept: application/vnd.github.v3+json" \
  https://api.github.com/repos/OWNER/REPO/hooks \
  -d '{"config":{"url":"https://monitoring.noves.digital/webhook","content_type":"json"},"events":["push","pull_request"]}'

Uygulama Senaryoları: Web Geliştirme, E-Ticaret, SaaS, Responsive Tasarım ve UI/UX Projeleri İçin Pratikler

Git kullanımı proje türüne göre farklılık gösterir. Her alanın kendine özgü versiyonlama, deployment ve iş akışı ihtiyaçları vardır. Profesyonel ekiplerde bu farklılıkların bilinmesi ve doğru stratejinin seçilmesi, projenin sürdürülebilirliğini doğrudan etkiler. Cross-platform uyumluluk, performans optimizasyonu ve kullanıcı deneyimi her projede farklı şekillerde ele alınır. Agile metodolojinin uygulanması, sprint planlaması ve release yönetimi proje karakteristiğine göre şekillenir. Test edilebilirlik ve CI/CD entegrasyonu da bu senaryolara göre özelleştirilir.

Web Geliştirme İçin Modüler Repo Yapısı ve Deployment Örnekleri

Modern web projelerinde modüler mimari (micro-frontends, feature-based folder structure) Git repo yapısına yansıtılır. Her feature kendi dizininde, bağımsız test ve story dosyalarıyla tutulur. Monorepo (Nx, Turborepo) veya polyrepo (her servis ayrı depo) tercihi ekip büyüklüğüne göre yapılır. Deployment stratejileri: Vercel/Netlify (Jamstack), Docker + Kubernetes (containerized), AWS/GCP (serverless). Blue-green deployment: yeni sürüm paralel olarak ayağa kaldırılır, trafik anında yönlendirilir; rollback anlıktır. API gateway yapılandırmaları versiyonlanır, backward compatibility sağlanır. Responsive tasarım değişiklikleri ayrı branch'lerde geliştirilir, cihaz testleri tamamlanınca merge edilir. CI/CD pipeline'ı:

# Deployment script örneği
npm run build:production
docker build -t web-app:$GIT_COMMIT .
docker push registry/web-app:$GIT_COMMIT
kubectl set image deployment/web-app web-app=registry/web-app:$GIT_COMMIT

E-Ticaret Projelerinde Sürümleme, Ürün İçerik Yönetimi ve Rollback Stratejileri

E-ticaret sitelerinde canlı ortamda kesinti maliyeti yüksektir; bu yüzden versiyonlama ve rollback kritiktir. Ürün içerik yönetimi (PIM) entegrasyonları: ürün görselleri, açıklamaları ve fiyatları Git ile versiyonlanabilir (JSON/YAML formatında) veya headless CMS kullanılır. Feature flag'ler: yeni ödeme yöntemi, kampanya modülü canlıda kapatılıp açılabilir; deployment sıklığı artırılır. Rollback stratejileri: database migration'lar geri alınabilir olmalı (down migration), eski uygulama sürümüne anında dönülebilmeli. Mavi-yeşil deployment veya canary release: yeni sürüm %5 trafiğe çıkarılır, hata oranı izlenir. Black Friday gibi yüksek trafik dönemlerinde code freeze uygulanır; sadece hotfix merge edilir. Performans optimizasyonu için CDN cache invalidation stratejileri versiyonlanır. Yapay zeka destekli ürün öneri sistemleri A/B test branch'lerinde geliştirilir:

# Rollback script
git tag -a rollback-$(date +%Y%m%d-%H%M%S) -m "Emergency rollback point"
git revert HEAD~2..HEAD  # Son 2 commit'i geri al
git push origin main
# Veritabanı rollback
npm run db:migrate:down

SaaS ve UI/UX Projelerinde Tema Branching, A/B Testleri ve Responsive Tasarım Entegrasyonu

SaaS uygulamalarında çok tenant'lı (multi-tenant) yapıda her müşteri için özelleştirme gerekebilir. Tema branching: theme/enterprise-dark, theme/startup-light gibi branch'lerde UI temaları geliştirilir, ana uygulamaya merge edilir. A/B testleri: experiment/new-checkout-flow branch'i canlıda %10 kullanıcıya gösterilir, conversion metrikleri izlenir. Kullanıcı deneyimi iyileştirmeleri: heatmap ve session replay verilerine göre branch oluşturulur, geliştirme yapılır. Responsive tasarım: mobil öncelikli (mobile-first) yaklaşımla feature/mobile-nav branch'inde geliştirme, desktop'ta test edilip main'e alınır. Design system (Storybook) bileşenleri ayrı bir paket/monorepo'da versiyonlanır, tüm uygulamalarda kullanılır. Cross-platform tutarlılık: iOS, Android ve web'de aynı bileşenlerin davranışını sağlamak için design token'lar Git'te versiyonlanır. CI/CD'de visual regression testleri (Chromatic, Percy) ile her PR'de UI değişiklikleri otomatik olarak görsel olarak karşılaştırılır:

# Tema branch yönetimi
git checkout -b theme/enterprise
# Tema değişkenlerini güncelle
git add src/styles/theme.css
git commit -m "feat(theme): add enterprise color palette"
git checkout main
git merge theme/enterprise --no-ff

Araçlar ve İş Akışları: CLI, GUI, GitHub, GitLab ve Yerel Entegrasyonlar

Verimli Git kullanımı, doğru araçların seçimi ve kişiselleştirilmiş iş akışlarıyla mümkün olur. Her geliştiricinin tercih ettiği araç farklı olsa da, takım içinde tutarlılık sağlanmalıdır. Profesyonel ekiplerde Git yapılandırması, alias'lar ve credential yönetimi standartlaştırılır. IDE entegrasyonları, context switching'i azaltarak verimliliği artırır. Sektörde GitHub ve GitLab en yaygın platformlardır; her ikisinin de güçlü CI/CD, code review ve proje yönetimi özellikleri vardır. Cross-platform geliştirmede aynı .gitconfig dosyasının tüm makinelerde kullanılması tutarlılık sağlar.

Komut Satırı ile Verimli Çalışma: Alias, Config ve Credential Yönetimi

Git alias'ları uzun komutları kısaltır: git config --global alias.co checkout, git config --global alias.br branch, git config --global alias.ci commit, git config --global alias.st status. Güçlü alias örnekleri: git config --global alias.unstage 'reset HEAD --', git config --global alias.last 'log -1 HEAD'. Global yapılandırma: git config --global user.name "Ad Soyad", git config --global user.email "email@noves.digital". Credential yönetimi: git config --global credential.helper cache (bellekte geçici), git config --global credential.helper store (dosyada kalıcı, güvenli değil), SSH key kullanımı (önerilen). Çoklu hesap yönetimi (iş/kişisel): SSH config ile farklı key'ler atanır. Performans optimizasyonu için git config --global core.fsmonitor true (büyük depolarda dosya izleme hızlandırma). E-ticaret projelerinde sık kullanılan komutlar için proje-spesifik alias'lar tanımlanabilir:

# ~/.gitconfig örneği
[alias]
    lg = log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit
    undo = reset HEAD~1 --mixed
    amend = commit --amend --no-edit
    cleanup = "!git branch --merged | grep -v '\\*' | xargs -n 1 git branch -d"
[core]
    editor = code --wait
    autocrlf = input
[credential]
    helper = cache --timeout=3600

GitHub/GitLab Merge Request, Code Review ve CI Ayarları Örnekleri

GitHub Pull Request: feat: add payment gateway başlıklı PR açılır, şablon (.github/pull_request_template.md) otomatik doldurulur. Reviewer atama, label ekleme (feature, bug, urgent), project board bağlama. CI check'ler (GitHub Actions) PR'de görünür, başarısız olursa merge engellenir. GitLab Merge Request: benzer akış, .gitlab/merge_request_templates/ dizininde şablonlar tutulur. Approval rules: belirli dosyalara (örneğin src/payment/*) dokunulduğunda finans ekibi onayı zorunlu. Code review best practices: küçük PR'ler (maksimum 400 satır), açıklayıcı açıklama, screenshot/gif ekleme (UI değişikliklerinde). Otomatik merge: tüm check'ler geçtiğinde ve gerekli onaylar alındığında automerge label'ı ile otomatik birleştirme. Test edilebilirlik için PR açıklamasında test adımları ve edge case'ler belirtilmelidir. API değişikliklerinde OpenAPI şema güncellemesi ve backward compatibility kontrolü zorunludur. Mobil uygulama geliştirmede her PR'de screenshot karşılaştırma otomatik olarak yapılır:

<!-- .github/pull_request_template.md -->
## Açıklama
<!-- Değişikliğin nedenini ve neyi çözdüğünü açıkla -->

## Test Adımları
1. 
2. 

## Ekran Görüntüleri (UI değişiklikleri için)
<!-- Before/After -->

## Checklist
- [ ] Unit testler eklendi/güncellendi
- [ ] Lint hatası yok
- [ ] API dokümantasyonu güncellendi (varsa)

IDE Entegrasyonları, GUI İstemciler ve Görsel Çatışma Çözüm Araçları

IDE Entegrasyonları: VS Code (GitLens eklentisi), IntelliJ IDEA (yerleşik Git araçları), Visual Studio. IDE içinden blame, diff, stash yönetimi, conflict çözümü yapılabilir. GitLens ile satır satır commit bilgisi görünür, hover ile detaylara erişilir. GUI İstemciler: GitKraken (cross-platform, güçlü merge aracı), SourceTree (Atlassian, ücretsiz), Tower (macOS/Windows, ücretli). Görsel Çatışma Çözümü: Beyond Compare, Kaleidoscope, IDE'nin built-in merge aracı. Three-way merge görünümü (yours, base, theirs) çatışmaları anlamayı kolaylaştırır. Profesyonel ekiplerde çatışma çözümü eğitimi verilir; "theirs" veya "ours" stratejisi bilinçli seçilir. Yapay zeka destekli merge araçları (GitHub Copilot, Codeium) çatışma çözümünde öneriler sunar. Responsive tasarım projelerinde Figma'nın Git eklentileri ile tasarım versiyonlaması yapılabilir.

Sonuç ve Uygulama Rehberi: Proje Başlangıcından Üretime Kadar Sürüm Kontrolü Stratejileri

Git ve sürüm kontrolü, yazılım geliştirme sürecinin ayrılmaz bir parçasıdır. Temel komutlardan ileri seviye stratejilere kadar uzanan bu yolculukta, projenin ihtiyaçlarına uygun araç ve yöntemleri seçmek başarının anahtarıdır. Profesyonel ekiplerde Git kullanımı sadece teknik bir beceri değil, aynı zamanda iş birliği ve iletişim kültürüdür. Agile prensiplerle uyumlu, test edilebilir ve otomasyona açık bir Git iş akışı, ürün kalitesini ve teslimat hızını doğrudan etkiler. Noves Digital olarak gözlemlediğimiz en başarılı projeler, Git'i sadece kod saklama aracı olarak değil, proje yönetiminin merkezine yerleştiren ekipler tarafından geliştirilmiştir.

Proje Başlangıcı Checklist: .gitignore, Branching Politikası ve CI Kurulumu

Yeni projeye başlarken atılması gereken adımlar:

Repo oluşturma: git init veya GitHub/GitLab üzerinden boş repo oluşturma

.gitignore: Proje tipine uygun template (Node, Python, Rails, vb.) kullanma; .env, node_modules, build çıktıları, IDE dosyalarını hariç tutma

README.md: Proje açıklaması, kurulum adımları, contribution guidelines

Branching politikası: Git Flow, GitHub Flow veya Trunk-Based seçimi; protected branch kuralları

CI/CD kurulumu: GitHub Actions veya GitLab CI ile lint, test, build adımları

Pre-commit hooks: Husky + lint-staged ile kod kalitesi garantisi

Semantic versioning: Tag stratejisi ve changelog yönetimi

Access control: CODEOWNERS dosyası ile kritik dosya/dizin sahipliği

# Başlangıç komutları
git init
curl -o .gitignore https://raw.githubusercontent.com/github/gitignore/main/Node.gitignore
git add README.md .gitignore
git commit -m "chore: initial commit with project setup"
git branch -M main
git remote add origin https://github.com/kullanici/proje.git
git push -u origin main

Bakım ve Ölçeklendirme: Performans İzleme, Güvenlik ve Sürümleme Taktikleri

Proje büyüdükçe Git stratejisinin de evrimi gerekir:

Performans izleme: Büyük depolarda git gc (garbage collection) düzenli çalıştırma, LFS kullanımı, shallow clone stratejileri. CI build sürelerini monitör etme, cache optimizasyonu.

Güvenlik: git-secrets veya truffleHog ile API anahtarı/sifre leak kontrolü. Dependency scanning (Dependabot, Snyk) ile güvenlik açığı takibi. Signed commit'ler (GPG) ile commit sahipliği doğrulama.

Sürümleme taktikleri: Semantic versioning (MAJOR.MINOR.PATCH) disiplini. Feature flag'ler ile sürekli deployment. Canary release ve A/B test entegrasyonu. Database migration stratejisi (backward compatible migration'lar).

Ölçeklendirme: Monorepo araçları (Nx, Turborepo) ile büyük kod tabanı yönetimi. Micro-frontend/micro-servis yapısında repo organizasyonu (monorepo vs polyrepo kararı).

Dokümantasyon: Architecture Decision Records (ADR) olarak Git'te tutma. Runbook'lar ve operasyon prosedürlerinin versiyonlanması.

Agile süreçlerde düzenli retrospektiflerde Git iş akışı da değerlendirilmeli; "commit sıklığı yeterli mi?", "PR merge süresi ne kadar?", "rollback ne kadar sürdü?" gibi metrikler takip edilmelidir. Cross-platform projelerde Git yapılandırması standartlaştırılmalı, yeni ekip üyeleri için onboarding dokümantasyonu güncel tutulmalıdır. Test edilebilirlik, performans optimizasyonu ve kullanıcı deneyimi odaklı geliştirme, sağlam bir Git altyapısı üzerine inşa edilir. CI/CD pipeline'larının sağlığı, deployment güvenliği ve otomasyon seviyesi, projenin olgunluğunun göstergesidir.