Gitflow
- Okunuşu
- git flo
Kısaca
Gitflow, planlı sürümleri yönetmek için uzun ömürlü main ve develop branch'lerini feature, release ve hotfix branch'leriyle kullanan bir Git branch modelidir.
Gitflow nedir?
Gitflow, Vincent Driessen'in 2010'da 'A successful Git branching model' başlıklı bir blog yazısında anlattığı bir branch stratejisidir. Her iş türüne kendi branch türünü verir ve branch'in nereden başlayıp nereye geri birleşeceğine dair katı kurallar koyar. Model, masaüstü uygulamaları, mobil uygulamalar ve kütüphaneler gibi belirli bir takvimle numaralı sürümler olarak yayımlanan yazılımlar için tasarlanmıştır.
İki branch sonsuza dek yaşar: main (aslen master) yalnızca yayımlanmış kodu tutar ve her sürüm bir tag ile işaretlenir, develop ise bir sonraki sürüm için tamamlanmış özellikleri toplar. Feature branch'leri develop'tan başlar ve ona geri birleşir; yeterli sayıda özellik hazır olduğunda son testler ve sürüm numarası artırımları için develop'tan bir release branch'i çıkarılır, ardından hem main'e hem de develop'a birleştirilir. Acil canlı düzeltmeleri main'den oluşturulan hotfix branch'lerine yapılır ve bunlar da her ikisine birleştirilir.
Gitflow bir yayınevi gibi çalışır: yazarlar bölümleri feature branch'lerinde ayrı ayrı yazar, bir editör bir sonraki baskıyı develop'ta bir araya getirir, bir düzeltme aşaması baskıdan önce onu bir release branch'inde dondurur ve basılmış nüshalar hemen hotfix'ler olarak düzeltme listeleriyle onarılır. İsteğe bağlı komut satırı uzantıları git flow feature start gibi kısayollar sunar, ancak modelin kendisi sıradan Git komutları üzerine kurulu bir adlandırma ve birleştirme geleneğinden ibarettir.
Gitflow en sık, herkesin küçük değişiklikleri en az günde bir kez tek bir main branch'ine birleştirdiği trunk-based development ile karşılaştırılır. Gitflow'un uzun ömürlü branch'leri ve toplu sürümleri merge işini artırır ve geri bildirimi geciktirir; bu da sürekli teslimatla pek uyuşmaz ve 2020'de yazarı, sürekli dağıtılan web uygulamaları için daha basit iş akışlarını öneren bir not ekledi. Aynı anda birkaç yayımlanmış sürümü desteklemesi gereken ürünler için makul bir seçenek olmaya devam eder.
Önemli noktalar
- Gitflow iki kalıcı branch kullanır: yayımlanmış kod için
mainve yaklaşan işler içindevelop. - Feature branch'leri
develop'tan çıkar, release branch'leri bir sürümü hazırlar, hotfix branch'leri canlıyı yamalar. - Release ve hotfix branch'leri hem
main'e hem dedevelop'a birleştirilir ve her sürüm etiketlenir. - Sürekli dağıtımdan çok, sürümlü ve planlı yayınlara uygundur.
- Trunk-based development ana hafif alternatiftir.
Örnek
# Start a feature from develop and merge it back when done
git switch -c feature/cart develop
git switch develop && git merge --no-ff feature/cart
# Cut a release branch, then merge it into main and back into develop
git switch -c release/1.4.0 develop
git switch main && git merge --no-ff release/1.4.0
git tag -a v1.4.0 -m "Release 1.4.0"
git switch develop && git merge --no-ff release/1.4.0
# Fix production with a hotfix branch made from main
git switch -c hotfix/1.4.1 main
git switch main && git merge --no-ff hotfix/1.4.1
git tag -a v1.4.1 -m "Hotfix 1.4.1"
git switch develop && git merge --no-ff hotfix/1.4.1Sık sorulan sorular
Gitflow ile trunk-based development arasındaki fark nedir?
Gitflow, uzun ömürlü main ve develop branch'lerini tutar ve işi feature, release ve hotfix branch'leri üzerinden gruplar halinde ilerletir. Trunk-based development ise herkesin sürekli küçük değişiklikler birleştirdiği tek bir ana branch'e sahiptir; bu da sık dağıtım yapan ekiplere uygundur.
Gitflow hâlâ kullanılıyor mu?
Evet, özellikle mobil uygulamalar, kurulan yazılımlar ve eski sürümleri sürdüren kütüphaneler gibi sürümlü yayınları olan ürünlerde. Sürekli dağıtım yapan birçok web ekibi, tek bir ana branch ve kısa ömürlü feature branch'lerden oluşan daha basit iş akışlarına geçti.
Gitflow'daki develop branch'i nedir?
develop, tamamlanmış özelliklerin bir sonraki sürümü beklerken birleştirildiği entegrasyon branch'idir. main koda yalnızca release ve hotfix branch'leri aracılığıyla ulaşır; böylece her zaman canlıda olanı yansıtır.
İlgili sayfalar
- Trunk-Based DevelopmentSürüm Kontrolü, s. 39Trunk-based development, geliştiricilerin küçük değişiklikleri en az günde bir kez ortak ana branch'e birleştirip onu hep yayımlanabilir tuttuğu stratejidir.
- BranchSürüm Kontrolü, s. 2Git'te branch, bir özellik ya da düzeltme üzerinde, birleştirene kadar ana kodu etkilemeden çalışmanızı sağlayan bağımsız bir geliştirme hattıdır.
- MergeSürüm Kontrolü, s. 29Git'te merge, bir branch'teki değişiklikleri başka bir branch'e katarak ayrı geliştirme hatlarını tek ve ortak bir geçmişte yeniden birleştirir.
- Git TagSürüm Kontrolü, s. 23Git tag, belirli bir commit'i gösteren adlandırılmış kalıcı bir işaretçidir; çoğunlukla deponun geçmişinde v1.0.0 gibi sürümleri işaretlemek için kullanılır.
- Semantic VersioningSürüm Kontrolü, s. 35Semantic versioning, her bölümün bir sürümün uyumluluğu bozduğunu, özellik eklediğini ya da hata düzelttiğini belirttiği MAJOR.MINOR.PATCH şemasıdır.
- Pull RequestSürüm Kontrolü, s. 32Pull request, bir branch'teki değişiklikleri başka bir branch'e birleştirme önerisidir; kod birleşmeden önce ekibe inceleme, tartışma ve test alanı sunar.
- HotfixSürüm Kontrolü, s. 28Hotfix, çökme ya da güvenlik açığı gibi production'daki ciddi bir sorun için hızla ve olağan sürüm takviminin dışında yayımlanan acil bir düzeltmedir.
Bu sayfada bir hata ya da eksik mi gördünüz?Düzeltme önerin