Git'i ilk öğrendiğimde tek başıma çalışıyordum. git add, git commit, git push üçlüsü işimi görüyordu. Sonra ilk takım projeme katıldım ve her şey değişti.

Birinin değişikliği diğerinin kodunu ezdi. Commit geçmişinde "düzeltme", "son hali", "bu sefer oldu" gibi mesajlar birikti. Hatanın nereden geldiğini bulmak saatler aldı.

O günlerden bu yana öğrendiğim şey şu: Git'in komutları kadar, takımın üzerinde anlaştığı kurallar da önemli. Bu yazıda yeni başlayanlar için üç temel konuyu anlatacağım: dal stratejisi, anlamlı commit mesajları ve pull request incelemesi.

Dal stratejisi: herkes kendi şeridinde

Dal (branch), ana koddan ayrılıp güvenle çalışabildiğin bir kopya gibidir. Takım çalışmasında altın kural basit: Kimse doğrudan ana dala commit atmaz.

Main adlı ana daldan ayrılan feature/beni-hatirla ve fix/sepet-toplam-hatasi dallarının birkaç commit sonra main'e geri birleştiğini gösteren zaman çizelgesi; doğrudan main'e commit atılmaması ve dall
Her iş için main'den kısa ömürlü bir dal açılır, iş bitince yeniden main ile birleştirilir.

Ana dal (çoğu projede main) her zaman çalışır durumda olmalı. Yeni bir özellik ya da hata düzeltmesi için ondan yeni bir dal açarsın, işini bitirince geri birleştirirsin.

Basit bir dal yapısı

Yeni başlayan takımlar için en anlaşılır yaklaşım, kısa ömürlü özellik dallarıdır:

  • main: Yayındaki ya da yayına hazır kod.
  • feature/...: Yeni bir özellik için açılan dal.
  • fix/...: Bir hatayı düzeltmek için açılan dal.

Örneğin giriş sayfasına "Beni hatırla" seçeneği ekleyeceksem şöyle başlarım:

git switch main
git pull
git switch -c feature/beni-hatirla

Önce main dalını güncelliyorum, sonra en güncel halinden yeni dalımı açıyorum. Böylece eski bir kodun üzerine çalışmamış oluyorum.

Dal isimlendirme

Dal adı, içinde ne olduğunu söylemeli. deneme2 ya da bahadir-dal gibi isimler bir hafta sonra kimseye bir şey anlatmaz. fix/sepet-toplam-hatasi ise ilk bakışta anlaşılır.

Dallarını kısa tut. Bir dal ne kadar uzun yaşarsa main ile arasındaki fark o kadar büyür ve birleştirirken çakışma (conflict) çıkma ihtimali artar. Birkaç günde bitirilebilecek parçalara bölmeye çalış.

Daha büyük projelerde Git Flow gibi ayrı develop ve release dalları kullanan yapılar da var. Ama başlangıçta bu karmaşıklığa ihtiyacın yok. Önce basit yapıyı alışkanlık haline getir.

Anlamlı commit mesajları

Commit mesajı, gelecekteki sana ve takım arkadaşlarına bırakılmış bir nottur. Altı ay sonra "Bu satır neden böyle?" diye sorduğunda cevabı burada ararsın.

Kötü ve iyi örnekleri yan yana koyalım:

Kötü:
  düzeltme
  güncellendi
  asdasd

İyi:
  Sepet toplamında indirimin iki kez uygulanması düzeltildi
  Giriş formuna "Beni hatırla" seçeneği eklendi

İyi mesaj, kodun ne yaptığını ve mümkünse neden değiştiğini söyler. Kodun nasıl değiştiğini zaten fark (diff) gösterir.

Uyduğum birkaç kural

  1. İlk satır kısa olsun, yaklaşık 50 karakter civarı.
  2. İlk satırdan sonra bir boş satır bırak, gerekiyorsa ayrıntıyı alt satırlara yaz.
  3. Her commit tek bir mantıksal değişiklik içersin.
  4. Takım hangi dili seçtiyse (Türkçe ya da İngilizce) hep onu kullan.

Ayrıntılı bir commit şöyle görünebilir:

fix: sepet toplamında indirim iki kez uygulanıyordu

Kupon kodu girildiğinde indirim hem ürün satırında hem de
genel toplamda hesaplanıyordu. Hesaplama yalnızca genel
toplama taşındı.

Baştaki fix: öneki Conventional Commits adlı bir kurala ait. feat:, fix:, docs: gibi önekler geçmişi taramayı kolaylaştırır. Zorunlu değil, ama takım olarak birine karar vermek işi çok rahatlatır.

"Tüm gün ne yaptıysam tek commit" alışkanlığından kaçın. Bir hatayı geri almak gerektiğinde, ilgisiz on değişikliği de birlikte geri almak zorunda kalırsın. Küçük ve odaklı commit'ler, git revert ile tek bir değişikliği güvenle geri almayı mümkün kılar.

Pull request açmak ve incelemek

Dalındaki iş bitti. Şimdi onu main ile birleştirmek istiyorsun. Takımlarda bu iş doğrudan git merge ile değil, pull request (GitLab'da merge request) ile yapılır.

Pull request sürecinin altı adımı: dalı gönder, pull request aç, otomatik testler, inceleme ve yorumlar, düzeltme commit'leri ve onayla main ile birleştirme; inceleme ile düzeltme arasında tekrar döng
Pull request, kodun main'e girmeden önce test edilip takım tarafından incelendiği adımlardan oluşur.

Pull request, "Bu değişikliği ana koda almak istiyorum, bir göz atar mısınız?" demenin resmî yoludur. Akış genellikle şöyledir:

  1. Dalını uzak depoya gönderirsin.
  2. Pull request açar, ne yaptığını açıklarsın.
  3. Otomatik testler çalışır.
  4. Bir ya da daha fazla takım arkadaşın kodu inceler, yorum yazar.
  5. Gereken düzeltmeleri yapıp aynı dala yeni commit gönderirsin.
  6. Onay gelince dal main ile birleştirilir.
git push -u origin feature/beni-hatirla

Bu komuttan sonra GitHub ya da GitLab arayüzü sana pull request açma bağlantısı gösterir. Ayrıntılar için GitHub'ın pull request belgelerine bakabilirsin.

İyi bir pull request açıklaması

İnceleyen kişi senin kafandakini bilmiyor. Açıklamada şunları yazmaya çalışıyorum:

  • Ne değişti: Bir iki cümlelik özet.
  • Neden: İlgili görev ya da hata kaydı.
  • Nasıl test edilir: "Giriş sayfasında kutuyu işaretle, tarayıcıyı kapatıp aç, oturum açık kalmalı."

Bir de boyuta dikkat et. Bin satırlık bir pull request'i kimse gerçekten incelemez, sadece onaylar. Küçük pull request'ler hem daha hızlı hem daha dikkatli incelenir.

İnceleme yaparken

Kod incelemesi bir sınav değil, birlikte daha iyi kod yazma yolu. Yorumlarda kişiyi değil kodu konuşmaya özen gösteriyorum:

"Bu kod yanlış." yerine "Burada kullanıcı null gelirse ne olur? Bir kontrol eklesek mi?"

İncelerken baktığım şeyler kabaca şunlar: Kod söylediği işi yapıyor mu? Okunabilir mi? Hata durumları düşünülmüş mü? Test var mı? Değişken adı ya da boşluk gibi küçük şeyleri ise mümkünse otomatik araçlara (linter, formatter) bırakmak en iyisi.

İncelenen taraf olduğunda da yorumları kişisel alma. Benim en çok şey öğrendiğim yer, kendi pull request'lerime gelen yorumlar oldu.

Günlük akış: baştan sona bir örnek

Tüm parçaları birleştirelim. Bir hata kaydı geldiğinde benim tipik günüm şöyle geçer:

# 1. Güncel main'den yeni dal aç
git switch main
git pull
git switch -c fix/sepet-indirim

# 2. Değişikliği yap, küçük commit'ler at
git add sepet.js
git commit -m "fix: indirim yalnızca genel toplamda uygulanıyor"

# 3. Bu arada main ilerlediyse dalını güncelle
git fetch origin
git rebase origin/main

# 4. Gönder ve pull request aç
git push -u origin fix/sepet-indirim

Üçüncü adımdaki rebase, senin commit'lerini main'in en güncel halinin üzerine taşır. Çakışma çıkarsa Git sana hangi dosyada olduğunu söyler; düzeltip git add ve ardından git rebase --continue ile devam edersin. Komutların ayrıntısı için resmî git-rebase belgesi iyi bir kaynak.

Başkalarının da üzerinde çalıştığı ortak bir dalı rebase edip git push --force ile gönderme. Geçmişi yeniden yazdığın için arkadaşlarının elindeki kopyalar bozulur. Rebase'i yalnızca sadece senin kullandığın dallarda yap; zorunlu kalırsan daha güvenli olan --force-with-lease seçeneğini tercih et.

Sonuç

Git ile takım çalışması aslında üç basit alışkanlığa dayanıyor: Her iş için kısa ömürlü bir dal aç, her commit'e ne yaptığını anlatan bir mesaj yaz ve kodu ana dala almadan önce bir pull request ile başkasının gözünden geçir.

Bu kuralları ilk başta yavaşlatıcı bulabilirsin. Ama bir hatanın kaynağını iki dakikada bulduğun ilk gün, neden uğraştığını anlayacaksın. Küçük başla, takımınla kuralları yazıya dök ve zamanla geliştir.

Sık sorulan sorular

Merge mi kullanmalıyım, rebase mi?

İkisi de doğru araçlar. Merge geçmişi olduğu gibi korur, rebase daha düz ve okunaklı bir geçmiş verir. Yeni başlayanlar için önerim: Kendi dalını güncellerken rebase, paylaşılan dallarda merge kullan ve takımca birine karar ver.

Yanlış commit mesajı yazdım, düzeltebilir miyim?

Henüz push etmediysen git commit --amend ile son commit'in mesajını değiştirebilirsin. Push ettiysen ve dal ortak kullanılıyorsa, geçmişi değiştirmek yerine olduğu gibi bırakmak genellikle daha güvenlidir.

Pull request'i kaç kişi incelemeli?

Küçük takımlarda bir onay çoğu zaman yeterli. Önemli olan sayıdan çok incelemenin gerçekten yapılması. GitHub ve GitLab'da ana dal için en az bir onay zorunluluğu koymak iyi bir başlangıçtır.

İşi bitmemiş bir dalı paylaşabilir miyim?

Evet. GitHub'daki taslak (draft) pull request özelliğiyle işin henüz hazır olmadığını belirtip erken geri bildirim alabilirsin. Bu, yanlış yönde çok ilerlemeden önce yön düzeltmek için çok faydalı.