Git'te Main ve Master Branch: nedir ve ana dala neden ihtiyaç duyulur

Git'te Main / Master Branch Nedir

Main Branch (veya Master — depo ayarlarına bağlı olarak), herhangi bir Git deposunu başlatırken oluşturulan varsayılan daldır. Projenin ana dalıdır ve üretime dağıtıma hazır kod içerir.

Yeni özelliklerle günlük çalışmanın tüm hızıyla devam ettiği develop'ın aksine, main projenin vitrinidir. Main'deki her kod sürümü tam bir döngüden geçmiştir: feature dalında geliştirme, develop'a entegrasyon, release dalında sürüm hazırlığı ve son testler. Ancak bundan sonra değişiklikler main'e ulaşır.

Temel prensip: main her zaman kararlı olmalıdır. Main'de bir hata bulunursa, bu, sıra dışı acil bir hotfix yayınlanması gerektiği anlamına gelir. Bu nedenle, profesyonel projelerde main, dal koruma kurallarıyla kazara yapılan değişikliklere karşı korunur.

Git Book'a göre main, benzersiz özelliklere sahip özel bir dal değil, gelenek gereği ana olarak kabul edilen bir commit'e yapılan normal bir referanstır. Git, sistem düzeyinde main ile diğer dallar arasında ayrım yapmaz.

Master'dan main'e geçiş

Tarihsel olarak, Git'teki varsayılan dal master olarak adlandırılıyordu. Haziran 2020'de, Black Lives Matter hareketi IT sektöründeki master ve slave terimlerine dikkat çekti. GitHub, varsayılan dal için main terimine geçişi duyurdu.

Ekim 2020'den itibaren, GitHub'daki tüm yeni depolar main dalı ile oluşturuluyor. GitLab ve Bitbucket da varsayılan ad olarak main desteğini uyguladı. Git 2.28 (Temmuz 2020), varsayılan dal adını yapılandırmak için init.defaultBranch seçeneğini ekledi.

Teknik olarak, mevcut bir dalı master'dan main'e yeniden adlandırmak basit bir işlemdir. Ana zorluk, CI/CD yapılandırmalarındaki, belgelerdeki ve geliştiricilerin yerel depolarındaki tüm referansları güncellemektir.

Mevcut bir depoda bir dalı yeniden adlandırmak için şunu çalıştırın:

# Master'ı yerel olarak main olarak yeniden adlandırma
git branch -m master main

# Uzak depoyu güncelleme
git push -u origin main

# Sunucudaki eski master'ı silme
git push origin --delete master

# Sunucuda HEAD'i güncelleme
# (GitHub web arayüzü üzerinden: Settings → Branches → Default branch)

Git Flow ve GitHub Flow'da main'in rolü

Git Flow ve GitHub Flow, main dalının rolünü farklı şekilde tanımlar. Model seçimi, ekip büyüklüğüne, sürüm sıklığına ve kod kararlılığı gereksinimlerine bağlıdır.

Mobil geliştirme için, Git Flow standarttır çünkü bir uygulamayı App Store ve Google Play'de yayınlamanın sabit sürüm döngüleri vardır. GitHub Flow, günde birkaç kez dağıtılabilen web projeleri için daha uygundur.

GitHub Flow — basitleştirilmiş yaklaşım

GitHub Flow'da develop dalı yoktur. Tüm feature dalları doğrudan main'den oluşturulur ve tamamlandıktan sonra bir Pull Request aracılığıyla geri birleştirilir. Main'deki her birleştirme, otomatik olarak üretime dağıtımı tetikler. Bu model, yüksek düzeyde test otomasyonu ve ekip disiplini gerektirir.

GitHub Flow'da develop dalı yoktur. Tüm feature dalları doğrudan main'den oluşturulur ve tamamlandıktan sonra bir Pull Request aracılığıyla geri birleştirilir. Main'deki her birleştirme, otomatik olarak üretime dağıtımı tetikler. Bu model, yüksek düzeyde test otomasyonu ve ekip disiplini gerektirir.

Main dalının korunması

Main için dal koruması, herhangi bir ticari projede zorunlu bir ayardır. Bu olmadan, kazara yapılan bir push, tamamlanmamış kodu üretime gönderebilir veya tüm kullanıcılar için çalışan bir uygulamayı bozabilir.

• Require pull request — main'e doğrudan push yasaktır. İncelemeli PR ile tüm değişiklikler.
• Require approvals — main'e birleştirmek için en az 2 onay (bir inceleyicinin bir şeyi kaçırması durumunda).
• Require status checks — birleştirmeden önce tüm CI/CD kontrolleri başarılı olmalıdır.
• Require up-to-date — PR, en son main commit'ine dayanmalıdır.
• Include administrators — koruma, depo sahipleri için bile geçerlidir.
• Require signed commits — main'deki tüm commit'ler bir GPG anahtarıyla imzalanmalıdır.

Altı kuralın tümünü yapılandırmak, 10.000+ kullanıcılı mobil projeler için standarttır. Küçük projeler için ilk üç kural yeterlidir.

Farklı proje türleri için koruma seviyelerinin karşılaştırılması

Main'in koruma seviyesi, projenin ölçeğine bağlıdır. Bir startup, minimum koruma ile idare edebilirken, kurumsal bir uygulama maksimum kısıtlamalar gerektirir.

Main'de sürümler ve etiketler

Etiketleme, main'deki belirli commit'lere adlandırılmış referanslar oluşturma uygulamasıdır. Her etiket, üretime yayınlanan uygulamanın bir sürümüne karşılık gelir. Bu, hata ayıklama veya yama için önceki herhangi bir sürüme hızla geçiş yapılmasını sağlar.

Mobil geliştirmede etiket adlandırma standardı SemVer'dir (Anlamsal Sürümleme): v1.2.3, burada ilk sayı ana sürüm (kırıcı değişiklikler), ikincisi alt sürüm (yeni özellikler) ve üçüncüsü yamadır (düzeltmeler).

Release dalı main'e birleştirildikten sonra bir etiket oluşturulur. Bu commit daha sonra CI/CD'de derlenir, imzalanır ve uygulama mağazasına gönderilir. Etikette bir hata bulunursa, bu etiketten bir hotfix dalı oluşturulur.

# Açıklamalı sürüm etiketi oluşturma
git tag -a v2.4.1 -m "Release version 2.4.1"

# Etiketi sunucuya gönderme
git push origin v2.4.1

# Depodaki tüm etiketleri görüntüleme
git tag -l "v2.*"

# Belirli bir etiketten hotfix dalı oluşturma
git checkout -b hotfix/crash-fix v2.4.1

Git Flow dal hiyerarşisi

Git Flow'daki dal hiyerarşisini anlamak, işbirlikçi geliştirmeyi doğru şekilde organize etmenin temelidir. Her dal türünün kendi kaynağı, amacı ve birleştirme kuralları vardır.

• Main (Seviye 1) — kök dal, yalnızca sürümleri içerir. Depo başlatılırken oluşturulur.
• Develop (Seviye 2) — proje başlangıcında main'den oluşturulur. Tüm özelliklerin entegrasyon kodunu içerir.
• Feature (Seviye 3) — develop'dan oluşturulur. Bireysel özelliklerin izole geliştirilmesi.
• Release (Seviye 2) — develop'dan oluşturulur. Belirli bir sürümün yayına hazırlanması.
• Hotfix (Seviye 2) — main'den oluşturulur. Kritik üretim hatalarının acil düzeltilmesi.

Önemli kural: feature asla doğrudan main'e birleştirilmez. feature → develop → release → main doğru birleştirme zinciridir. Bu kuralı ihlal etmek, tüm Git Flow modelinin amacını geçersiz kılar.

Main ile çalışmak için komut örnekleri

Bir senaryo düşünelim: ekip, v2.5.0 sürümünün hazırlığını tamamladı. Release dalı incelendi ve main'e birleştirilmeye hazır. Birleştirmeden sonra bir etiket oluşturulur ve sürüm yayınlanır.

# Main'e geçme ve güncelleme
git checkout main
git pull origin main

# Doğrulanmış release dalını birleştirme
git merge --no-ff release/2.5.0

# Sürüm etiketi oluşturma
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# Main ve etiketi sunucuya gönderme
git push origin main --tags

--no-ff bayrağı (hızlı ilerleme yok), birleştirme yalnızca işaretçi hareket ettirilerek yapılabilecek olsa bile bir birleştirme commit'i oluşturulmasını garanti eder. Bu, değişikliklerin bir release dalından geldiği bilgisini koruyarak geçmiş analizini kolaylaştırır.

Main üzerinden hotfix ile çalışmak

Üretimde kritik bir hata keşfedilirse, süreç normal bir sürümden farklıdır. Hotfix, main'den oluşturulur ve düzeltmeden sonra hem main'e hem de develop'a birleştirilir.

Üretimde kritik bir hata keşfedilirse, süreç normal bir sürümden farklıdır. Hotfix, main'den oluşturulur ve düzeltmeden sonra hem main'e hem de develop'a birleştirilir.

# Main'den hotfix dalı oluşturma
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

# Düzeltme ve commit yapma
git add src/fix/
git commit -m "Fix crash on login screen"

# Hotfix'i main'e geri birleştirme
git checkout main
git merge --no-ff hotfix/2.5.1-crash-fix
git tag -a v2.5.1 -m "Hotfix 2.5.1"
git push origin main --tags

# Hotfix'i develop'a da birleştirme
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# Hotfix dalını silme
git branch -d hotfix/2.5.1-crash-fix