Kucuk Takimlar Icin Anlamli Bir Git Is Akisi

Çoğu Git iş akışı rehberi düzinelerce veya yüzlerce geliştiricisi olan büyük şirketler, karmaşık sürüm trenleri ve özel DevOps takımları için yazılmıştır. İki-beş kişilik küçük bir takımdaysanız, o tavsiyelerin çoğu gereksizdir. Kod yazmak yerine dal yönetimiyle uğraşırsınız.

Çeşitli boyutlarda takımlarda çalıştım ve takımınız tek bir odaya sığdığında gerçekten işe yarayan Git iş akışını paylaşmak istiyorum.

Git Flow'un Problemi

Git Flow 2010'da Vincent Driessen tarafından tanıtıldı ve bir süre altın standart oldu. Beş dal türü tanımlar: main, develop, feature, release ve hotfix. Her birinin nereden dallanacağı ve nereye birleştirileceği hakkında kuralları var.

Sürekli dağıtımla web uygulaması yapan üç kişilik bir takım için? Çok fazla seremoni.

Pratikte şu olur: develop'dan feature dalı oluşturursunuz, özelliği bitirirsiniz, develop'a geri birleştirirsiniz, sonra sürüm çıkarmak istediğinizde develop'dan release dalı oluşturursunuz, sorunları düzeltirsiniz, main'e VE develop'a birleştirirsiniz, etiketlersiniz ve temizlersiniz.

Küçük bir proje için bu yorucu. Senkron tutulması gereken iki uzun ömürlü dalınız (main ve develop), günlerce var olan release dalları ve anlamak için akış şeması gerektiren bir birleştirme süreci var.

Daha Basit Yaklaşım: Trunk-Based Development (Hafif)

Küçük takımlarla kullandığım iş akışı şu:

1. main — her zaman deploy edilebilir, korumalı dal 2. feature dalları — kısa ömürlü (saatler-günler, haftalar değil), görev başına bir tane 3. Bu kadar. Develop dalı yok. Release dalları yok. Hotfix dalları yok.

Temel ilkeler:

• Feature dalları maksimum 1-3 gün yaşar
• Main'e her birleştirme kod incelemesiyle PR üzerinden geçer
• Main her zaman deploy edilebilir
• Doğrudan main'den deploy edin

Günlük Akış Detaylı

Yeni Özellik Başlatma

Bash

# Her zaman güncel main'den başla
git checkout main
git pull origin main
# Açıklayıcı isimle feature dalı oluştur
git checkout -b feature/arama-cubugu-ekle

Dal isimlendirme önemlidir:

• feature/aciklama — yeni işlevsellik
• fix/aciklama — hata düzeltmeleri
• refactor/aciklama — davranış değişikliği olmadan iyileştirme
• chore/aciklama — araçlar, bağımlılıklar, yapılandırma

Özellik Üzerinde Çalışma

Sık commit yapın. Küçük, odaklanmış commitler incelenmesi ve hata ayıklaması çok daha kolaydır.

Bash

git add -A
git commit -m "feat: debounce ile arama input bileşeni ekle"
git add -A
git commit -m "feat: arama inputunu post arama API'sine bağla"
git add -A
git commit -m "feat: aramaya yükleme spinner ve hata durumu ekle"
git add -A
git commit -m "test: arama bileşeni için birim testleri ekle"

Güncel Kalma

Siz çalışırken main değiştiyse dalınızı rebase edin:

Bash

git fetch origin
git rebase origin/main

Rebase commitLerinizi en son main'in üstüne yeniden oynatır. Geçmişi doğrusal ve temiz tutar.

Kodunuzu Birleştirme

Bash

git push origin feature/arama-cubugu-ekle

PR oluşturun. Anlamlı bir açıklama yazın: ne değişiyor, neden gerekli, inceleyici nasıl test edebilir.

Takım arkadaşı kodu inceler, onayladığında squash-merge ile main'e birleştirin. Squash merge tüm feature dal commitlerini main'de tek commite birleştirir.

Gerçekten Yardımcı Olan Commit Mesajları

Conventional Commits kullanıyorum:

feat: debounce ile kullanıcı araması ekle
fix: yavaş ağlarda çift form gönderimini önle
refactor: e-posta doğrulamayı paylaşılan utility'ye çıkar
docs: v2 için API endpoint belgelerini güncelle
chore: Spring Boot'u 3.2'den 4.0'a yükselt
test: ödeme işleme için entegrasyon testleri ekle

Önek, diff okumadan ne tür değişiklik olduğunu söyler.

Kötü commit mesajları:

"güncelleme"
"hata düzelt"
"değişiklikler"
"WIP"

İşler Ters Gittiğinde

Yanlışlıkla Main'e Commit Ettiniz

Bash

git reset HEAD~1
git checkout -b feature/uzerinde-calistigim-sey
git add -A
git commit -m "feat: üzerinde çalıştığım şey"

Son Commiti Geri Almak

Bash

git reset --soft HEAD~1   # Commit geri al, değişiklikler staged kalır
git reset HEAD~1          # Commit geri al, değişiklikler unstaged kalır
git reset --hard HEAD~1   # Commit VE değişiklikler gider (DİKKAT)

Merge Çatışmaları

Panik yapmayın. Merge çatışmaları normaldir ve genellikle göründüğü kadar kötü değildir.

1. Çatışan dosyayı açın 2. <<<<<<< işaretlerini bulun 3. Hangi versiyonu tutacağınıza karar verin (veya birleştirin) 4. Çatışma işaretlerini kaldırın 5. Stage ve commit yapın

İpucu: çatışmalar korkutuyorsa görsel birleştirme aracı kullanın. VS Code'un yerleşik çatışma çözümü iyidir.

PR En İyi Uygulamaları

PR'leri küçük tutun. 400 satırın altı idealdir. Büyük PR'ler inceleyiciler odağını kaybettiği için otomatik onaylanır.

İyi açıklama yazın. Ne değişiyor, neden değişiyor, nasıl doğrulanır.

Bir PR = bir konu. İlgisiz refactoring veya bağımlılık güncellemelerini karıştırmayın.

24 saat içinde inceleyin. Bayat PR'ler momentumu öldürür.

İncelemelerde yapıcı olun. "Bu yanlış" yardımcı değildir. "Kullanıcının e-postası yoksa null pointer oluşabilir — burada null kontrolü eklemeyi düşünün" yardımcıdır.

Dal Koruma Kuralları

İki kişilik takımda bile main'i koruyun:

• Birleştirmeden önce en az bir onay gerekir
• CI kontrollerinin geçmesi gerekir
• Main'e doğrudan push yok
• Sadece squash merge
• Birleştirmeden sonra dalları otomatik sil

Bu kuralları GitHub'da ayarlamak beş dakika sürer ve saatlerce baş ağrısını önler.

CI/CD: Otomatikleştirebileceğinizi Otomatikleştirin

Minimumda CI pipeline'ınız her PR'de projeyi derlemeli, tüm testleri çalıştırmalı, linter çalıştırmalı ve sonuçları PR'ye bildirmelidir.

YAML

name: CI
on:
  pull_request:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: 21
          distribution: temurin
      - run: ./mvnw verify

Sonuç

Git bir araçtır, din değil. Takımınızı üretken ve kodunuzu güvende tutan en basit iş akışını kullanın. Çoğu küçük takım için bu:

• main + feature dalları + pull request'ler
• Kısa ömürlü dallar (1-3 gün)
• Temiz geçmiş için squash merge
• CI kontrolleriyle dal koruması
• Conventional commit mesajları

Bu kadar. Develop dalı yok, release dalları yok, karmaşık birleştirme seremonileri yok. Kod gönderin, sık gönderin ve main'i her zaman deploy edilebilir tutun.

Takımınız 10+ kişiye büyüdüğünde ve sürümlü sürümlere ihtiyaç duyduğunuzda, o zaman daha yapılandırılmış bir şey düşünün. O zamana kadar basit tutun.