Temiz Commit’ler ve Ekipler İçin Git En İyi Uygulamaları

Temiz Commit’ler ve Ekip İş Birliği İçin Git En İyi Uygulamaları

Git, bir projedeki anlamlı her adımı koruyabilir; ancak geliştiriciler yalnızca commit oluşturduğu için bir depo kullanışlı hale gelmez. Sağlıklı bir Git geçmişi bilinçli kararlara bağlıdır: Bir commit’e nelerin dahil olduğu, branch’lerin nasıl adlandırıldığı, çalışmanın ne zaman incelendiği, secret’ların nasıl korunduğu, hangi merge yönteminin kullanıldığı ve bir sorun oluştuğunda kurtarmanın nasıl yönetildiği.

İyi Git uygulamaları projeye dokunan herkes için sürtünmeyi azaltır. İncelemeleri hızlandırır, hata ayıklamayı kolaylaştırır, sürümleri daha güvenli hale getirir, onboarding sürecini netleştirir ve otomasyonu daha güvenilir yapar. Kötü uygulamalar ise tam tersini üretir: aşırı büyük commit’ler, kafa karıştırıcı branch’ler, yanlışlıkla eklenen secret’lar, kararsız main branch’ler, gürültülü geçmiş ve riskli force push işlemleri.

Bu rehber, bireysel geliştiriciler ve ekipler için pratik Git alışkanlıklarını bir araya getirir. Temiz commit’lere, branch disiplinine, iş birliğine, depo güvenliğine, kod incelemesine, CI/CD’ye, kurtarmaya, bakıma ve uzun vadeli geçmiş kalitesine odaklanır.

Neler Öğreneceksiniz?

Odaklı ve incelenebilir commit’lerin nasıl tasarlanacağını.
Yararlı commit mesajlarının nasıl yazılacağını.
Değişikliklerin bilinçli biçimde nasıl stage edileceğini.
Mantıklı branch adlarının ve yaşam sürelerinin nasıl seçileceğini.
Varsayılan branch’in nasıl sağlıklı tutulacağını.
Değişikliklerin güvenli biçimde nasıl incelenip merge edileceğini.
Merge, squash, rebase, revert veya cherry-pick işlemlerinin ne zaman kullanılacağını.
Secret’ların ve hassas yapılandırmanın nasıl korunacağını.
.gitignore ve .gitattributes dosyalarının doğru biçimde nasıl kullanılacağını.
Yıkıcı geçmiş hatalarından nasıl kaçınılacağını.
Hook’ların, CI’ın, branch korumasının ve otomasyonun nasıl etkili kullanılacağını.
Büyük depoların ve binary dosyaların nasıl yönetileceğini.
Anlaşılır kalabilen bir ekip Git politikasının nasıl oluşturulacağını.

En İyi Uygulama 1: İşlem Yapmadan Önce Depo Durumunu Anlayın

Birçok Git hatası, geçerli branch’i, staged değişiklikleri veya untracked dosyaları anlamadan komut çalıştırmakla başlar.

Önemli işlemlere şunlarla başlayın:

git status
git branch --show-current
git log -1 --oneline

Commit, merge, rebase, pull, reset veya branch silme işleminden önce şunları doğrulayın:

Geçerli branch doğrudur.
Working tree yalnızca beklenen değişiklikleri içerir.
Staging area amaçlanan snapshot’ı içerir.
Hiçbir tamamlanmamış çalışma üzerine yazılmayacaktır.
Depo ekip iş akışına göre senkronizedir.

git status yalnızca yeni başlayanlara yönelik bir komut değildir. Deneyimli geliştiriciler de durum değiştiren işlemlerden önce güvenli bir özet sunduğu için onu sürekli kullanır.

En İyi Uygulama 2: Commit’leri Odaklı Tutun

Bir commit tek bir mantıksal değişikliği temsil etmelidir.

İyi örnekler:

Kayıt işlemine e-posta doğrulaması eklemek.
Yinelenen fatura oluşturmayı düzeltmek.
Ödeme servisi interface’lerini yeniden adlandırmak.
Yerel ortam kurulumunu belgelemek.
Süresi dolmuş parola sıfırlama token’ları için test eklemek.

Kötü bir commit şunları bir araya getirebilir:

Bir hata düzeltmesi.
Bir formatting geçişi.
Bir dependency güncellemesi.
Dokümantasyon değişiklikleri.
Geçici debug kodu.

Odaklı commit’ler şunları kolaylaştırır:

İnceleme.
Test etme.
Geri alma.
Cherry-pick yapma.
Aylar sonra anlama.
Hata ayıklama ve bisect işlemlerinde kullanma.

Commit boyutu sabit bir satır sayısıyla değil, mantıksal amacıyla değerlendirilmelidir. Tutarlı bir veritabanı migration’ı birkaç dosyaya dokunabilir. Tek satırlık bir değişiklik bile riskli olabilir ve kendi commit’ini hak edebilir.

En İyi Uygulama 3: Değişiklikleri Bilinçli Biçimde Stage Edin

Profesyonel bir commit iş akışı, düzenleme ile commit tasarımını birbirinden ayırır.

Unstaged çalışmayı inceleyin:

git diff

Seçilen path’leri stage edin:

git add src/OrderService.php
git add tests/OrderServiceTest.php

Veya seçilen hunk’ları stage edin:

git add -p

Önerilen commit’i inceleyin:

git diff --staged

Ardından commit oluşturun:

git commit -m "Yinelenen sipariş oluşturmayı önle"

git add . komutunu otomatik ilk adım olarak kullanmaktan kaçının. Kullanışlıdır, ancak ilgisiz düzenlemeleri, yerel dosyaları, kimlik bilgilerini, üretilmiş çıktıları veya debug değişikliklerini dahil edebilir.

Daha güvenli bir düzen:

git status
git diff
git add -p
git diff --staged
git commit

En İyi Uygulama 4: Yararlı Commit Mesajları Yazın

Commit mesajı değişikliğin amacını açıklamalıdır.

Zayıf başlıklar:

güncelle
düzelt
değişiklikler
son
yeni kod

Daha güçlü başlıklar:

Süresi dolmuş parola sıfırlama token’larını reddet
Yinelenen webhook işlemlerini önle
Görev başlıkları için arama indeksi ekle
Queue worker yapılandırmasını belgele

Pratik bir mesaj biçimi:

Kısa başlık

Değişikliğin neden gerektiğini, önemli kısıtları,
ödünleşimleri ve test notlarını açıklayan isteğe bağlı gövde.

İyi mesaj alışkanlıkları:

Açık ve eylem odaklı bir başlık kullanın.
Yalnızca dosya adını değil, amacı açıklayın.
Diff’in açıklayamadığı nedeni belirtin.
Önemli uyumluluk veya migration ayrıntılarını kaydedin.
Issue’lara ekip kurallarına göre referans verin.
Commit mesajlarında hassas bilgilerden kaçının.

Diff neyin değiştiğini gösterir. Mesaj ise neden değiştiğini korumalıdır.

En İyi Uygulama 5: Tutarlı Bir Commit Kuralı Kullanın

Ekipler tutarlı bir mesaj stilinden yararlanır.

Basit bir kural şunları kullanabilir:

Ekle ...
Düzelt ...
Kaldır ...
Yeniden düzenle ...
Belgele ...
Test et ...

Bazı projeler Conventional Commits kullanır:

feat: görev arama filtreleri ekle
fix: yinelenen fatura oluşturmayı önle
docs: yerel queue kurulumunu açıkla
refactor: ödeme yeniden deneme politikasını ayır
test: süresi dolmuş sıfırlama token’larını kapsa

Bu yapı otomatik changelog üretimini ve release araçlarını destekleyebilir, ancak Git’in bir gereksinimi değildir.

Yapılandırılmış bir kuralı yalnızca şu durumlarda kullanın:

Ekip onu anlıyorsa.
Araçlar bundan fayda sağlıyorsa.
Kurallar belgelenmişse.
Doğrulama gereksiz ölçüde katı hale gelmiyorsa.

En İyi Uygulama 6: Bozuk veya Eksik Mantıksal Durumları Commit Etmeyin

Mümkün olduğunda her commit projeyi test edilebilir bir durumda bırakmalıdır.

Bir commit kasıtlı olarak şunları içermemelidir:

Sözdizimi hataları.
Çözülmemiş conflict işaretleri.
Açıklama olmadan bilinen başarısız testler.
Uygulamayı kullanılamaz hale getiren yarım migration’lar.
Yalnızca sonraki commit’te eklenen dosyalara referanslar.

Bu önemlidir çünkü tekil commit’ler:

Hata ayıklama sırasında checkout edilebilir.
git bisect tarafından kullanılabilir.
Başka branch’e cherry-pick edilebilir.
Bağımsız olarak incelenebilir.
Otomasyon tarafından yanlışlıkla yayınlanabilir.

Her ara commit production’a hazır olmak zorunda değildir; ancak kendi içinde anlaşılır olmalı ve açık bir neden olmadan temel depo varsayımlarını bozmamalıdır.

En İyi Uygulama 7: Refactoring’i Davranış Değişikliklerinden Ayırın

Refactoring ideal olarak davranışı korur. Feature veya bug fix ise davranışı değiştirir.

İkisini tek büyük commit içinde birleştirmek incelemeyi zorlaştırır; çünkü inceleyenler yapısal hareketi işlevsel mantıktan kolayca ayıramaz.

Şunu tercih edin:

Commit 1: Fatura doğrulama servisini ayır
Commit 2: Yinelenen fatura kimliklerini reddet

Bu, inceleyenlerin önce refactoring’in davranışı koruduğunu doğrulamasına, ardından yeni mantığı ayrı değerlendirmesine olanak tanır.

Ayırma mümkün değilse commit gövdesinde veya pull request açıklamasında ilişkiyi açıkça anlatın.

En İyi Uygulama 8: Açıklayıcı Branch Adları Kullanın

Branch adı amacı anlatmalıdır.

İyi örnekler:

feature/task-search
fix/payment-timeout
hotfix/duplicate-invoice
docs/local-setup
refactor/order-service
release/3.2.0

Kötü örnekler:

new
test
final
branch2
adnan-work
changes

Branch adlandırma politikası şunları içerebilir:

Tür ön eki.
Kısa açıklama.
Yararlı olduğunda issue kimliği.
Tutarlı biçimde ayrılan küçük harfli sözcükler.

Örnek:

feature/APP-142-task-search

Kişisel adları branch’in ana kimliği olarak kullanmayın. Branch’ler sahipliği değil, işi açıklamalıdır.

En İyi Uygulama 9: Branch’leri Kısa Ömürlü Tutun

Branch ne kadar uzun süre açık kalırsa hedef branch’ten o kadar fazla ayrışır.

Uzun ömürlü branch’ler şunları oluşturur:

Daha büyük merge conflict’leri.
Geç ortaya çıkan mimari sürprizler.
Uzun inceleme döngüleri.
Yinelenen çalışma.
Riskli entegrasyon olayları.
Branch’in hâlâ aktif olup olmadığını anlamakta zorluk.

Proje izin veriyorsa saatler veya birkaç gün içinde merge edilen küçük ve incelenebilir artışları tercih edin.

Büyük özellikler için:

Feature flag kullanın.
Branch by abstraction kullanın.
Çalışmayı bağımsız ve güvenli artışlara bölün.
Aktivasyondan önce altyapıyı entegre edin.

En İyi Uygulama 10: Branch’leri Doğru Base’den Başlatın

Branch oluşturmadan önce:

git switch main
git fetch origin
git merge --ff-only origin/main
git switch -c feature/task-search

Tam güncelleme komutu iş akışına bağlıdır; ancak ilke sabittir: amaçlanan güncel base’den başlayın.

Eski veya yanlış branch’ten yeni branch oluşturmak ilgisiz commit’ler, eksik düzeltmeler ve kafa karıştırıcı pull request diff’leri getirebilir.

En İyi Uygulama 11: Varsayılan Branch’i Sağlıklı Tutun

Varsayılan branch’in açıkça tanımlanmış bir durumu olmalıdır.

Yaygın beklentiler:

Her zaman deploy edilebilir olması.
Her zaman yayınlanabilir olması.
Gerekli testleri her zaman geçmesi.
Her zaman en güncel entegre geliştirme durumunu temsil etmesi.

Varsayılan branch’i şu yöntemlerle koruyun:

Pull request veya merge request zorunlu kılmak.
Doğrudan push işlemlerini engellemek.
Otomatik kontrolleri zorunlu kılmak.
Onayları zorunlu kılmak.
Force push işlemlerini engellemek.
Silme işlemini kısıtlamak.

Varsayılan branch bozulduğunda onarımı önceliklendirin. Uzun süre bozuk kalan bir branch ekibe CI’ı görmezden gelmeyi öğretir ve sonraki her merge işlemine duyulan güveni azaltır.

En İyi Uygulama 12: Pull Request Açmadan Önce Branch Diff’ini İnceleyin

Geliştiriciler inceleme istemeden önce kendi çalışmalarını gözden geçirmelidir.

Yararlı komutlar:

git log --oneline main..HEAD
git diff --stat main...HEAD
git diff main...HEAD

Şunları kontrol edin:

İlgisiz dosyalar.
Debug ifadeleri.
Secret’lar.
Üretilmiş dosyalar.
Formatting gürültüsü.
Eksik testler.
Yanlışlıkla silinen içerikler.
Migration süreci olmayan veritabanı değişiklikleri.

Kendi kendine incelenmiş bir pull request, inceleyenlerin zamanını korur ve iş birliğini iyileştirir.

En İyi Uygulama 13: Pull Request’leri Küçük Tutun

Büyük pull request’ler inceleme kalitesini düşürür.

Binlerce değişmiş satırla karşılaşan bir inceleyenin şunları yapma olasılığı artar:

Hataları kaçırmak.
Tasarım yerine stile odaklanmak.
İncelemeyi geciktirmek.
Tam anlamadan onaylamak.
Sürecin sonunda tamamen yeniden yazım istemek.

Küçük pull request’ler:

Daha hızlı geri bildirim alır.
Daha az conflict üretir.
Daha kolay test edilir.
Daha kolay geri alınır.
Artımlı tasarımı teşvik eder.

Büyük bir değişiklik kaçınılmazsa mekanik değişiklikleri, schema hazırlığını, feature-flag altyapısını ve davranış aktivasyonunu aşamalara ayırın.

En İyi Uygulama 14: Draft İncelemeleri Erken Kullanın

Draft pull request veya merge request şu durumlarda faydalıdır:

Mimarinin erken geri bildirime ihtiyacı varsa.
Değişiklik birden fazla ekibi etkiliyorsa.
Geliştirici tamamlanmadan önce CI doğrulaması istiyorsa.
Branch aksi halde çok uzun süre izole kalacaksa.

Erken inceleme, her tasarım kararının değiştirilmesi pahalı hale geldikten sonra yapılan geç incelemeden daha değerlidir.

Draft durumu kalıcı hale gelmemelidir. Büyük çalışmayı merge edilebilir artışlara ayırmaya devam edin.

En İyi Uygulama 15: Açık Bir Merge Politikası Seçin

Ekipler hangi entegrasyon yöntemlerinin kullanılabileceğini tanımlamalıdır.

Merge Commit

Branch topolojisini ve tekil commit’leri korur.

Squash Merge

Pull request’i hedef branch üzerinde tek yeni commit halinde birleştirir.

Rebase and Merge

Commit’leri merge commit oluşturmadan hedef geçmişin üzerine yeniden uygular.

Doğru seçim ekibin şunlara verdiği öneme bağlıdır:

Açık merge sınırları.
Her pull request için tek commit.
Doğrusal geçmiş.
Feature branch commit’lerinin korunması.

Tutarsız merge yöntemleri geçmişi yorumlamayı zorlaştırır. Varsayılan yöntemi ve istisnaları belgeleyin.

En İyi Uygulama 16: Rebase’i Yalnızca Güvenli Olduğunda Kullanın

Rebase, commit’leri yeni bir base üzerinde yeniden oluşturarak geçmişi değiştirir.

Şu amaçlar için kullanışlıdır:

Özel feature branch geçmişini temizlemek.
İnceleme öncesinde yerel branch’i güncellemek.
Fixup commit’lerini birleştirmek.
Ekip istediğinde doğrusal geçmişi korumak.

Ekip yeniden yazımı koordine etmedikçe diğer geliştiricilerin zaten bağımlı olduğu commit’leri rebase etmekten kaçının.

Pratik kural:

Özel yerel geçmiş özgürce yeniden yazılabilir.
Paylaşılan public geçmiş yalnızca açık anlaşmayla yeniden yazılmalıdır.

En İyi Uygulama 17: Kör Force Push Yerine force-with-lease Kullanın

Yeniden yazılmış bir branch remote üzerinde güncellenmek zorundaysa şundan kaçının:

git push --force

Şunu tercih edin:

git push --force-with-lease

--force-with-lease bir güvenlik kontrolü ekler. Remote durumu yerel deponun beklediğinden farklıysa remote branch’in üzerine yazmayı reddeder.

Bu, force push işlemini zararsız hale getirmez. Yalnızca başka bir geliştiricinin daha yeni çalışmasını silme riskini azaltır.

Belgelenmiş acil durum süreci gerektirmediği sürece main gibi korumalı paylaşılan branch’lere asla force push uygulamayın.

En İyi Uygulama 18: Paylaşılan Geçmişte Revert Kullanın

Kötü bir commit zaten paylaşıldıysa onu tersine çeviren yeni bir commit oluşturun:

git revert <commit>

Bu yöntem tarihsel kaydı korur.

Reset’i esas olarak yerel veya özel geçmiş için kullanın:

git reset --soft HEAD~1
git reset --mixed HEAD~1
git reset --hard HEAD~1

Reset modlarının branch, index ve working tree üzerindeki etkileri farklıdır. --hard commit edilmemiş çalışmayı yok edebilir.

Genel kural:

Yayınlanmış commit’leri geri almak için revert kullanın.
Sonuçları anladığınızda özel geçmişi yeniden düzenlemek için reset kullanın.

En İyi Uygulama 19: Cherry-Pick’i Bilinçli Kullanın

git cherry-pick, seçilen commit’lerin getirdiği değişikliği geçerli branch’e kopyalar.

Yararlı kullanım alanları:

Bir hata düzeltmesini eski sürüme taşımak.
Onaylanan tek bir değişikliği release branch’e uygulamak.
Terk edilmiş branch’ten yararlı bir commit’i kurtarmak.

Örnek:

git switch release/2.5
git cherry-pick -x abc1234

-x seçeneği uygun olduğunda orijinal commit kimliğini yeni mesaja kaydeder ve izlenebilirliği artırır.

Cherry-pick’i normal branch entegrasyonunun varsayılan alternatifi olarak kullanmayın. Değişiklikleri çoğaltır, ancak branch merge ilişkisini kaydetmez.

En İyi Uygulama 20: Secret’lar Geçmişe Girmeden Önce Koruyun

Asla şunları commit etmeyin:

Parolalar.
API anahtarları.
Özel token’lar.
Cloud kimlik bilgileri.
Özel SSH anahtarları.
Production ortam dosyaları.
Gerçek müşteri verisi içeren veritabanı dump’ları.
Özel sertifikalar.

Şunları kullanın:

Environment variable’ları.
Secret manager’ları.
CI/CD secret depolarını.
Git dışında bırakılan yerel yapılandırma dosyalarını.
Placeholder değerler içeren örnek dosyaları.

Örnek:

.env
.env.*
!.env.example

Bir secret commit edildiyse:

Hemen iptal edin veya yenileyin.
Geçerli dosyalardan kaldırın.
Geçmiş yeniden yazımının gerekip gerekmediğini değerlendirin.
Tüm katkıcılar ve deployment sistemleriyle koordinasyon kurun.
Monitoring ve olay kayıtlarını güncelleyin.

Secret’ı sonraki commit’te silmek, onu önceki geçmişten kaldırmaz.

En İyi Uygulama 21: .gitignore Dosyasını Doğru Kullanın

Depo düzeyindeki .gitignore ortak proje kurallarını içermelidir.

Yaygın girdiler:

# Ortam dosyaları
.env
.env.*

# Bağımlılıklar
vendor/
node_modules/

# Build çıktısı
dist/
build/

# Log’lar
*.log
storage/logs/

# Editör ve işletim sistemi dosyaları
.DS_Store
Thumbs.db

Önemli ilkeler:

.gitignore untracked dosyaları etkiler.
Daha önce commit edilmiş bir dosyanın takibini durdurmaz.
Proje için gerekli ignore kuralları depoya ait olmalıdır.
Kişisel editör pattern’ları global ignore dosyasında bulunabilir.

Bir dosyayı yerelde tutarken Git takibinden çıkarmak için:

git rm --cached .env

Ardından kaldırmayı commit edin ve açığa çıkan secret’ları yenileyin.

En İyi Uygulama 22: Depo Genelindeki Dosya Kuralları İçin .gitattributes Kullanın

.gitattributes, tüm clone’larda path davranışını tanımlar.

Örnek:

* text=auto

*.sh text eol=lf
*.bat text eol=crlf
*.cmd text eol=crlf

*.png binary
*.jpg binary
*.pdf binary

Şunlar için kullanın:

Satır sonu normalizasyonu.
Binary dosya tanımı.
Özel diff driver’ları.
Merge davranışı.
Export ayarları.
Git LFS path kuralları.

Depo düzeyindeki attributes, her geliştiricinin global ayarlarının aynı olduğunu varsaymaktan daha güvenilirdir.

En İyi Uygulama 23: Gereksiz Binary Dosyalardan Kaçının

Git metin dosyalarıyla en iyi şekilde çalışır; çünkü bunları verimli biçimde karşılaştırabilir ve merge edebilir.

Büyük binary dosyalar şu sorunları oluşturur:

Depo clone’ları büyür.
Değişen her sürüm geçmişte kalabilir.
Diff sınırlı olur veya hiç kullanılamaz.
Merge işlemi zorlaşır.
CI ve ağ işlemleri yavaşlar.

Gerekli büyük binary dosyalar için şunları değerlendirin:

Git LFS.
Artifact depoları.
Object storage.
Package registry’leri.
Kaynak koddan artifact üreten build pipeline’ları.

Deployment için gerekli diye build çıktısını commit etmeyin. Tekrarlanabilir build’leri ve bu amaç için tasarlanmış sistemlerde saklanan immutable artifact’leri tercih edin.

En İyi Uygulama 24: Gerekmedikçe Üretilmiş Bağımlılıkları Commit Etmeyin

Çoğu ekosistem, kurulmuş dependency dizinleri yerine dependency tanım ve lock dosyalarını takip eder.

Örnekler:

composer.json ve genellikle composer.lock dosyalarını takip edin; vendor/ dizinini ignore edin.
package.json ve seçilen lock dosyasını takip edin; node_modules/ dizinini ignore edin.
Dependency manifest’lerini takip edin; kurulu package’ları CI içinde yeniden oluşturun.

Deployment modelleri, vendored kütüphaneler, çevrimdışı build’ler ve gömülü ortamlar için istisnalar vardır. Üretilmiş dependency’ler bilerek commit ediliyorsa nedenini belgeleyin.

En İyi Uygulama 25: Lock Dosyalarını Tutarlı Tutun

Uygulamalar genellikle ekosistemin lock dosyasını commit etmekten yararlanır; çünkü bu dosya test edilmiş dependency sürümlerini kaydeder.

Yaygın sorunlar:

Manifest’i güncelleyip lock dosyasını güncellememek.
İlgisiz dependency değişikliklerini birleştirmek.
Dependency’leri yeniden kurmadan lock-file conflict’lerini manuel çözmek.
Birden fazla rakip lock-file biçimi kullanmak.

Dependency değişikliklerinden sonra:

Package manager’ın normal güncelleme komutunu çalıştırın.
Hem manifest hem lock değişikliklerini inceleyin.
Testleri ve build’leri çalıştırın.
Dependency güncellemesini odaklı tutun.

En İyi Uygulama 26: Git Hook’larını Dikkatli Kullanın

Git hook’ları önemli noktalarda kontroller çalıştırabilir.

Yararlı yerel hook’lar:

pre-commit: Formatting, linting ve secret taramaları.
commit-msg: Mesaj doğrulaması.
pre-push: Yayınlamadan önce testler.

Faydaları:

CI’dan önce hızlı geri bildirim.
Otomatik formatting.
Yanlışlıkla yapılan hataların azalması.
Tutarlı yerel doğrulama.

Sınırlamaları:

Hook’lar varsayılan olarak yereldir.
Geliştiriciler bunları atlayabilir.
Ağır hook’lar her commit veya push işlemini yavaşlatır.
Farklı ortamlar farklı davranabilir.

Kritik kurallar CI veya sunucu tarafı kontrollerinde de çalışmalıdır.

En İyi Uygulama 27: Otomatik Kontrolleri Hızlı ve İlgili Tutun

Zorunlu CI güvenilir geri bildirimi hızlıca sağlamalıdır.

Pratik bir pipeline şunları içerebilir:

Formatting kontrolleri.
Linting.
Statik analiz.
Unit testler.
Integration testleri.
Güvenlik taraması.
Build doğrulaması.
Migration doğrulaması.

Kötü CI uygulamaları:

Flaky zorunlu testler.
Her küçük dokümantasyon değişikliği için tüm pahalı testleri çalıştırmak.
Başarısız kontrolleri görmezden gelmek.
Bozuk pipeline’ları uzun süre bırakmak.
Kritik kontroller bitmeden merge işlemine izin vermek.

Uygun olduğunda path tabanlı veya katmanlı doğrulama kullanın; ancak pipeline daha hızlı görünsün diye kontrolleri zayıflatmayın.

En İyi Uygulama 28: Gerektiğinde Önemli Commit ve Tag’leri İmzalayın

Kriptografik imzalama, bir commit veya tag’in onaylı bir anahtarın sahibi tarafından oluşturulduğunu doğrulamaya yardımcı olabilir.

Commit imzalayın:

git commit -S -m "Ödeme callback düzeltmesini yayınla"

Tag imzalayın:

git tag -s v2.0.1 -m "2.0.1 sürümünü yayınla"

Tag’i doğrulayın:

git tag -v v2.0.1

İmzalama, Git nesnesi ve anahtar ilişkisi hakkında bir şey kanıtlar. Şunları kanıtlamaz:

Kodun güvenli olduğunu.
İncelemenin doğru olduğunu.
Build artifact’in kaynakla eşleştiğini.
Deployment’ın yetkilendirildiğini.

İmzalamayı güvenilir build, release ve artifact süreçleriyle birleştirin.

En İyi Uygulama 29: Sürümleri Açıkça Tag’leyin

Önemli yayınlanmış commit’leri tanımlamak için tag kullanın.

Resmî sürümlerde annotated veya signed tag tercih edin:

git tag -a v3.1.0 -m "3.1.0 sürümünü yayınla"
git push origin v3.1.0

Tag oluşturmadan önce:

Branch’i doğrulayın.
Commit’i doğrulayın.
Working tree’nin temiz olduğundan emin olun.
Release testlerini çalıştırın.
Version numarasını doğrulayın.
Yayınlamadan önce tag’i inceleyin.

Yayınlanmış release tag’lerini immutable kabul edin. Bir release tag’ini taşımak clone’lar, cache’ler, build sistemleri ve deployment’lar arasında tutarsız kimlikler oluşturur.

En İyi Uygulama 30: Reflog’u Kurtarma Aracı Olarak Kullanın

Branch beklenmedik biçimde hareket ettiğinde veya commit normal geçmişten kaybolduğunda şunu inceleyin:

git reflog

Yararlı kurtarma durumları:

Yanlışlıkla yapılan reset.
Hatalı amend işlemi.
Beklenen commit’leri kaldıran rebase.
Silinen yerel branch.
Detached-HEAD commit’i.

Adayı inceleyin:

git show HEAD@{2}

Koruyun:

git branch recovery HEAD@{2}

Reflog’lar yerel ve geçicidir. Normal commit’lerin, remote kopyaların veya yedeklerin yerine geçmez.

En İyi Uygulama 31: Katmanları Anlamadan Yıkıcı Komutlar Kullanmayın

Şu komutlar çalışmayı silebilir:

git reset --hard
git clean -fd
git restore .
git checkout -- .
git branch -D
git push --force

Bunları kullanmadan önce:

git status çalıştırın.
Hedef revision’ı inceleyin.
Untracked dosyaları kontrol edin.
Uygun olduğunda geçici branch veya stash oluşturun.
Çalışmanın başka bir yerde bulunup bulunmadığını doğrulayın.

Varsa önizleme modlarını kullanın:

git clean -nd

Bu, git clean komutunun neleri sileceğini silmeden gösterir.

En İyi Uygulama 32: Stash’i Kalıcı Depolama Olarak Kullanmayın

Stash geçici yerel çalışma için kullanışlıdır; uzun vadeli proje yönetimi için değildir.

Eski stash’lerin sorunları:

Belirsiz amaç.
Yeni kodla conflict.
Normal branch görünürlüğünün olmaması.
Remote iş birliğinin olmaması.
Yanlışlıkla temizlenme riski.

Önemli çalışmayı branch’e dönüştürün:

git stash branch feature/recovered-work stash@{0}

Ardından odaklı commit’ler oluşturun.

En İyi Uygulama 33: Tamamlanan Branch’leri Silin

Entegrasyondan sonra kısa ömürlü branch’leri kaldırın.

Güvenle merge edilmiş yerel branch’i silin:

git branch -d feature/task-search

Remote branch’i silin:

git push origin --delete feature/task-search

Eski branch’ler neyin aktif olduğunu anlamayı zorlaştırır.

Force deletion öncesinde:

git log --oneline main..feature/task-search
git branch --contains feature/task-search

Benzersiz çalışmanın başka yerde korunduğunu doğrulayın.

En İyi Uygulama 34: Eski Remote-Tracking Referanslarını Prune Edin

Başkaları tarafından silinen remote branch’ler yerelde eski remote-tracking referansları bırakabilir.

Fetch edip prune edin:

git fetch --prune

Veya tek bir remote’u prune edin:

git remote prune origin

Ekip tercihine uygunsa otomatik pruning ayarlayın:

git config --global fetch.prune true

Pruning eski remote-tracking referanslarını kaldırır. Aktif remote branch’leri silmez.

En İyi Uygulama 35: Depo Performansını Koruyun

Git birçok ortamda bakımı otomatik yapar; ancak büyük veya uzun ömürlü depolar dikkat gerektirebilir.

Yararlı komutlar:

git count-objects -vH
git gc
git maintenance run
git fsck

Kullanım alanları:

git count-objects: Loose object ve pack kullanımını incelemek.
git gc: Depo verisini optimize edip temizlemek.
git maintenance: Bakım görevlerini çalıştırmak.
git fsck: Nesne bağlantısını ve geçerliliğini kontrol etmek.

Unreachable nesneleri kurtarmaya çalışırken agresif temizlik çalıştırmayın. Bakım, reflog veya nesne kurtarma araçlarının bulabileceği verileri kaldırabilir.

En İyi Uygulama 36: Çok Büyük Depolarda Sparse Checkout veya Partial Clone Kullanın

Büyük monorepo’ların clone ve checkout maliyeti yüksek olabilir.

Seçenekler:

Partial clone.
Sparse checkout.
Sınırlı CI senaryolarında shallow clone.
Mimari destekliyorsa depoyu bölmek.

Örnek sparse-checkout kurulumu:

git sparse-checkout init --cone
git sparse-checkout set services/billing shared

Bu tekniklerin ödünleşimleri vardır. Bazı komutlar ve araçlar shallow veya partial geçmişle farklı davranır. Bilinçli kullanın ve ekip beklentilerini belgeleyin.

En İyi Uygulama 37: Kimlik Tutarlılığı İçin .mailmap Kullanın

Geliştiriciler farklı adlar veya e-posta adresleriyle görünebilir.

.mailmap dosyası git shortlog gibi komutlarda kimlikleri normalize edebilir.

Örnek:

Jane Developer <jane@company.example> <jane.old@example.com>

Bu, mevcut commit’leri yeniden yazmadan katkıcı özetlerini iyileştirir.

En İyi Uygulama 38: Depoya Özel Git Kurallarını Belgeleyin

Yazılı olmayan ekip alışkanlıklarına güvenmeyin.

Yararlı dosyalar:

CONTRIBUTING.md
docs/git-workflow.md
docs/release-process.md
CODEOWNERS

Şunları belgeleyin:

Branch adlandırması.
Varsayılan branch beklentileri.
Commit mesajı stili.
Zorunlu kontroller.
İnceleme gereksinimleri.
Merge yöntemleri.
Release tag’leri.
Hotfix ve backport süreçleri.
Force-push politikası.
Secret yönetimi kuralları.

Kısa ve uygulanan bir politika, kimsenin takip etmediği uzun bir belgeden daha iyidir.

En İyi Uygulama 39: CODEOWNERS ve İnceleme Sorumluluğu Kullanın

Büyük depolar açık inceleme sahipliğinden yararlanır.

CODEOWNERS dosyası, desteklenen hosting platformlarında path’leri sorumlu inceleyenlerle ilişkilendirebilir.

Örnek:

/src/Payments/ @payments-team
/database/migrations/ @backend-team
/docs/ @documentation-team

Sahiplik silo oluşturmamalıdır. Hassas alanların bilgili kişiler tarafından incelenmesini sağlarken mimari bilginin paylaşılmasına da izin vermelidir.

En İyi Uygulama 40: Yalnızca Sözdizimini Değil, Daha Fazlasını İnceleyin

Yararlı bir kod incelemesi şunları kontrol eder:

Doğruluk.
Güvenlik.
Hata yönetimi.
Testler.
Performans.
Veri migration güvenliği.
Geriye uyumluluk.
Observability.
Sürdürülebilirlik.
Deployment etkisi.

Git diff’i gösterir; ancak inceleyenlerin çevredeki sistemi anlaması gerekir.

Küçük bir sözdizimi değişikliği büyük operasyonel risk oluşturabilir. Büyük bir üretilmiş diff ise çok az anlamlı mantık içerebilir.

En İyi Uygulama 41: Formatting ile İşlevsel Değişiklikleri Karıştırmayın

Bir feature branch içinde tüm dosyaları yeniden biçimlendirmek gürültülü diff’ler oluşturur.

Şunları tercih edin:

Feature çalışmasından önce otomatik formatting.
Ayrı formatting commit’i.
Depo genelinde formatter yapılandırması.
Stil sapmasını önleyen CI kontrolleri.

Bu, işlevsel değişiklikleri inceleme sırasında görünür tutar ve blame geçmişini iyileştirir.

En İyi Uygulama 42: Veritabanı Değişikliklerini Deploy Edilebilir Hale Getirin

Veritabanı migration’ları özel Git disiplini gerektirir.

İyi uygulamalar:

Rollout sırasında schema ve uygulama değişikliklerini uyumlu tutun.
Eski kod yollarını kaldıran deployment ile aynı anda yıkıcı değişikliklerden kaçının.
Rollback destekleniyorsa ileri ve geri prosedürlerini test edin.
Proje açıkça izin vermedikçe geniş ölçüde uygulanmış migration’ları düzenlemeyin.
Gerekirse veri backfill işlemlerini schema tanımlarından ayırın.
Operasyon sırasını belgeleyin.

Deployment sırası uygulamayı bozuyorsa temiz bir Git commit tek başına yeterli değildir.

En İyi Uygulama 43: Deployment Provenance Kaydedin

Ekipler her ortama tam olarak hangi commit ve artifact’in ulaştığını bilmelidir.

Yararlı tanımlayıcılar:

Commit hash’i.
Release tag’i.
Build numarası.
Container digest’i.
Artifact checksum’ı.

Branch’ler hareket ettiği için yalnızca branch adı yeterli değildir.

Deployment sistemleri immutable tanımlayıcıları kaydetmelidir.

En İyi Uygulama 44: Tekrarlanan Depo Görevleri İçin Otomasyon Kullanın

Otomasyon şunları yönetebilir:

Merge edilmiş branch’leri silmek.
Release note’ları oluşturmak.
Version tag’leri oluşturmak.
Changelog’ları güncellemek.
Dependency güncellemelerini çalıştırmak.
Eski branch’leri kontrol etmek.
Commit veya pull request kurallarını doğrulamak.

Otomasyon manuel hataları azaltmalı, önemli kararları gizlememelidir. Release tag’leri, migration’lar ve yıkıcı temizlik işlemleri yine açık sahiplik ve denetlenebilirlik gerektirir.

En İyi Uygulama 45: Geçmişi Yapay Olarak Kusursuz Değil, Kullanışlı Tutun

Yararlı bir geçmiş şu özelliklere sahip olmalıdır:

Anlaşılır.
İzlenebilir.
İncelenebilir.
Kurtarılabilir.
Ekip iş akışıyla tutarlı.

Matematiksel olarak kusursuz görünmesi gerekmez.

Geçmişi aşırı optimize etmek şu sorunları oluşturabilir:

Aşırı rebase.
İş birliği bağlamının kaybı.
Force-push riski.
İnceleme sonrasında küçük commit ayrıntılarını düzeltmek için harcanan zaman.

Yararlı olduğunda paylaşmadan önce özel geçmişi temizleyin. Entegrasyondan sonra kararlı paylaşılan geçmişi koruyun.

Pratik Bir Günlük Git İş Akışı

1. Base’i Güncelleyin

git switch main
git fetch origin
git merge --ff-only origin/main

2. Odaklı Bir Branch Oluşturun

git switch -c fix/payment-timeout

3. Küçük Adımlarla Çalışın

git status
git diff
git add -p
git diff --staged
git commit -m "Ödeme sağlayıcısı zaman aşımını artır"

4. Testleri Çalıştırın

# Projenin gerçek komutlarını kullanın
php vendor/bin/phpunit
npm test

5. Branch’i İnceleyin

git log --oneline main..HEAD
git diff --stat main...HEAD
git diff main...HEAD

6. Push Edin ve İnceleme Açın

git push -u origin fix/payment-timeout

7. İncelemeye Yanıt Verin

Ekip politikasına göre odaklı takip commit’leri oluşturun veya özel commit’leri amend edin.

8. Merge Edin ve Temizleyin

git switch main
git pull --ff-only
git branch -d fix/payment-timeout

Manuel Uygulama: Karışık Working Tree’yi Temizlemek

Working tree’nin şunları içerdiğini varsayın:

Bir ödeme hatası düzeltmesi.
Bir README iyileştirmesi.
Geçici debug çıktısı.

İnceleyin:

git status
git diff

Yalnızca hata düzeltmesini stage edin:

git add -p src/PaymentService.php
git add tests/PaymentServiceTest.php

İnceleyin:

git diff --staged

Commit oluşturun:

git commit -m "Yinelenen ödeme denemelerini önle"

İstenmeyen debug çıktısını working tree’den kaldırın veya dokümantasyon commit’ini hazırlarken unstaged bırakın.

Dokümantasyonu ayrı stage edin:

git add README.md
git commit -m "Ödeme yeniden deneme yapılandırmasını belgele"

Sonuç, tek karışık snapshot yerine iki odaklı commit olur.

Manuel Uygulama: Yanlışlıkla Yapılan Reset’ten Kurtulmak

Bir branch’in reset edildiğini ve en son commit’in kaybolduğunu varsayın.

Reflog’u inceleyin:

git reflog

Önceki branch konumunu bulun:

git show HEAD@{1}

Koruyun:

git branch recovery/payment-fix HEAD@{1}

Doğrulayın:

git log --oneline --graph --decorate --all

Daha fazla geçmiş değiştiren komut çalıştırmadan önce bir recovery branch oluşturun.

Manuel Uygulama: Yeniden Yazılmış Feature Branch’i Güvenle Güncellemek

Özel bir branch’in rebase edildiğini varsayın:

git rebase main

Yeni geçmişi inceleyin:

git log --oneline --graph --decorate main..HEAD

Remote’u lease ile güncelleyin:

git push --force-with-lease

Başka bir geliştirici remote branch’e yeni commit’ler push ettiyse lease üzerine yazmayı reddetmeli ve ekibin çalışmayı uzlaştırmasına izin vermelidir.

Yaygın Git Hataları

Her Şeyi Tek Seferde Commit Etmek

Bu, karışık geçmiş oluşturur ve inceleme ile kurtarmayı zorlaştırır.

Belirsiz Commit Mesajları Kullanmak

update gibi mesajlar yararlı tarihsel bağlam sağlamaz.

Politika Olmadan Doğrudan Main Üzerinde Çalışmak

Bu, incelemeyi ve zorunlu kontrolleri atlayabilir.

Feature Branch’leri Haftalarca Açık Bırakmak

Ayrışma ve entegrasyon riski zamanla artar.

Paylaşılan Branch’lere Force Push Uygulamak

Bu, diğer geliştiricilerin görünür geçmişini silebilir.

Secret’ları Commit Etmek

Sonraki bir silme işlemi onları önceki commit’lerden kaldırmaz.

CI Hatalarını Görmezden Gelmek

Başarısızlıklar rutin olarak kabul edildiğinde zorunlu kontroller değerini kaybeder.

Yayınlanmış Geçmişte Reset Kullanmak

Bu, branch konumunu yeniden yazar ve iş arkadaşlarını etkileyebilir.

Benzersiz Commit’leri Kontrol Etmeden Branch Silmek

Önemli çalışmayı bulmak zorlaşabilir.

Gerek Olmadan Üretilmiş Dosyaları Commit Etmek

Bu, depo boyutunu artırır ve gürültülü diff’ler oluşturur.

Birden Fazla Merge Stilini Rastgele Kullanmak

Geçmiş tutarsız ve yorumlanması zor hale gelir.

Reflog’u Yedek Olarak Görmek

Reflog yerel ve geçicidir.

Ekip Git Politikası Örneği

Varsayılan branch:
- main

Branch adları:
- feature/<açıklama>
- fix/<açıklama>
- docs/<açıklama>
- hotfix/<açıklama>

Commit kuralları:
- Her commit’te tek mantıksal değişiklik
- Açık ve eylem odaklı başlık
- Secret veya üretilmiş dependency yok

Pull request kuralları:
- Main branch’e doğrudan push engellenir
- En az bir onay gerekir
- CI, statik analiz ve testler geçmelidir
- Pull request’ler odaklı ve küçük kalmalıdır

Merge politikası:
- Normal feature branch’ler için squash merge
- Release ve uzun ömürlü maintenance branch’leri için merge commit
- Yalnızca özel feature geçmişinde rebase

Release politikası:
- Annotated veya signed tag’ler
- Tag’ler test edilmiş commit’leri tanımlar
- Yayınlanmış tag’ler immutable kabul edilir

Güvenlik:
- Paylaşılan geçmiş için revert kullan
- Onaylanmış yeniden yazılmış feature branch’lerde force-with-lease kullan
- Main branch’e force push yok

Git En İyi Uygulamaları Kontrol Listesi

Commit oluşturmadan önce:

Geçerli branch doğrudur.
Commit tek bir mantıksal değişiklik içerir.
Staged diff incelenmiştir.
Hiçbir secret veya üretilmiş dosya stage edilmemiştir.
İlgili testler geçer.
Commit mesajı amacı açıklar.

Pull request açmadan önce:

Branch doğru base’den başlar.
Pull request odaklıdır.
Branch diff’i geliştirici tarafından incelenmiştir.
CI geçer.
Test ve migration konuları belgelenmiştir.
Geçici debug kodu kalmamıştır.

Merge etmeden önce:

Gerekli onaylar tamamlanmıştır.
Zorunlu kontroller geçer.
Merge yöntemi ekip politikasına uygundur.
Hedef branch doğrudur.
Release ve deployment etkisi anlaşılmıştır.

Geçmişi yeniden yazmadan veya silmeden önce:

Commit’ler özeldir veya ekip koordinasyon sağlamıştır.
Önemli çalışma başka yerde korunur.
Remote durumu anlaşılmıştır.
Uygun olduğunda kör force yerine --force-with-lease kullanılır.
Recovery branch veya reflog referansı bulunur.

Sık Sorulan Sorular

Ne Sıklıkla Commit Oluşturmalıyım?

Mantıksal bir değişiklik tamamlanıp anlaşılır hale geldiğinde commit oluşturun. Hem gün sonunda tek dev commit’ten hem de kaydedilen her satır sonrası anlamsız commit’lerden kaçının.

Her Commit Tüm Testleri Geçmeli mi?

Her commit ideal olarak kullanılabilir ve test edilebilir bir durumu korumalıdır. En azından belgelenmiş bir neden olmadan temel depo varsayımlarını bilerek bozmamalıdır.

git add . Kullanmalı mıyım?

Geçerli tüm değişiklikler birlikteyse kabul edilebilir; ancak sonrasında mutlaka git status ve git diff --staged çıktısını inceleyin.

Tüm Commit’leri Squash Etmeli miyim?

Hayır. Tek mantıksal mainline commit istendiğinde gürültülü veya geçici branch geçmişini squash edin. Geçmişi iyileştiren anlamlı ve bağımsız commit’leri koruyun.

Rebase Merge’den Daha mı İyi?

Hiçbiri evrensel olarak daha iyi değildir. Rebase yeni commit’ler oluşturur ve doğrusal geçmiş sağlayabilir. Merge mevcut geçmişi korur ve entegrasyonu kaydeder. Ekibin belgelenmiş politikasını izleyin.

Force Push Ne Zaman Kabul Edilebilir?

Genellikle yalnızca özel veya açıkça yeniden yazılabilir feature branch üzerinde. --force-with-lease tercih edin. Korumalı paylaşılan branch’lere force push uygulamayın.

Bir Secret Commit Ettikten Sonra Ne Yapmalıyım?

Hemen yenileyin veya iptal edin. Ardından geçerli dosyalardan kaldırın, geçmiş temizliğini değerlendirin ve ekip ile etkilenen sistemlerle koordinasyon kurun.

.env.example Dosyasını Commit Etmeli miyim?

Evet; güvenli placeholder anahtarları içeriyor ve gerekli yapılandırmayı belgeliyorsa. İçine gerçek secret değerler koymayın.

Lock Dosyalarını Commit Etmeli miyim?

Uygulamalar genellikle etmelidir. Kütüphaneler ekosisteme özgü politikaları izleyebilir. Ekip kararı belgelemelidir.

Merge Edilmiş Branch’leri Silmeli miyim?

Evet, kısa ömürlü çalışmalar için. Bu, depoyu anlamayı kolaylaştırır. Uzun ömürlü release veya maintenance branch’lerini yalnızca aktif bir amaca hizmet ediyorsa koruyun.

Temiz Doğrusal Geçmiş Her Zaman Daha mı İyidir?

Hayır. Okunabilir geçmiş, kusursuz düz bir grafikten daha önemlidir. Merge commit’ler değerli entegrasyon bağlamını koruyabilir.

Git Bir Yedekleme Sisteminin Yerini Alabilir mi?

Hayır. Git; veritabanlarını, yüklenen dosyaları, harici servisleri veya commit edilmemiş tüm yerel değişiklikleri değil, commit edilmiş depo geçmişini korur.

Yeni Ekip Üyeleri İçin Git’i Nasıl Kolaylaştırabilirim?

İş akışını belgeleyin, kurulumu ve doğrulamayı otomatikleştirin, tutarlı branch ve commit kuralları kullanın ve depo geçmişini anlaşılır tutun.

Sonuç

Git en iyi uygulamaları en fazla sayıda komutu ezberlemekle ilgili değildir. Belirsizliği azaltmakla ilgilidir.

Temiz bir commit tek bir mantıksal değişikliği açıklar. İyi bir branch tek bir amacı tanımlar. Yararlı bir pull request incelenebilecek kadar küçüktür. Sağlıklı bir varsayılan branch gerekli kontrolleri geçer. Güvenli bir depo secret’ları geçmişin dışında tutar, açık release tag’leri kullanır ve paylaşılan commit’leri koordinasyon olmadan yeniden yazmaz.

En güvenilir günlük düzen basittir: depoyu inceleyin, working diff’i gözden geçirin, bilinçli biçimde stage edin, staged diff’i inceleyin, değişikliği test edin, anlamlı bir mesajla commit oluşturun ve ekip inceleme süreci üzerinden yayınlayın.

Ekipler için en değerli iyileştirmeler tutarlılık ve uygulamadır. İş akışını belgeleyin, önemli branch’leri koruyun, tekrarlanabilir kontrolleri otomatikleştirin, merge ve release politikalarını tanımlayın ve süreci ürünün gerektirdiğinden daha karmaşık hale getirmeyin.

Git temelleri serisinin son makalesi; depolar, commit’ler, branch’ler, remote’lar, merge, rebase, tag, stash, kurtarma ve iş birliği genelinde kullanılan temel terimleri birbirine bağlayan eksiksiz bir Git sözlüğü sunacaktır.

Resmî Kaynaklar ve Ek Okumalar