Her Ekibin Kullandığı Git Akışı: Clone'dan Merge'e

Profesyonel yazılım geliştirme süreçlerinde Git, sadece bir sürüm kontrol aracı değildir. Ekip içi koordinasyonun ve işbirliğinin ana mekanizmasıdır. Temiz ve öngörülebilir bir Git geçmişi; sürekli teslimatı (continuous delivery) kolaylaştırır, hata ayıklama süreçlerini hızlandırır ve kod tabanının bakımını basitleştirir.

Buna karşın, "hata düzeltildi", "yedek" gibi belirsiz commit mesajlarıyla dolu, devasa boyutlarda Pull Request'ler içeren ve iç içe geçmiş karmaşık merge commit'lerinden oluşan bir Git geçmişi, geliştirme ekibinin hızını doğrudan düşürür.

Bu kılavuz, modern mühendislik ekipleri tarafından kullanılan ileri düzey Git ve GitHub iş akışını, klonlama adımından birleştirme adımına kadar detaylandırmaktadır.

---

1. İşin Mutfağı: Git'in Üç Temel Alanı

Git iş akışlarında uzmanlaşmak için değişikliklerin nasıl takip edildiğini anlamak gerekir. Dosya farklarını (diff) saklayan geleneksel sistemlerin aksine Git, dosya sisteminizin anlık görüntülerini (snapshot) üç ana alanda yönetir:

[ Çalışma Dizini ]    --->  (Sahne / Index)  ---> [ Yerel Depo ]
  (Working Directory)       (git add)             (git commit)

1. Çalışma Dizini (Working Directory): Dosyaları düzenlediğiniz yerel alan. Buradaki dosyalar henüz takip edilmiyor (untracked) ya da değiştirilmiş (modified) durumdadır.
2. Hazırlık Alanı / Sahne (Staging Area - Index): Bir nevi taslak alanı. Bir sonraki commit'e tam olarak hangi değişikliklerin dahil edileceğini indeksler. Bu sayede, aynı anda birden fazla dosyada düzenleme yapsanız bile, sadece ilgili kısımları ayıklayarak temiz commit'ler oluşturabilirsiniz.
3. Yerel Depo (Local Repository - .git dizini): Hazırlık alanındaki değişikliklerin Git tarafından kalıcı olarak kaydedildiği ve meta verilerin tutulduğu yerdir.

---

2. Dallanma Stratejisi: GitHub Flow

Modern web ve SaaS ekipleri, sadeliği ve sürekli dağıtım (CD) süreçlerine uyumluluğu nedeniyle genellikle GitHub Flow modelini standart olarak kabul eder.

       (Özellik Dalı: feat/user-auth)
        o---o---o---o
       /             \  (Pull Request)
------o---------------o------> main branch

GitHub Flow Kuralları:

• Ana dal (main) her an üretime (production) dağıtılabilecek kadar kararlı ve hatasız olmalıdır.
• Yeni bir görev üzerinde çalışmak için main dalından açıklayıcı bir isme sahip kısa ömürlü bir dal (feature branch) oluşturulur.
• Değişiklikler yerelde commit edilir ve uzak depoya (remote) gönderilir.
• Değişiklikleri birleştirmek için bir Pull Request (PR) açılır ve inceleme talep edilir.

---

3. Dal (Branch) Oluşturma ve İsimlendirme

Dal oluştururken, amacın ne olduğunu anında belirtmek için ön ek kurallarını kullanın:

• feat/ozellik-adi (Yeni bir özellik eklerken)
• fix/hata-adi (Hata düzeltmeleri yaparken)
• chore/gorev-adi (Yapılandırma, bağımlılık güncellemeleri veya altyapı işlerinde)
• docs/dokuman-adi (Markdown veya dokümantasyon güncellemelerinde)
• refactor/temizlik-adi (Hata düzeltmeyen veya özellik eklemeyen kod yapılandırmalarında)

Örnek İş Akışı:

Çalışmaya başlamadan önce yerel main dalının uzak depo ile tamamen aynı olduğundan emin olun:

git checkout main
git pull origin main

Özellik dalınızı oluşturun ve bu dala geçiş yapın:

git checkout -b feat/oauth-login

---

4. Kusursuz Commit Mesajları (Conventional Commits)

Profesyonel commit'ler atomik olmalıdır: yalnızca tek bir mantıksal değişikliğe odaklanmalıdır.

Kısmi Değişiklikleri Sahneye Ekleme

Eğer hem server.js hem de styles.css dosyalarında değişiklik yaptıysanız ve sadece backend değişikliklerini commit etmek istiyorsanız, hazırlık alanını kullanın:

# Sadece backend dosyasını hazırlık alanına ekle
git add server.js

Daha ileri düzey kullanımda, bir dosya içindeki belirli satırları etkileşimli olarak sahneye ekleyebilirsiniz:

git add -p server.js

Conventional Commits Spesifikasyonu

Commit mesajlarınızı belirli bir formata oturtmak, geçmişin okunabilirliğini artırır ve otomatik versiyonlama araçlarının çalışmasını sağlar.

<tip>(<kapsam>): <konu>

[isteğe bağlı gövde]

Örnekler:

• feat(auth): Google OAuth ile giriş desteği ekle.
• fix(api): Ödeme endpoint'indeki doğrulama hatasını çöz.
• chore(deps): Framer Motion bağımlılığını sürüm 11.0'a yükselt.

git commit -m "feat(auth): add Google OAuth login flow"

---

5. Senkron Kalmak: Merge vs. Rebase

Siz kendi dalınızda çalışırken, başkaları main dalına kod birleştirebilir. Kendi dalınızı birleştirmeden önce güncel durumla senkronize olmalısınız.

A Seçeneği: git merge main (Yeni bir merge commit oluşturur)
o---o---o (feat)
     \   \
------o---o (main)

B Seçeneği: git rebase main (Değişikliklerinizi main'in üzerine yeniden yazar)
          o'---o'---o' (feat)
         /
--------o (main)

Ne Zaman Rebase Yapılmalı?

Doğrusal (linear) ve temiz bir geçmiş için rebase tercih edilir. Yerel değişikliklerinizi main dalındaki en son commit'in üzerine taşır.

git checkout feat/oauth-login
git fetch origin
git rebase origin/main

Çakışmaları (Conflict) Çözme:

Eğer aynı satır hem main dalında hem de sizin dalınızda değiştirilmişse, rebase işlemi duraklatılır.

1. Çakışan dosyaları görmek için git status komutunu çalıştırın.
2. Dosyaları açarak çakışma işaretlerini bulun:

   <<<<<<< HEAD
   // main dalından gelen kod
   =======
   // Sizin yaptığınız değişiklikler
   >>>>>>> feat/oauth-login
   

3. Dosyayı düzenleyerek kalması gereken kodu seçin ve çakışma işaretlerini silin.
4. Çözülen dosyayı hazırlık alanına ekleyin:

   git add server.js
   

5. Rebase işlemine devam edin:

   git rebase --continue
   

---

6. Pull Request (PR) Yönetimi

Değişikliklerinizi uzak depoya şu komutla gönderin:

git push origin feat/oauth-login

GitHub üzerinde Pull Request açarken şu standartları uygulayın:

• Küçük Kapsam: Değişiklikleri 300 satır sınırının altında tutmaya çalışın.
• Açıklayıcı Olun: Değişikliğin Ne, Neden ve Nasıl test edildiğini açıklayın.
• Kendi Kodunuzu İnceleyin: PR açmadan önce GitHub'daki değişiklikleri gözden geçirin. Unutulmuş test kodlarını veya konsol çıktılarını temizleyin.

---

7. Birleştirme (Merging) Stratejileri

PR onaylandığında ve testler başarılı olduğunda, uygun birleştirme stratejisini seçin:

1. Squash and Merge: Özellik dalındaki tüm commit'leri tek bir temiz commit olarak birleştirip main dalına yazar. SaaS projelerinde üretim dalının geçmişini temiz tuttuğu için en çok tercih edilen yöntemdir.
2. Rebase and Merge: Özellik dalındaki commit'leri ayrı ayrı main üzerine yazar, geçmişi doğrusal tutar.
3. Merge Commit: Tüm commit geçmişini ve birleştirmeye dair özel bir birleştirme commit'ini korur.

Çoğu durumda Squash and Merge tercih edilmelidir.

---

Sonuç

Hazırlık alanının gücünü kullanmak, düzenli dal isimlendirmeleri yapmak, Conventional Commits standardını benimsemek ve doğru yerlerde Git Rebase ve Squash-and-Merge stratejilerini uygulamak, ekipler arasındaki sürtünmeyi sıfıra indirir. Bu temiz alışkanlıklar, kod entegrasyonu problemlerini önleyerek geliştirme hızınızı yüksek tutar.