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 — kararlı üretim kodunuza hiç dokunmadan. İster solo bir geliştirici ister dağıtılmış bir ekibin parçası olun, Git dallarında uzmanlaşmak temiz ve profesyonel iş akışlarını korumak için gereklidir.

Bu kapsamlı rehber, Git branching hakkında bilmeniz gereken her şey konusunda size yol gösterir: temel kavramları anlamaktan dalları 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 boru hattınıza sorunsuz bir şekilde entegre olur.

Git Dalı Nedir?

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

Yeni bir dal oluşturduğunuzda, kod tabanının mevcut durumundan ayrılan bağımsız bir geliştirme satırı oluşturursunuz. O dal üzerinde yapılan değişiklikler, açıkça bunları birleştirene kadar başka hiçbir dalı etkilemez. Bu izolasyon, dallandırmayı bu kadar değerli kılan şeydir: main dalınız temiz ve dağıtılabilir kalırken, devam eden çalışmalar güvenli bir şekilde başka yerde yaşar.

Dalları 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 tam olarak kontrol edersiniz.

Git Dallanması Neden Barındırma Ortamınız İçin Önemlidir

Bir sunucuda uygulamalar dağıtıyorsanız — ister bir VPS Hosting planı ister bir Dedicated Servers ortamı olsun — Git dallanması daha da kritik hale gelir. İşte nedenleri:

• Stabilite: Üretim dalınız (main) her zaman dağıtılabilir durumda kalır.
• Takım işbirliği: Birden fazla geliştirici aynı anda ayrı özellikler üzerinde çalışabilir ve birbirlerinin değişikliklerine müdahale etmez.
• Güvenli deneyler: Riskli değişiklikleri izole bir dalda test edebilir ve işler yanlış giderse basitçe silebilirsiniz.
• CI/CD entegrasyonu: GitFlow veya trunk-based development gibi dallanma stratejileri sunucunuzda çalışan otomatik dağıtım boru hatlarıyla mükemmel şekilde eşleşir.
• Geri alma yeteneği: Bir birleştirme bir hata ortaya çıkarırsa, diğer çalışmaları kaybetmeden temiz bir şekilde geri alabilirsiniz.

Git depolarınızı NVMe SSD depolama ve tam kök erişimi olan bir sunucuda barındırmak, daha hızlı clone, fetch ve push işlemleri anlamına gelir — özellikle büyük depolarla veya birden fazla katılımcıyla çalışırken önemlidir.

Adım 1: Mevcut Dalları Kontrol Etme

Yeni bir şey oluşturmadan önce, deponuzda zaten hangi dalların bulunduğunu gözden geçirmek iyi bir uygulamadır. Aşağıdaki komutu kullanın:

git branch

Bu, tüm yerel dalları listeler. Şu anda etkin olan dal bir yıldız işaretiyle vurgulanır (*).

Uzak dalları da görmek için şunu kullanın:

git branch -a

Yalnızca uzak dalları görmek için:

git branch -r

Mevcut dal ortamınızı anlamak, adlandırma çatışmalarını önler ve karmaşık projelerde yönelim bulmanıza yardımcı olur.

Adım 2: Yeni Bir 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 yeni bir branch oluşturun:

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şturun ve hemen ona geçin (klasik yöntem):

git checkout -b branch_name

Örnek:

git checkout -b feature/user-authentication

Modern switch komutunu kullanarak oluşturun ve geçin (Git 2.23+):

git switch -c branch_name

Örnek:

git switch -c bugfix/login-redirect

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

Adım 3: Dallar Arasında Geçiş Yapma

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

Klasik yöntem:

git checkout branch_name

Modern yöntem (önerilir):

git switch branch_name

Örnek — ana dala geri dönme:

git switch main

Önemli: Dallar arasında geçiş yapmadan önce, çalışma dizininizin temiz olduğundan emin olun. Değişikliklerinizi commit edin veya git stash kullanarak stash edin, aksi takdirde Git geçişi reddedebilir veya commit edilmemiş değişiklikleri yeni dal 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: Bir Şube Üzerinde Değişiklik Yapma

Doğru şubeye geçtikten sonra, geliştirme iş akışınız normal şekilde devam eder. İşte standart döngü:

1. Dosyaları düzenleyin veya oluşturun

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

2. Değişikliklerinizi hazırlayın

git add filename

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

git add .

3. Değişikliklerinizi işleyin

git commit -m "Add user authentication module"

Açık ve 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 takım üyelerini dahil ederken priceless hale gelir.

4. Şubenizi uzak bir depoya gönderin

Bir takımla işbirliği yapıyorsanız veya uzak bir sunucuya yedekleme yapıyorsanız:

git push origin branch_name

Örnek:

git push origin feature/user-authentication

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

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

Adım 5: Şubeları Birleştirme

Özelliğiniz veya düzeltmeniz tamamlandığında ve test edildiğinde, bunu hedef şubenize geri birleştirme zamanı gelmiştir — tipik olarak main veya develop.

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

1. Hedef şubeye geçin:

git switch main

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

git pull origin main

3. Özellik şubenizi birleştirin:

git merge feature/user-authentication

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

Hızlı ileri birleştirme vs. birleştirme işlemi

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

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

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

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

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

Çatışmaları tanımlama

Bir çatış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.

Bir dosyada çatış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 dalınızdan gelen sürümdür.
• ======= ve >>>>>>> feature/user-authentication arasındaki her şey, gelen sürümdür.

Çatışmayı çözme

1. Çatışan dosyayı editörünüzde açın.
2. Hangi sürümü tutacağınıza karar verin — ya da her ikisini birleştiren yeni bir sürüm yazın.
3. Tüm çatış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 çatış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 almaktadır.

Adım 7: Şubeleri Silme

Bir şube birleştirildikten ve artık gerekli olmadığında, depoyu temiz ve gezinilebilir tutmak için silin.

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

git branch -d branch_name

Örnek:

git branch -d feature/user-authentication

Bir şubeyi zorla silme (birleştirilmemiş olsa bile):

git branch -D branch_name

-D kullanırken dikkatli olun — bu, o şubedeki birleştirilmemiş tüm işleri kalıcı olarak siler.

Uzak bir şubeyi silme:

git push origin --delete branch_name

Örnek:

git push origin --delete feature/user-authentication

Eski şubeleri düzenli olarak budamak, deponuzu organize tutmanızı ve takım ortamlarında kafa karışıklığını önlemenizi sağlar.

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

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

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

Bu, aşağıdakileri gösteren kompakt bir ASCII-art grafik üretir:

• Tüm şubeler arasındaki tüm commitler
• Her şube 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 şubenin daha ayrıntılı bir görünümü için:

git log branch_name --oneline

İki şubeyi karşılaştırmak ve bir şubede var olup diğerinde olmayan commitleri görmek için:

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

Adım 9: Gelişmiş Branching Teknikleri

Merge yerine Rebasing

Rebasing, daha temiz ve doğrusal bir zaman çizelgesi oluşturmak için commit geçmişini yeniden yazan merge’e alternatif bir yöntemdir:

git rebase main

Bu, feature branch commit’lerinizi en son main üzerine yeniden oynatır ve merge commit’ini ortadan kaldırır. Sonuç daha temiz bir geçmiştir — ancak paylaşılan remote’a push edilmiş branch’leri asla rebase etmeyin, çünkü bu geçmişi yeniden yazar ve işbirlikçiler için sorunlara neden olur.

Belirli commit’leri cherry-picking

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

git cherry-pick commit_hash

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

Remote branch’leri izleme

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

git checkout --track origin/branch_name

Veya modern söz dizimiyle:

git switch --track origin/branch_name

Üretim Ortamları için Git Branching Stratejileri

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

GitFlow

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

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

Trunk-Based Development

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

GitHub Flow

Hafif bir varyant: main üzerinden dal oluştur, pull request aç, gözden geçir, birleştir. Daha küçük takımlar veya sürekli dağıtım yapan projeler için basit ve etkili.

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

Bu kuralları takip etmek depoları 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 ile sapma o kadar büyük olur ve acı verici merge çatış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 yapın

Küçük, sık yapılan commit’ler incelemesi, geri alınması ve anlaşılması daha kolaydır. Düzinelerce ilgisiz değişikliği bir araya getiren büyük “hepsini kapsayan” commit’lerden kaçının.

4. Birleştirmeden önce her zaman pull yapın

Bir özellik branch’ini birleştirmeden önce, çatışmaları en aza indirmek için main adresinden en son değişiklikleri pull yapın:

git pull origin main

5. Anlamlı commit mesajları yazın

Tutarlılık için geleneksel commit’ler formatını izleyin:

feat: add OAuth2 login support
fix: resolve null pointer in user profile loader
docs: update API authentication guide
refactor: simplify database connection pooling

6. Ana branch’inizi koruyun

Barındırılan Git platformlarında (GitHub, GitLab, Gitea), main adresine birleştirmeden önce pull request incelemelerini gerektirmek için branch koruma kurallarını yapılandırın. Bu, üretime yanlışlıkla doğrudan push’ları engeller.

7. CI/CD ile otomatikleştirin

Git iş akışınızı, her branch push’ında otomatik olarak testleri çalıştıran bir CI/CD pipeline’ı ile entegre edin. Yalnızca tüm testleri geçen branch’ler birleştirilmeye uygun olmalıdır. Bu, düzgün şekilde yapılandırılmış bir sunucu ortamı ile mükemmel şekilde eşleşir — kendi Git sunucunuzu veya CI runner’ınızı barındırıyorsanız, root erişimi olan bir VPS Hosting planı, pipeline yapılandırmanız üzerinde tam kontrol sağlar.

Sunucunuzda Özel Git Deposu Kurulumu

Git depolarınızı üçüncü taraf platformlarına güvenmek yerine kendi sunucunuzda barındırmayı tercih ediyorsanız, doğrudan sunucunuzda bir bare Git deposu kurabilirsiniz.

Sunucuda bare depo başlatın:

mkdir -p /srv/git/myproject.git
cd /srv/git/myproject.git
git init --bare

Bunu yerel makinenizden klonlayın:

git clone user@yourserver.com:/srv/git/myproject.git

Dalları buna herhangi bir remote gibi gönderin:

git push origin feature/new-dashboard

Git depolarınızı kendi sunucunuzda barındırmak, tam gizlilik, üçüncü taraf platformlar tarafından dayatılan depolama sınırlaması olmayışı ve erişim izinleri üzerinde tam kontrol sağlar. Bunu SSL Sertifikaları ile eşleştirerek geliştiricileriniz ile sunucu arasındaki trafiği şifreleyin ve güvenli, şifresiz erişim için SSH anahtar kimlik doğrulaması kurulumunu düşünün.

Tam özellikli Git barındırma arayüzüne ihtiyaç duyan takımlar için, Gitea veya GitLab CE gibi araçlar bir saatten kısa sürede VPS’inize kurulabilir ve size pull request’ler, sorun takibi ve CI/CD pipeline’ları sağlar — hepsi kontrol ettiğiniz altyapıda kendi sunucunuzda barındırılır.

Hızlı Referans: Temel Git Branch Komutları

Sonuç

Git branching sadece teknik bir özellik değildir — organize, ölçeklenebilir geliştirmeyi kaotik, kırılgan kod tabanlarından ayıran bir profesyonel disiplindir. Bu kılavuzda ele alınan komutları ve stratejileri ustalıkla öğrenerek, karmaşık projeleri güvenle yönetebilir, takım arkadaşlarınızla etkili bir şekilde işbirliği yapabilir ve tahmin edilebilir şekilde dağıtım yapabilirsiniz.

İleri taşıyacağınız temel ilkeler:

• İşleri izole edin ana branch’inizi her zaman korumak için ayrılmış branch’lerde.
• Branch’leri açıklayıcı şekilde adlandırın böylece her işbirlikçi amaçlarını anında anlasın.
• Sık sık merge edin sapmaları en aza indirmek ve çakışma karmaşıklığını azaltmak için.
• Temizleyin merge edilmiş branch’leri deponuzu gezinilebilir tutmak için.
• Otomatikleştirin branching workflow’unuza bağlı CI/CD pipeline’ları aracılığıyla test ve dağıtımı.

Kişisel bir proje oluşturuyor olsanız ya da mühendislerden oluşan bir takımı yönetiyor olsanız, doğru hosting altyapısı gerçek bir fark yaratır. Hızlı NVMe depolama Git işlemlerini hızlandırır, root erişimi ortamınızı tam olarak ihtiyacınız şekilde yapılandırmanıza izin verir ve güvenilir çalışma süresi deponuzun her zaman erişilebilir olmasını sağlar. Geliştiriciler için tasarlanmış VPS Hosting planlarını keşfedin veya yüksek talep gören takım ortamları için Dedicated Servers‘a ölçekleyin. Deponuzun yanı sıra web uygulamalarını da yönetiyorsanız, Shared Web Hosting daha küçük projeler için uygun maliyetli bir seçenek sunar.

Git workflow’unuz onu destekleyen altyapı kadar güçlüdür — her ikisinin de uzun ömürlü olacak şekilde inşa edildiğinden emin olun.