Git Flow, projelerde düzenli ve tutarlı bir iş akışı sağlamak için kullanılan bir modeldir. Bu model, özellikle büyük projelerde ve karmaşık geliştirme süreçlerinde faydalıdır. Şimdi GitHub’da Git Flow sürecini adım adım anlatalım.

Git Flow Nedir?

Git Flow, Vincent Driessen tarafından 2010 yılında önerilen bir dallanma modelidir. Bu model, projenin farklı aşamalarında düzenli bir iş akışı sağlar ve geliştiricilerin koordineli çalışmasına yardımcı olur. Git Flow’un temelinde iki ana dal ve üç destek dalı bulunur:

• Master (Ana Dal): Üretimde çalışan ve her zaman stabil olan kod tabanını temsil eder. Bu dal, yeni sürümlerin yayınlandığı yerdir.
• Develop (Geliştirme Dalı): Yeni özelliklerin ve değişikliklerin birleştirildiği ana daldır. Geliştiriciler, bu dal üzerinden yeni özellikler geliştirir ve test eder.
• Feature (Özellik Dalları): Her yeni özellik için oluşturulan geçici dallardır. Bu dallar, develop dalından oluşturulur ve tamamlandıktan sonra develop ile birleştirilir.
• Release (Yayın Dalı): Yayına hazırlanmak için yapılan son düzenlemelerin toplandığı daldır. Bu dal, master’a merge edilir ve yeni bir sürüm oluşturur.
• Hotfix (Hata Düzeltme Dalları): Üretimde karşılaşılan kritik hataları düzeltmek için master dalından oluşturulur.

Git Flow Süreci

Aşağıdaki adımlarla Git Flow sürecini uygulayabilirsiniz:

1. Proje Hazırlığı:
   • Projenizi GitHub’da oluşturun veya var olan bir projeyi kullanın.
   • Yerel makinenize projeyi klonlayın: git clone https://github.com/kullanici_adi/proje_adi.git
2. Develop Dalını Oluşturma:
   • Projenizde develop dalını oluşturun: git branch develop
   • Develop dalına geçin: git checkout develop
3. Özellik Geliştirme:
   • Yeni bir özellik dalı oluşturun: git checkout -b feature/yeni-ozellik
   • Değişikliklerinizi yapın, commitleyin ve pushlayın:

1
2
3

git add .
git commit -m "Yeni özellik eklendi"
git push origin feature/yeni-ozellik

4. Pull Request Oluşturma:
   • GitHub’da feature dalınız için bir pull request oluşturun. Bu, kodunuzu takım arkadaşlarınızla paylaşmanızı sağlar.
   • Kod gözden geçirme ve test süreçlerini tamamlayın.
5. Feature Dalını Develop ile Birleştirme:
   • Kod gözden geçirme ve testler tamamlandıktan sonra, feature dalını develop ile birleştirin:

1
2

git checkout develop
git merge feature/yeni-ozellik

6. Yayın Hazırlığı:
   • Projeniz yeterli sayıda özellik birleştirdiğinde, bir release dalı oluşturun: git checkout -b release/v1.0
   • Son düzenlemeleri yapın ve commitleyin:

1
2
3

git add .
git commit -m "Yayın için son düzenlemeler"
git push origin release/v1.0

7. Yayın Dalını Master ile Birleştirme:
   • Release dalını master ile birleştirin ve yeni bir sürüm oluşturun:

1
2
3
4

git checkout master
git merge release/v1.0
git tag -a v1.0 -m "İlk sürüm"
git push origin master --tags

8. Hata Düzeltme:
   • Üretimde karşılaşılan kritik hataları düzeltmek için hotfix dalı oluşturun: git checkout -b hotfix/critical-bug
   • Hataları düzeltin, commitleyin ve pushlayın:

1
2
3

git add .
git commit -m "Kritik hata düzeltildi"
git push origin hotfix/critical-bug

- Hotfix dalını master ve develop ile birleştirin:

1
2
3
4

git checkout master
git merge hotfix/critical-bug
git checkout develop
git merge hotfix/critical-bug

Kendi Dallanma Modelim

Benim kullandığım dallanma modeli daha basit ve esnek bir yapı sunuyor. Temel dalları ve iş akışı aşağıdaki gibi:

• Dev (main branch): Geliştirme dalı, tüm işler buradan başlar.

• Test: Test ortamını güncellemek için kullanılan dal.

• Staging: Staging ortamını güncellemek için kullanılan dal.

• Prod: Üretim ortamını temsil eder.

Bu yaklaşımda, değişiklikler dev branchinden başlar, test, staging ve prod dallarına sırayla birleştirilir. Hotfix’ler ise prod ve main’den aynı anda güncellenir. Gerekli görüldüğünde dev dalı üzerinden feature(özellik) dal çıkılarak paralel geliştirmelerin önü açılabilir.

Sonuç

Her iki yaklaşım da kendi avantaj ve dezavantajları var. Git Flow, karmaşık projelerde daha iyi organizasyon sağlayabilir ancak daha karmaşıktır. Kendi dallanma modelim ise Git-Flow yaklaşımına ek olarak daha basit ve otomatik güncellemelere olanak tanıyor. Hangi yaklaşımın daha uygun olduğuna projenizin büyüklüğü ve karmaşıklığı ile takımınızın deneyim seviyesine göre karar verebilirsiniz. Ben ilk aşamada genelde kendi yaklaşımımla başlayıp duruma göre güncellemeler yapıyorum.