Git’te Şubelerle Çalışmak: Geliştiriciler için Tam Rehber

Git branching, modern yazılım geliştirmesinin en güçlü özelliklerinden biridir. Yeni özellikler geliştirmenize, hataları düzeltmenize ve denemeleri çalıştırmanıza olanak tanır — stabil üretim kodunuza hiç dokunmadan, tamamen izole bir şekilde. Tek başına bir geliştirici olsanız veya dağıtılmış bir ekibin parçası olsanız, Git branch’lerini kullanmayı öğrenmek temiz, profesyonel iş akışlarını sürdürmek için gereklidir.

Bu kapsamlı kılavuz, Git branching hakkında bilmeniz gereken her şeyde size rehberlik eder: temel kavramları anlamaktan branch’ler oluşturmaya, değiştirmeye, birleştirmeye ve kıdemli bir geliştirici gibi yönetmeye kadar. Projelerinizi tam root erişimi olan bir VPS Hosting ortamında çalıştırıyorsanız, bu iş akışları günlük geliştirme pipeline’ınıza sorunsuzca entegre olur.

Git Branch Nedir?

Git’teki bir branch, esasen projenizin geçmişindeki belirli bir commit’e işaret eden hafif, taşınabilir bir işaretçidir. Bir repository başlattığınızda, Git varsayılan bir branch oluşturur — genellikle main veya master olarak adlandırılır — bu, geliştirmenizin birincil hattını temsil eder.

Yeni bir branch oluşturduğunuzda, codebase’in mevcut durumundan ayrılan bağımsız bir geliştirme hattı oluşturursunuz. Bu branch’te yapılan değişiklikler, açıkça birleştirene kadar başka hiçbir branch’i etkilemez. Bu izolasyon, branching’i bu kadar değerli kılan şeydir: main branch’iniz temiz ve dağıtılabilir kalırken, devam eden çalışmalar güvenli bir yerde yaşar.

Branch’leri kodunuz için paralel evrenler olarak düşünün. Her biri bağımsız olarak gelişebilir ve ne zaman ve nasıl bir araya geldiklerini kontrol edersiniz.

Git Branching’in Hosting Ortamınız İçin Neden Önemli Olduğu

Uygulamaları bir sunucuya dağıtıyorsanız — ister bir VPS Hosting planı ister bir Dedicated Servers ortamı olsun — Git branching daha da kritik hale gelir. İşte nedenler:

• Stabilite: Üretim branch’iniz (main) her zaman dağıtılabilir kalır.
• Ekip işbirliği: Birden fazla geliştirici, birbirlerinin değişikliklerine müdahale etmeden aynı anda ayrı özellikler üzerinde çalışabilir.
• Güvenli deneme: Riskli değişiklikleri izole bir branch’te test edebilir ve işler yanlış giderse basitçe silebilirsiniz.
• CI/CD entegrasyonu: GitFlow veya trunk-based development gibi branching stratejileri, sunucunuzda çalışan otomatik dağıtım pipeline’larıyla mükemmel şekilde eşleşir.
• Geri alma yeteneği: Bir birleştirme hata getirirse, diğer çalışmaları kaybetmeden temiz bir şekilde geri alabilirsiniz.

Git repository’lerinizi NVMe SSD depolama ve tam root erişimi olan bir sunucuda barındırmak, özellikle büyük repository’ler veya birden fazla katkıda bulunan kişilerle çalışırken, daha hızlı clone, fetch ve push işlemleri anlamına gelir.

Adım 1: Mevcut Branch’leri Kontrol Etme

Yeni bir şey oluşturmadan önce, repository’nizde zaten hangi branch’lerin var olduğunu gözden geçirmek iyi bir uygulamadır. Aşağıdaki komutu kullanın:

git branch

Bu, tüm yerel branch’leri listeler. Şu anda aktif olan branch, yıldız işaretiyle (*) vurgulanır.

Uzak branch’leri de görmek için şunu kullanın:

git branch -a

Yalnızca uzak branch’leri görmek için:

git branch -r

Mevcut branch ortamınızı anlamak, adlandırma çakışmalarını önler ve karmaşık projelerde yönelimli kalmanıza yardımcı olur.

Adım 2: Yeni Branch Oluşturma

Git’te iş akışınıza bağlı olarak yeni bir branch oluşturmanın birkaç yolu vardır.

Branch’e geçmeden oluşturma:

git branch branch_name

branch_name yerine branch’in amacını yansıtan anlamlı bir ad yazın. Örneğin:

git branch feature/user-authentication

Branch oluşturma ve hemen geçme (klasik yöntem):

git checkout -b branch_name

Örnek:

git checkout -b feature/user-authentication

Modern switch komutu kullanarak oluşturma ve geçme (Git 2.23+):

git switch -c branch_name

Örnek:

git switch -c bugfix/login-redirect

git switch komutu, branch işlemlerini aşırı yüklenmiş git checkout komutundan daha sezgisel ve daha az belirsiz hale getirmek için tanıtılmıştır. Her iki yaklaşım da işe yarar, ancak git switch önerilen modern uygulamadır.

Adım 3: Branch’ler Arasında Geçiş Yapma

Mevcut branch’ler arasında hareket etmek için iki seçeneğiniz vardır:

Klasik yöntem:

git checkout branch_name

Modern yöntem (önerilen):

git switch branch_name

Örnek — ana branch’e geri dönme:

git switch main

Önemli: Branch’ler arasında geçiş yapmadan önce, çalışma dizininizin temiz olduğundan emin olun. Değişikliklerinizi commit’leyin veya git stash kullanarak saklayın, aksi takdirde Git geçişi reddedebilir veya commit’lenmemiş değişiklikleri yeni branch bağlamına taşıyabilir.

git stash          # Save uncommitted changes temporarily
git switch main    # Switch branch
git stash pop      # Restore your stashed changes later

Adım 4: Branch’te Değişiklik Yapma

Doğru branch’te olduğunuzda, geliştirme iş akışınız normal şekilde devam eder. İşte standart döngü:

1. Dosyaları düzenleme veya oluşturma

Tercih ettiğiniz editör veya IDE’yi kullanarak değişiklikler yapın.

2. Değişikliklerinizi hazırlama

git add filename

Veya tüm değiştirilmiş dosyaları aynı anda hazırlayın:

git add .

3. Değişikliklerinizi commit’leme

git commit -m "Add user authentication module"

Açık, açıklayıcı commit mesajları yazın. İyi bir commit mesajı ne değiştiğini ve neden değiştiğini açıklar — sadece nasıl değiştiğini değil. Bu, aylar sonra geçmişi gözden geçirirken veya yeni ekip üyelerini işe alırken paha biçilmez hale gelir.

4. Branch’inizi uzak repository’ye gönderme

Bir ekiple işbirliği yapıyorsanız veya uzak sunucuya yedekliyorsanız:

git push origin branch_name

Örnek:

git push origin feature/user-authentication

Bu branch’i ilk kez gönderiyorsanız, upstream’i ayarlamanız gerekebilir:

git push --set-upstream origin feature/user-authentication

Adım 5: Branch’leri Birleştirme

Özelliğiniz veya düzeltmeniz tamamlandığında ve test edildiğinde, hedef branch’inize — genellikle main veya develop — geri birleştirme zamanı gelmiştir.

Adım adım birleştirme süreci:

1. Hedef branch’e geçiş yapın:

git switch main

2. Uzaktan en son değişiklikleri çekin (ekip ortamlarında önemli):

git pull origin main

3. Özellik branch’inizi birleştirin:

git merge feature/user-authentication

Birleştirme temizse (çakışma yok), Git otomatik olarak bir birleştirme commit’i oluşturacak veya branch geçmişine bağlı olarak hızlı ileri birleştirme gerçekleştirecektir.

Hızlı ileri birleştirme vs. birleştirme commit’i

• Hızlı ileri birleştirme: Hedef branch, özellik branch’inden ayrılmadığında oluşur. Git işaretçiyi ileri taşır. Birleştirme commit’i oluşturulmaz.
• Üç yönlü birleştirme: Her iki branch de ayrıldığında oluşur. Git, her iki geçmişi birbirine bağlayan yeni bir birleştirme commit’i oluşturur.

Her zaman bir birleştirme commit’i oluşturmak için (proje günlüklerinde branch geçmişini korumak için yararlı):

git merge --no-ff feature/user-authentication

Adım 6: Birleştirme Çakışmalarını Çözme

Birleştirme çakışmaları, bir dosyadaki aynı satırlar iki branch’te farklı şekilde değiştirildiğinde oluşur. Git otomatik olarak hangi sürümü tutacağını belirleyemez, bu nedenle çakışmayı manuel olarak çözmenizi ister.

Çakışmaları tanımlama

Çakışma oluştuğunda, Git şöyle bir çıktı verecektir:

CONFLICT (content): Merge conflict in src/auth.js
Automatic merge failed; fix conflicts and then commit the result.

Dosyada çakışma nasıl görünür

<<<<<<< HEAD
const loginUrl = '/api/v2/login';
=======
const loginUrl = '/api/v1/login';
>>>>>>> feature/user-authentication

• <<<<<<< HEAD ve ======= arasındaki her şey, mevcut branch’inizin sürümüdür.
• ======= ve >>>>>>> feature/user-authentication arasındaki her şey, gelen sürümdür.

Çakışmayı çözme

1. Çakışan dosyayı editörünüzde açın.
2. Hangi sürümü tutacağına karar verin — veya her ikisini birleştiren yeni bir sürüm yazın.
3. Tüm çakışma işaretçilerini kaldırın (<<<<<<<, =======, >>>>>>>).
4. Dosyayı kaydedin.

Çözümden sonra birleştirmeyi tamamlama

git add src/auth.js
git commit -m "Resolve merge conflict in auth module"

Birleştirme aracı kullanma

Karmaşık çakışmalar için, görsel bir birleştirme aracı çok değerli olabilir:

git mergetool

Popüler araçlar arasında VS Code’un yerleşik diff editörü, vimdiff, meld ve kdiff3 yer alır.

Adım 7: Branch’leri Silme

Bir branch birleştirildikten ve artık gerekli olmadıktan sonra, repository’nizi temiz ve gezinebilir tutmak için silin.

Yerel branch’i silme (güvenli — yalnızca zaten birleştirilmişse çalışır):

git branch -d branch_name

Örnek:

git branch -d feature/user-authentication

Branch’i zorla silme (birleştirilmemiş olsa bile):

git branch -D branch_name

-D ile dikkatli olun — bu, o branch’teki birleştirilmemiş çalışmaları kalıcı olarak siler.

Uzak branch’i silme:

git push origin --delete branch_name

Örnek:

git push origin --delete feature/user-authentication

Eski branch’leri düzenli olarak temizlemek, repository’nizi organize tutmak ve ekip ortamlarında kafa karışıklığını önlemek için gereklidir.

Adım 8: Branch Geçmişini ve Yapısını Görüntüleme

Tüm branch ve commit geçmişinizin görsel bir özetini almak için şunu kullanın:

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

Bu, şunları gösteren kompakt bir ASCII-art grafiği üretir:

• Tüm branch’ler arasındaki tüm commit’ler
• Her branch işaretçisinin şu anda nerede olduğu
• Birleştirme noktaları ve ayrılmalar
• Etiketler ve HEAD konumu

Örnek çıktı:

* a3f9c12 (HEAD -> main, origin/main) Merge branch 'feature/user-authentication'
|
| * 7b2e441 Add password hashing utility
| * 3d1a908 Create login endpoint
|/
* 9c4f017 Initial project setup

Belirli bir branch’in daha ayrıntılı bir görünümü için:

git log branch_name --oneline

İki branch’i karşılaştırmak ve bir branch’te var olan ancak diğerinde olmayan commit’leri görmek için:

git log main..feature/user-authentication --oneline

Adım 9: Gelişmiş Branching Teknikleri

Birleştirme yerine rebase yapma

Rebase, temiz, doğrusal bir zaman çizelgesi oluşturmak için commit geçmişini yeniden yazan birleştirmeye bir alternatiftir:

git rebase main

Bu, özellik branch’i commit’lerinizi en son main üzerine yeniden oynatır, birleştirme commit’ini ortadan kaldırır. Sonuç, daha temiz bir geçmiştir — ancak paylaşılan uzak sunucuya gönderilen branch’leri hiçbir zaman rebase yapmayın, çünkü geçmişi yeniden yazar ve işbirlikçiler için sorunlara neden olur.

Belirli commit’leri cherry-picking yapma

Tüm branch’i birleştirmek yerine başka bir branch’ten yalnızca bir belirli commit’e ihtiyacınız varsa:

git cherry-pick commit_hash

Bu, kritik bir hata düzeltmesini geliştirme branch’inden doğrudan üretime uygulamak için, tamamlanmamış özellikleri birleştirmeden yararlıdır.

Uzak branch’leri izleme

Uzak branch’i izleyen yerel bir branch kurmak için:

git checkout --track origin/branch_name

Veya modern sözdizimi ile:

git switch --track origin/branch_name

Üretim Ortamları İçin Git Branching Stratejileri

Canlı bir uygulamayı Dedicated Servers veya VPS ortamında yönetiyorsanız, resmi bir branching stratejisini benimsemek dağıtım güvenilirliğini dramatik olarak iyileştirir.

GitFlow

Özellikler, sürümler ve hotfix’ler için adanmış branch’leri olan yapılandırılmış bir iş akışı:

• main — yalnızca üretime hazır kod
• develop — tamamlanan özellikler için entegrasyon branch’i
• feature/* — bireysel özellik branch’leri
• release/* — sürüm hazırlama branch’leri
• hotfix/* — acil üretim düzeltmeleri

Trunk-Based Development

Tüm geliştiricilerin main (“trunk”) üzerine sık sık commit’ledikleri, tamamlanmamış çalışmayı yönetmek için kısa ömürlü özellik branch’leri veya özellik bayraklarını kullanan daha basit, yüksek hızlı bir yaklaşım. Güçlü CI/CD pipeline’larına sahip ekipler tarafından tercih edilir.

GitHub Flow

Hafif bir varyant: main üzerinden branch’leyin, pull request açın, gözden geçirin, birleştirin. Küçük ekipler veya sürekli dağıtım yapan projeler için basit ve etkilidir.

Git Branch Yönetimi İçin En İyi Uygulamalar

Bu kuralları takip etmek, repository’lerinizi temiz, ekibinizi uyumlu ve dağıtımlarınızı öngörülebilir tutacaktır:

1. Açıklayıcı, yapılandırılmış branch adları kullanın

Amacı bir bakışta iletişim kuran tutarlı bir adlandırma kuralı benimseyin:

2. Branch’leri kısa ömürlü tutun

Bir branch birleştirilmeden ne kadar uzun yaşarsa, main üzerinden ayrılması o kadar artar ve acı verici birleştirme çakışmalarının riski o kadar yüksek olur. Özellik branch’lerini haftalar değil, günler içinde birleştirmeyi hedefleyin.

3. Erken ve sık commit’leyin

Küçük, sık commit’ler gözden geçirmesi, geri alması ve anlaması daha kolaydır. Düzinelerce ilişkisiz değişikliği bir araya getiren devasa “catch-all” commit’lerinden kaçının.

4. Birleştirmeden önce her zaman çekin

Özellik branch’ini birleştirmeden önce, main üzerinden en son