Branch (Dal) Nedir?
Kısa tanım
Branch (dal), Git'te bir commit'i gösteren ve üzerine yeni commit eklendikçe ileri kayan hafif bir işaretçidir. Ana koddan bağımsız bir çalışma hattı açar: yeni bir özellik ya da düzeltme ayrı bir branch'te geliştirilir ve hazır olduğunda merge ile ana branch'e birleştirilir. Aynı satırlar iki tarafta farklı şekilde değiştirilmişse merge conflict oluşur; hangi değişikliğin kalacağına bir insan karar verir.
Diğer adları: dal, Git branch, feature branch, merge, merge conflict, branching stratejisi
Branch aslında bir işaretçi
Branch denince akla kodun bir kopyası gelir, ama Git'te branch yalnızca bir commit'in kimliğini tutan küçük bir referanstır. Yeni bir branch açmak dosyaları kopyalamaz; bu yüzden anlık ve neredeyse bedavadır. Siz o branch'teyken attığınız her commit, işaretçiyi bir adım ileri taşır. HEAD ise o anda hangi branch'te olduğunuzu gösterir.
git switch -c ozellik/iletisim-formu # yeni branch aç ve ona geç
git branch # yerel branch'leri listele
git switch main # ana branch'e dönBu ucuzluk, çalışma biçimini belirler: her iş için ayrı bir branch açılır, ana branch (main) her zaman yayına alınabilir durumda tutulur ve yarım işler oraya karışmaz.
Merge: iki hattı birleştirmek
Branch'teki iş bittiğinde ana branch'e birleştirilir. İki temel durum vardır:
- Fast-forward: Siz çalışırken ana branch'e yeni commit gelmediyse, Git işaretçiyi sizin son commit'inize kaydırır. Ayrı bir birleştirme commit'i oluşmaz.
- Üç yönlü merge: İki taraf da ilerlediyse Git, ortak ata commit'i ve iki ucu karşılaştırır, değişiklikleri birleştirir ve iki ebeveynli bir merge commit'i oluşturur.
Alternatif olarak rebase, sizin commit'lerinizi ana branch'in güncel ucunun üzerine yeniden yazarak düz bir geçmiş üretir. Rebase, başkalarıyla paylaşılmış commit'lerin kimliğini değiştirdiği için ortak branch'lerde dikkatli kullanılmalıdır.
Merge conflict neden çıkar, nasıl çözülür?
Git, iki branch'in farklı dosyalara ya da aynı dosyanın farklı bölgelerine yaptığı değişiklikleri kendisi birleştirir. Ama iki taraf aynı satırları farklı biçimde değiştirmişse hangisinin doğru olduğunu bilemez ve kararı size bırakır:
<<<<<<< HEAD
const MAX_DOSYA_MB = 10;
=======
const MAX_DOSYA_MB = 25;
>>>>>>> ozellik/buyuk-dosya-yukleme- İki değişikliğin amacını anlayın; çoğu zaman doğru sonuç ikisinin bileşimidir, birini körlemesine seçmek değil.
- Dosyayı düzenleyip çakışma işaretlerini (
<<<<<<<,=======,>>>>>>>) tamamen kaldırın. - Testleri çalıştırın; derlenen ama yanlış davranan bir birleştirme, conflict'in kendisinden daha tehlikelidir.
git addile çözümü işaretleyip merge'i tamamlayın.
En iyi önlem conflict'i küçük tutmaktır: kısa ömürlü branch'ler, ana branch'ten sık güncelleme almak ve küçük pull request'ler. Haftalarca yaşayan bir branch'in birleştirilmesi, her gün biraz birleşen beş branch'ten çok daha zahmetlidir.
Branching stratejileri
| Strateji | Nasıl işler? | Uygun olduğu durum |
|---|---|---|
| Trunk-based development | Herkes ana branch'e çok sık, küçük değişikliklerle birleştirir; branch'ler saatler veya birkaç gün yaşar, yarım özellikler feature flag ile gizlenir | Olgun test otomasyonu ve sürekli dağıtım yapan ekipler |
| GitHub flow | Tek uzun ömürlü branch (main); her iş için bir branch ve pull request, onaydan sonra merge ve yayın | Web uygulamalarının çoğu, küçük ve orta ekipler |
| Git Flow | develop, release ve hotfix gibi ek uzun ömürlü branch'ler | Numaralı sürümlerle dağıtılan, birden çok sürümü aynı anda destekleyen yazılımlar |
Sürekli yayına alınan bir web sitesi için Git Flow çoğu zaman gereğinden ağırdır; ek branch'ler birbirinden uzaklaştıkça birleştirme maliyeti artar.
Branch'ler ve ortamlar
Pek çok ekipte branch'ler doğrudan ortamlara bağlanır: her pull request için otomatik bir önizleme ortamı kurulur, main'e yapılan merge CI/CD hattı üzerinden önce staging ortamına, onaydan sonra canlıya gider. Her ortam için ayrı ve uzun ömürlü branch tutmak (ör. staging ve production branch'leri) ise zamanla ortamlar arasında fark edilmeyen kod farklılıklarına yol açabilir; aynı commit'in ortamlar arasında terfi ettirildiği bir deployment düzeni genellikle daha öngörülebilirdir.