Git Dalı: Dallar Oluşturma, Yönetme ve Birleştirme Rehberi

Bir grup kodlama projesinde çalıştıysanız, birden fazla kişinin aynı anda kopya dosyaları güncellemeye çalıştığında işlerin ne kadar hızlı kontrolden çıkabildiğini bilirsiniz. Çakışmalar ortaya çıkar, hatalar sızar ve ilerleme durur. İşte tam bu noktada Git dalları devreye girer—ileri düzey bir hile olarak değil, temiz ve paralel geliştirmenin temeli olarak.

Git’te dallanma sadece teşvik edilmez; beklenir. Yeni bir özelliği denerken, bir hatayı düzeltirken ya da bir başkasının kodunu incelerken, dallar kimsenin ayağına basmadan çalışmanıza olanak tanır. Bir şeyleri bozabilir, yineleyebilir ve ardından değişikliklerinizi ana kod tabanına derli toplu şekilde entegre edebilirsiniz.

Bu kılavuz, Git’te dallanmanın temel unsurlarını adım adım anlatır. git branch ve git checkout ile başlayacak, ardından dalların nasıl oluşturulduğuna, yönetildiğine, birleştirildiğine ve silindiğine daha yakından bakacağız. Ayrıca, iş akışınızı çakışmasız tutmanız için en iyi uygulamaları tartışacağız. Bu kılavuzun sonunda, yalnızca komut ezberlemenin ötesinde bir anlayış kazanmanızı umuyorum: İşin akışı hakkında daha fazlasını kavrayacaksınız. Tüm bunlar ilginizi çekiyorsa ve pratik yapmaya devam etmek istiyorsanız, GitHub Kavramlarına Giriş kursumuz başlamak için harika bir yer.

Git Dallarını Anlamak

Artık zemin hazır olduğuna göre, bir Git dalının ne olduğunu parçalarına ayıralım. Özünde, bir Git dalı ayrı bir klasör ya da kod tabanınızın tam bir kopyası değildir; belirli bir commite işaret eden hafif bir göstergedir. Git’in eski sürüm kontrol sistemlerinden ayrışmasının nedenlerinden biri de budur: dallanma hızlıdır, ucuzdur ve günlük iş akışlarının merkezindedir.

Bir dalı zaman çizgisi olarak düşünün. Yeni bir dal oluşturduğunuzda aslında “Buradan yeni bir yolu keşfedelim.” demiş olursunuz. Tüm değişiklikleriniz, onları ana hatta geri birleştirene kadar bu yolda yaşar. Bu esneklik, fikirleri denemeyi, özellikleri yalıtılmış şekilde geliştirmeyi ve istikrarlı kodu bozmadan başkalarıyla iş birliği yapmayı son derece kolaylaştırır.

Git, projedeki mevcut konumunuzu HEAD adı verilen özel bir referansla takip eder. Dal değiştirdiğinizde HEAD yeni dalın ucunu gösterir. Bu arka plandaki ayrıntı, Git’in bağlamları bu kadar hızlı değiştirmesini sağlar ve git checkout ile git switch gibi komutların, kaputun altında neler olduğunu anladığınızda, bu kadar pürüzsüz hissettirmesinin nedenidir.

Git dallarının nasıl çalıştığını anlayarak, geliştirme iş akışınızı netlik ve güvenle düzenleme gücünü açığa çıkarırsınız. Takip ederken bu kavramları test etmek isterseniz, DataCamp’in Orta Düzey Git kursu, bolca yönlendirmeli pratikle dallanmayı ele alır.

Git Dallarını Listeleme ve Görüntüleme

Dalları oluşturdunuz ve kullanmaya başladınız; peki her şeyi nasıl takip edeceksiniz? Neyse ki Git, iş akışınızı gözden kaçırmamanız için dalları listelemeye, sıralamaya ve filtrelemeye yarayan basit ama güçlü araçlar sunar.

Geçerli dalı kontrol etme

Başlamak için, yerel deponuzda hangi dalların bulunduğunu ve şu anda hangisinde olduğunuzu kontrol edelim.

git branch

Bu komut tüm yerel dallarınızı listeler. Geçerli dalınızın yanında bir yıldız işareti (*) göreceksiniz. Daha hedefli bir görünüm için şunu deneyin:

git branch --show-current

Bu, çalıştığınız dalın adını tertemiz şekilde döndürür.

Uzak dalları da görmek ister misiniz? Şunu kullanın:

git branch -r

Hem yerel hem de uzak dalları aynı anda görüntülemek isterseniz:

git branch -a

Bu, özellikle GitHub gibi platformlarda başkalarıyla iş birliği yaparken projenizin dallanma yapısına dair eksiksiz bir görünüm sağlar. 

Dalları sıralama ve filtreleme

Projeniz büyüdükçe, dal listeniz de büyüyecektir. Sıralama ve filtreleme, bu listeyi etkili şekilde yönetmenize yardımcı olur. Dalları son commit tarihine göre sıralamak için:

git branch --sort=-committerdate

Yazar adına, oluşturulma tarihine veya upstream yapılandırmasına göre de sıralayabilirsiniz. Aşağıda, belirli bir commit’i içeren dalları filtrelemek için kullanışlı bir komut var:

git branch --contains <commit>

Bu, belirli bir commit’i zaten içeren dalları gösterir; böylece bir hata düzeltmesinin veya özelliğin onlara birleştirilip birleştirilmediğini kontrol etmeye yardımcı olur. Tersine, aşağıdaki komut, o commit’i henüz almamış dalları gösterir:

git branch --no-contains <commit>

Dalları etkili şekilde yönetmek, onları oluşturmanın yanı sıra görünürlük ve denetim sağlamayı da içerir. Bu komutlar geliştirmeyi temiz, düzenli ve verimli tutmanıza yardımcı olur.

Bunların iş birliğiyle nasıl ilişkili olduğunu ustalıkla öğrenmek ister misiniz? Git’in Temelleri kursu mükemmel bir başlangıç sunar ve tekrar tekrar kullanacağınız gerçek dünya iş akışlarını kapsar.

Yeni Bir Git Dalı Oluşturma

Artık dallar arasında nasıl listeleme ve geçiş yapılacağını anladığınıza göre, onları oluşturmayı adım adım inceleyelim. Dallanma, Git’in iş akışının temel bir parçasıdır ve neyse ki yeni dallar oluşturmak, ister bir özellik dalı, ister acil düzeltme ya da tamamen yeni bir deneme olsun, oldukça basittir.

Geçiş yapmadan dal oluşturma

Bazen bir dalı, hemen ona geçmeden oluşturmak istersiniz. Bu, aynı anda birden fazla dal hazırlarken veya başkaları için iş akışları kurarken kullanışlıdır.

git branch new-feature

Bu komut new-feature adlı bir dal oluşturur, ancak hâlâ mevcut dalınızda kalırsınız. Üzerinde çalışmaya hazır olduğunuzda daha sonra ona geçebilirsiniz.

Aynı anda dal oluşturma ve geçiş yapma

Doğrudan geliştirmeye atlıyorsanız, tek hamlede yeni dalı oluşturup ona geçebilirsiniz. Eski Git sürümlerinde şunu kullanırdınız:

git checkout -b new-feature

Ancak modern Git’te daha anlaşılır ve sezgisel yaklaşım şudur:

git switch -c new-feature

Bu, dalı oluşturmakla kalmaz; onu hemen checkout eder, böylece çalışmaya hazırsınız.

Upstream dalları ayarlama

Uzak depolarla çalışırken, yerel dalınızın sıklıkla bir uzak dalı takip etmesini istersiniz. Bu, güncellemeleri itip çekmeyi basitleştirir. Baştan itibaren bir uzak dalı takip eden bir dal oluşturmak için:

git branch --track new-feature origin/new-feature

Dalı zaten oluşturduysanız ve upstream’i ayarlamak veya değiştirmek istiyorsanız, şu komut işinizi görür:

git branch --set-upstream-to=origin/new-feature

Bu yapılandırma, yerel dalınızın hangi uzak daldan çekeceğini veya hangisine iteceklerini bilmesini sağlar ve iş akışınızı akıcı ve bağlantılı tutar.

Git Dalları Arasında Geçiş Yapma

Birkaç dal oluşturduktan sonra, sık sık aralarında gezinmeniz gerekir; ister bir düzeltmeyi birleştirmek için main’e geri dönüyor olun, ister bir özellik dalına geçip kodlamaya devam ediyor olun. Git bu süreci sorunsuz hale getirir ve Git ile ilgili çoğu şeyde olduğu gibi bunu yapmanın birden fazla yolu vardır.

git checkout kullanma

Uzun süre, dallar arasında geçiş yapmak için başvurulan komut git checkout idi:

git checkout feature-login

Bu komut, çalışma dizininizi feature-login dalına geçirir ve tüm dosyalarınızı o dalın anlık görüntüsünü yansıtacak şekilde günceller. Güvenilirdir ve hâlâ yaygın olarak kullanılır. Ama mesele şu: git checkout çok şey yapar. Dalları değiştirmek, dosyaları geri yüklemek ve hatta commitleri checkout etmek için kullanılır. Bu da özellikle yeni başlıyorsanız kafa karıştırıcı olabilir.

git switch kullanma

İşleri daha sezgisel hale getirmek için Git 2.23 sürümünde git switchi tanıttı:

git switch feature-login

Bu, tam beklediğiniz şeyi yapar: dallar arasında geçiş yapar. Siz söylemedikçe çalışma ağacınıza dokunmaz ya da dosyalarınızı sıfırlamaz. Daha basit, daha güvenli ve öğretmesi/hatırlaması daha kolaydır.

Peki hangisini ne zaman kullanmalısınız?

• Dallar arasında geçiş için git switch kullanın—amaç odaklı ve nettir.
• Dosyaları geri yüklemeniz veya belirli bir commit’i checkout etmeniz gerekiyorsa git checkout kullanın.

Git Dallarını Birleştirme

Bir özelliği ayrı bir dalda geliştirdiniz. Şimdi sıra geldi: değişikliklerinizi ana dala birleştirmeye. Git’te bu sürece merge denir. Dallarınızın geçmişine bağlı olarak bunu birkaç şekilde ele alabilirsiniz.

Hızlı iletme (fast-forward) birleştirmesi

Diyelim ki özellik dalınız main’den başladı ve siz çalışırken hiç kimse main’e dokunmadı. Bu durumda Git’in çok fazla düşünmesine gerek yoktur. Sadece main göstergesini feature-branch’teki en son commite taşır.

git checkout main
git merge feature-branch

Yeni bir commit oluşturulmaz—Git main’i hızlıca iletir. Temiz, basit ve tek kişilik projeler ya da kısa ömürlü dallar için idealdir.

Üç yönlü birleştirme

Her iki dal da birbirinden bağımsız ilerlediğinde işler ilginçleşir. Siz özellik dalında kod yazarken ekip arkadaşınız maine bazı değişiklikler eklemiş olabilir. Şimdi Git, ortak ataya, sizin dalınıza ve hedef dala bakmak zorundadır.

git checkout main
git merge feature-branch

Bu durumda Git, iki dalı birleştirmek için yeni bir birleştirme commit’i oluşturur. Çakışmalar varsa, örneğin siz ve ekip arkadaşınız aynı dosyada aynı satırı değiştirdiyseniz, Git bunları elle çözmeniz için sizi yönlendirir. Dosyayı düzenler, çözüldü olarak işaretler ve ardından birleştirmeyi commitlersiniz.

git add .
git commit

Bu biraz göz korkutucu geliyorsa, Git Merge Eğitimi: Örneklerle Kapsamlı Rehber tüm temel noktaları, çakışmaları nazikçe ele almayı da içerecek şekilde, mükemmel biçimde anlatır.

Birleştirmek yerine rebase etmek

Geçmişinizi kirleten birleştirme commit’lerinin hayranı değil misiniz? Yalnız değilsiniz. İşte burada Git rebase devreye girer. Yeni bir birleştirme commit’i oluşturmak yerine rebase, değişikliklerinizi başka bir dalın üzerine tekrar uygular ve daha temiz, doğrusal bir geçmiş elde edilir.

git checkout feature-branch
git rebase main

Daha sonra birleştirdiğinizde Git düz bir çizgi görür—birleştirme commit’ine gerek kalmaz. Ancak, özellikle paylaşılan dallarda çalışırken dikkatli kullanın. Geçmişi yeniden yazmak, başkaları aynı kod üzerinde çalışıyorsa tehlikeli olabilir.

Birleştirme ile rebase’i ne zaman kullanmanın daha iyi olduğunu (ve güvenli şekilde nasıl rebase yapılacağını) öğrenmek için, Orta Düzey Git kursu pratik, uygulamalı rehberlik sunar.

Git Dallarını Silme

Başarılı bir birleştirmeden sonra, artık ihtiyaç duymadığınız dalları hem yerelde hem uzak depoda temizlemek iyi bir fikirdir. Bu, çalışma alanınızı düzenli, Git geçmişinizi ise gezinmesi kolay tutar. Önemli bir şeyi yanlışlıkla silme endişesi duymadan bunu nasıl yapacağınızı adım adım inceleyelim.

Yerel dalları silme

Bir dal birleştirildiğinde ve işini tamamladığında, onu yerel deponuzdan güvenle silebilirsiniz:

git branch -d feature-branch

Buradaki -d bayrağı “delete” (sil) anlamına gelir. Git, olası veri kaybını önlemek için dalın zaten birleştirildiğini kontrol eder.

Peki dalı, birleştirilmemiş olsa bile silmek isterseniz? Büyük harfli -D burada devreye girer:

git branch -D feature-branch

Bu, Git dalın birleştirilmediğini söylese bile silmeyi zorlar. Enter’a basmadan önce, bu değişikliklere ihtiyacınız olmadığından emin olun.

Yerel çalışma alanınızı ve dalları yönetmeye dair daha derinlemesine bir inceleme mi arıyorsunuz? Git Pull Force: Yerel Bir Dalı Uzakla Nasıl Ezersiniz eğitimimize göz atın. Bu, sadece silmek değil, dalları güvenle yönetmek için de yararlı bir eşlikçidir.

Uzak dalları silme

Yerel temizlik işin sadece yarısıdır. Dal uzak depoda (örneğin GitHub) da yaşıyorsa ve özellikle özellik ya da hata düzeltmesi tamamlandıysa, onu oradan da kaldırmak isteyeceksiniz.

git push origin --delete feature-branch

Bu komut, dalı origin uzak deposundan kaldırmasını Git’e söyler. Kullanılmayan dallarla uzak deponuzun dağınık hale gelmesini önlemek için temiz ve doğrudan bir yöntemdir.

Uzak dalları sildikten sonra, yerel izleme referanslarınızı temizlemek de iyi bir fikirdir.

git fetch -p

Buradaki -p “prune” (budama) anlamına gelir. Sunucuda artık var olmayan bayat uzak izleme dallarını kaldırır.

Daha fazla yararlı Git hijyen alışkanlığı için, Git Push ve Pull Eğitimi ile Eksiksiz Git Cheat Sheet hızlı başvuru için idealdir.

Git Dallarını Push ve Pull Yapma

Dalları yerelde oluşturup düzenledikten sonra sıradaki adım, onları uzak depo ile eşitlemektir. Bu, iş birliği ve yedekleme için gereklidir. Dalları etkili şekilde nasıl push, pull ve takip edeceğinizi inceleyelim.

Yeni bir dalı uzağa push etme

Yerelde yeni bir özellik oluşturdunuz ve test ettiniz; şimdi bunu ekibinizle paylaşmak veya yedeklemek istiyorsunuz. Yeni bir dalı uzak bir depoya (genellikle origin olarak adlandırılır) itmek için şunu kullanın:

git push -u origin new-feature

-u (uzun hali --set-upstream) bayrağı, Git’e gelecekteki pull ve push işlemleri için uzak dalı hatırlamasını söyler. Böylece bir sonraki sefer git pull veya git push komutlarını dal belirtmeden çalıştırabilirsiniz.

Bir push veya pull sırasında arka planda başka neler olduğunu merak ediyorsanız, Git Push ve Pull Eğitimi bunu takip edebileceğiniz örneklerle açıklar.

Uzak bir daldan değişiklikleri çekme

Diyelim ki başkası, üzerinde çalıştığınız aynı dala güncellemeler itti. Senkron kalmak için bu değişiklikleri çekmek isteyeceksiniz:

Git pull origin new-feature

Bu, uzak depodaki en son commitleri getirir ve yerel dalınıza birleştirir. Birleştirme commitlerinden kaçınmak isterseniz, şunu düşünün:

git pull --rebase origin new-feature

Birleştirme bölümünde açıklandığı gibi, --rebase commit geçmişinizi temiz tutmaya yardımcı olur.

Uzak bir dalı takip etme

Uzakta zaten var olan bir dal ile çalışmaya başlamak istediğinizde, kurulumu yapmanın en kolay yolu şudur:

git checkout --track origin/feature-xyz

Bu komut uzak dalı checkout eder ve izlemeyi otomatik olarak ayarlar; böylece sonraki pull ve push işlemleri çok kolay olur.

Yaygın Sorunlar ve Sorun Giderme

En iyi iş akışlarında bile işler her zaman sorunsuz gitmez. İster bir birleştirme çakışması, ister yanlışlıkla silinen bir dal, ister önünüzü tıkayan commitlenmemiş değişiklikler olsun, Git’in kurtarmaya yardımcı olacak araçları vardır. En yaygın dallanma sorunlarına ve bunları nasıl çözeceğinize bakalım.

Birleştirme çakışmalarını ele alma

Az önce bir dalı birleştirmeyi denediniz ve Git bir birleştirme çakışması verdi. Bu, iki dalın bir dosyanın aynı bölümünü farklı şekilde değiştirmesi ve Git’in hangi değişikliği tutacağına karar verememesi durumunda olur.

Bunu şöyle ele alırsınız:

git status

Bu, hangi dosyaların çakıştığını söyler. Ardından şunu kullanabilirsiniz:

git diff

Soruna neyin neden olduğunu görmek için. Buradan, çakışan dosyaları elle açıp farklılıkları giderir ve ardından

git add <resolved-file>
git commit

Birleştirme iş akışları ve çakışmaları çözme hakkında daha fazla bilgi edinmek isterseniz, baştan sona bir yürüyüş sunan Git Merge Eğitimine göz atın.

Silinen dalları kurtarma

Yanlışlıkla bir dalı mı sildiniz ve panik mi başladı? Endişelenmeyin—hızlı davranırsanız sonsuza kadar kaybolmaz.

Bunu, son HEAD konumlarınızı kaydeden git reflog ile kurtarabilirsiniz:

git reflog

Dalı silmeden önceki commit hash’ini bulun ve ardından şununla yeniden oluşturun:

git checkout -b your-branch-name <commit-hash>

Ve işte bu kadar, dalınız geri geldi. Git’in bu referansları nasıl takip ettiğini daha iyi anlamak ister misiniz? Git Reflog Rehberi bunu gerçek örneklerle açıklar.

Geçişten önce değişiklikleri saklama

Bazen dal değiştirmek istersiniz, ancak commitlenmemiş değişiklikleriniz vardır. Git, iş kaybına yol açabilecekse geçişe izin vermez. İşte burada git stash devreye girer.

git stash

Ve Git, değişikliklerinizi geçici olarak bir kenara koyar. Dal değiştirdikten sonra onları geri getirmek için şunu kullanabilirsiniz:

git stash pop

Bu, özellikler veya acil düzeltmeler arasında zıplarken özellikle yardımcıdır.

Birçok değişikliği yönetiyorsanız veya çalışma dizininizi temizliyorsanız, Git Clean: İzlenmeyen Dosyaları Kaldırın ve Depoları Düzenli Tutun da ilginizi çekebilir.

Gelişmiş Dallanma Stratejileri

Artık Git dallarını kolayca oluşturmayı, geçiş yapmayı ve yönetmeyi gördünüz. Peki ekipler bu dalları gerçek projelerde nasıl kullanıyor? Yanıt, doğru dallanma stratejisini seçmekte yatar—yani geliştirme iş akışınızda dalların nasıl ve ne zaman kullanılacağını belirleyen yapı. En popüler yaklaşımlardan bazılarını keşfedelim.

Özellik dalı iş akışı

Özellik dalı iş akışı, özellikle ortak projelerde en yaygın stratejilerden biridir. Nasıl çalışır:

Her yeni özellik, ana (veya develop) daldan oluşturulan kendi dalını alır. Bu, geliştiricilerin üretime hazır kodu etkilemeden bağımsız çalışmasına olanak tanır.

git switch -c feature/login-page

Özellik tamamlanıp test edildikten sonra, bir çekme isteği üzerinden ana dala (veya hazırlık dalına) geri birleştirilir.

Bu model, çalışmayı yalıtır, kod incelemelerini daha yönetilebilir hale getirir ve ana dalınızın yarım kalmış özelliklerle kirlenmesini önler. Uzak iş birliğini sorunsuz tutmak için dallarınızı push etmeyi unutmayın:

git push -u origin feature/login-page

Dalları push ve pull etme konusunda tazeleme mi gerekiyor? Git Push ve Pull Eğitimi tüm süreci adım adım anlatır.

GitFlow iş akışı

Düzenli sürümlerle çalışıyorsanız, GitFlow iyi bir seçenek olabilir. Bu iş akışı, farklı dal türleri için yapılandırılmış roller sunar:

• main: her zaman üretime hazır kodu içerir.

• develop: özellikler için entegrasyon dalı.

• feature/*: yeni özellikler için kısa ömürlü dallar.

• release/*: test için ön üretim dalları.

• hotfix/*: Hızlı düzeltmeler main temel alınarak yapılır.

GitFlow araçlarını kullanarak yeni bir özellik dalı başlatmanın hızlı bir örneği:

git flow feature start payment integration

Bu strateji biraz karmaşıklık katar, ancak net yapı ve istikrarın öncelik olduğu daha büyük ekiplerde parlar. GitHub’ın ötesindeki iş akışlarını keşfediyorsanız, yapılandırılmış Git uygulamalarına başka bir bakış için GitLab Nedir: Özellikler, Faydalar ve Başlangıç’a göz atın.

Gövde tabanlı geliştirme (Trunk-based development)

Minimum dallanma ve hızlı teslimatı mı tercih ediyorsunuz? Gövde tabanlı geliştirme tarzınız olabilir. Bu stratejide tüm geliştiriciler genellikle main olan tek bir dala, küçük ve sık commitlerle katkıda bulunur. Uzun ömürlü özellik dalları yerine, kısa ömürlü dallar veya doğrudan main dalına commitler teşvik edilir.

Hızlı ve yalındır ancak disiplin, güçlü test otomasyonu ve iyi iletişim gerektirir. Bu model, startuplarda ve DevOps ya da CI/CD uygulayan ekiplerde yaygındır. Bir dallanma stratejisini seçmek, ekibinizin büyüklüğüne ve sürüm sıklığına ve elbette iş birliği düzeyine bağlıdır.

Sonuç

Dallar, Git’in sürüm kontrol sisteminin kalbinde yer alır. Geliştiricilerin yeni özellikler, hata düzeltmeleri ve denemeler üzerinde, ana kod tabanını bozmadan, yalıtılmış şekilde çalışmasına olanak tanır. Bu esneklik, daha temiz ve düzenli iş akışlarına ve daha iyi ekip iş birliğine yol açar.

Sık commitleyerek, sorumlu şekilde birleştirerek ve temiz bir dal yapısı koruyarak çakışma riskini azaltır, kod tabanınızı gezinmesi ve bakım yapması daha kolay hale getirirsiniz. Kuşkusuz, Git dallarında ustalaşmak, zaman içinde daha iyi yazılım teslim etmenize yardımcı olur.