Git Dallanma ve Birleştirme Temelleri: OSD600Lab3

Yazılım geliştirme süreçleri, özellikle ekip halinde çalışırken karmaşık hale gelebilir. Çeşitli özelliklerin aynı anda geliştirilmesi, hataların giderilmesi ve tüm bu değişikliklerin ana kod tabanına sorunsuz bir şekilde entegre edilmesi, modern sürüm kontrol sistemleri olmadan neredeyse imkansızdır. Bu makale, Git’in sunduğu en güçlü özelliklerden biri olan dallanma (branching) ve birleştirme (merging) kavramlarını OSD600Lab3 bağlamında detaylıca inceleyecek ve geliştirme akışınızı nasıl optimize edebileceğinizi gösterecektir.

Git’in dallanma özelliği, geliştiricilere ana kod tabanından (genellikle main veya master olarak adlandırılır) bağımsız çalışma alanları oluşturma imkanı sunar. Tıpkı bir ağacın ana gövdesinden çıkan farklı dallar gibi, projenizin ana geçmişinden ayrılan yeni bir geliştirme hattı düşünebilirsiniz. Peki, bu özellik neden bu kadar kritik?

Öncelikle, izolasyon sağlar. Yeni bir özellik üzerinde çalışırken veya bir hatayı düzeltirken, yaptığınız değişiklikler ana projeyi (main dalı) doğrudan etkilemez. Bu, ana dalın her zaman kararlı ve üretime hazır kalmasını garanti eder. Diyelim ki, bir e-ticaret uygulamasında yeni bir ödeme sistemi entegrasyonu üzerinde çalışıyorsunuz. Bu süreç, haftalar sürebilir ve birçok ara değişikliği içerebilir. Eğer tüm bu değişiklikleri doğrudan main dalında yapsaydınız, bu dal sürekli olarak kararsız bir durumda olurdu. Ancak bir feature/yeni-odeme-sistemi dalı oluşturarak, tüm denemelerinizi, geliştirmelerinizi ve hatalarınızı bu dalda izole edebilir, main dalını etkilemeden ilerleyebilirsiniz. Bu, paralel geliştirmenin temelidir; birden fazla ekip üyesi aynı anda, birbirlerinin işlerini engellemeden farklı görevler üzerinde çalışabilir.

Ayrıca, dallar farklı geliştirme aşamalarını yönetmek için de kullanılır. Örneğin, development dalı tüm yeni özelliklerin birleştiği yer olabilirken, staging dalı test için hazırlanan versiyonu temsil edebilir ve main dalı ise canlıdaki (production) kararlı sürümü barındırır. Bu yapı, riskleri minimize eder ve daha kontrollü bir yayın döngüsü sağlar. Bir hata düzeltmesi gerektiğinde, sadece o hata için küçük bir dal oluşturup, hızlıca düzeltmeyi yapıp ana dala geri birleştirebilirsiniz. Bu esneklik, modern yazılım geliştirme metodolojilerinin (örneğin Agile) vazgeçilmez bir parçasıdır. Örneğin, acil bir güvenlik açığı tespit edildiğinde, canlıdaki main daldan bir hotfix/guvenlik-acigi dalı oluşturulur, düzeltme yapılır, hızlıca test edilir ve tekrar main dalına birleştirilir. Bu sayede, uygulamanın kritik işlevselliği kesintiye uğramadan sorun giderilmiş olur. Dolayısıyla, Git dallanması, sadece kod düzenlemekten öte, tüm geliştirme sürecini daha düzenli, verimli ve risksiz hale getiren stratejik bir araçtır.

Bir Git Dalı Nasıl Oluşturulur ve Yönetilir? Adım Adım Rehber

Git dallarını kullanmaya başlamak oldukça basittir, ancak etkili yönetim pratikleri benimsemek uzun vadede size büyük faydalar sağlayacaktır. İşte adım adım bir dal oluşturma, üzerinde çalışma ve yönetme süreci:

1. Mevcut Dalları Görüntüleme

Çalışmaya başlamadan önce mevcut dalları görmek iyi bir adımdır. Bu komut, yerel deponuzdaki tüm dalları listeler ve üzerinde bulunduğunuz dalı yıldız işaretiyle belirtir:

git branch

Benzer şekilde, uzaktaki (remote) dalları görmek için -r, hem yerel hem de uzak dalları görmek için -a parametresini kullanabilirsiniz.

git branch -a

2. Yeni Bir Dal Oluşturma

Yeni bir özellik üzerinde çalışmak için genellikle main dalından yeni bir dal oluştururuz. Diyelim ki, "kullanıcı profili" özelliği üzerinde çalışacaksınız:

git branch feature/kullanici-profili

Bu komut, bulunduğunuz dalın mevcut durumundan yeni bir dal oluşturur. Ancak bu dalı oluşturduktan sonra hala eski dalınızda (örneğin main) olacaksınız.

3. Yeni Dala Geçiş Yapma

Oluşturduğunuz yeni dalda çalışmaya başlamak için o dala geçiş yapmanız gerekir. Bunu git checkout veya daha modern olan git switch komutuyla yapabilirsiniz:

git checkout feature/kullanici-profili

veya

git switch feature/kullanici-profili

Hem dalı oluşturup hem de ona geçiş yapmak için kısa yolu da kullanabilirsiniz:

git checkout -b feature/kullanici-profili

veya

git switch -c feature/kullanici-profili

Artık feature/kullanici-profili dalındasınız ve burada yaptığınız tüm değişiklikler bu dala özgü olacaktır. Bu dalda geliştirmelerinizi yaparken, main dalınız tamamen güvende ve izole kalır.

4. Değişiklikleri Kaydetme (Commit)

Dalınızda kod değişiklikleri yaptıktan sonra, bunları düzenli olarak kaydetmeniz (commit) önemlidir:

git add .
git commit -m "Kullanıcı profili arayüzü eklendi"

Unutmayın, bu commit'ler sadece bulunduğunuz feature/kullanici-profili dalına kaydedilir.

5. Uzak Depoya Gönderme (Push)

Çalışmalarınızı diğer ekip üyeleriyle paylaşmak veya yedeklemek için dalınızı uzak depoya göndermeniz gerekir:

git push -u origin feature/kullanici-profili

-u (veya --set-upstream) parametresi, yerel dalınızı uzak depodaki aynı isimli dal ile ilişkilendirir, böylece sonraki git push komutlarını daha kısa yazabilirsiniz.

6. Dalları Silme

Özellik tamamlanıp main dala başarıyla birleştirildikten sonra, artık o dala ihtiyacınız kalmaz ve onu silebilirsiniz. Bu, deponuzun düzenli kalmasını sağlar:

git branch -d feature/kullanici-profili

Eğer dalınızda birleştirilmemiş değişiklikler varsa ve yine de silmek istiyorsanız -D (büyük harf D) kullanabilirsiniz, ancak bunu dikkatli yapmalısınız, çünkü bu işlem kaybolan değişikliklere yol açabilir.

git branch -D tehlikeli-dal

Uzak depodaki dalı silmek için ise:

git push origin --delete feature/kullanici-profili

Bu adımlar, Git dallarını etkin bir şekilde oluşturmanıza, üzerinde çalışmanıza ve yönetmenize yardımcı olacaktır. Dallanma, yazılım geliştirme süreçlerinde düzeni ve işbirliğini sağlayan temel bir mekanizmadır.

Dalları Birleştirme (Merging) Kavramı ve Çakışma Yönetimi Nasıl Çalışır?

Bir dalda yaptığınız değişiklikleri tamamladıktan ve bunların ana kod tabanına dahil edilmeye hazır olduğuna karar verdikten sonra, bu değişiklikleri birleştirme (merging) işlemi devreye girer. Birleştirme, bir dalın geçmişini ve içeriğini başka bir dala entegre etmek anlamına gelir. Git, bu birleştirme işlemini oldukça akıllıca yönetir, ancak bazen insan müdahalesi gerektiren durumlar da ortaya çıkar: çakışmalar (conflicts).

Genel olarak iki ana birleştirme türü vardır:

• Fast-Forward Birleştirme: Eğer hedef dalda (örneğin main) sizin dalınız oluşturulduktan sonra hiçbir yeni commit yapılmamışsa, Git hızlı ilerleme birleştirmesi yapar. Bu durumda, hedef dalın işaretçisi basitçe sizin dalınızın son commit'ine doğru ilerletilir. Geçmiş doğrusal kalır ve yeni bir birleştirme commit'i oluşmaz. Örneğin, main dalından feature/login dalı oluşturuldu ve siz bu dalda değişiklikler yaptınız. Bu süreçte main dalında başka hiçbir değişiklik olmadı. Bu durumda main dalına geri dönüp git merge feature/login komutunu verdiğinizde, main dalı işaretçisi feature/login dalının son commit'ine ilerletilir.
• Three-Way Birleştirme (Üç Yönlü Birleştirme): Eğer hedef dalda, sizin dalınız oluşturulduktan sonra yeni commit'ler yapılmışsa, Git birleştirme commit'i oluşturarak üç yönlü birleştirme yapar. Bu, her iki dalın ortak atası (common ancestor) ile mevcut durumları arasındaki farkları tespit eder ve bu değişiklikleri birleştirir. Bu durumda, geçmiş doğrusal olmaz ve yeni bir "merge commit" oluşur. Bu commit, birleştirilen iki dalın tüm geçmişini ve değişikliklerini içerir. Bu, daha karmaşık ama yaygın bir senaryodur ve genellikle birleştirme çakışmalarının ortaya çıktığı yerdir.

Birleştirme işlemini gerçekleştirmek için önce hedef dala geçmeniz gerekir:

git switch main
git pull origin main # Ana dalı güncel tutmak önemlidir
git merge feature/yeni-odeme-sistemi

Eğer birleştirme sorunsuz tamamlanırsa, Git size başarılı bir birleştirme mesajı gösterecektir. Ancak, eğer her iki dalda da aynı dosyanın aynı satırlarında veya birbirine çok yakın kod bloklarında farklı değişiklikler yapıldıysa, Git otomatik olarak nasıl birleştireceğine karar veremez. İşte bu noktada bir birleştirme çakışması (merge conflict) ortaya çıkar. Örneğin, bir ekip üyesi README.md dosyasının başlığını değiştirirken, siz de aynı dosyanın ilk paragrafını düzenlerseniz, Git genellikle bu tür çakışmaları kolayca çözer. Ancak eğer ikiniz de README.md dosyasının *aynı satırını* farklı şekillerde değiştirdiyseniz, işte o zaman bir çakışma yaşanır.

Bir çakışma meydana geldiğinde, Git birleştirme işlemini durdurur ve size hangi dosyaların çakıştığını bildirir. Bu dosyaları manuel olarak düzenlemeniz ve çakışmaları çözmeniz gerekir. Bu durum genellikle korkutucu görünse de, Git'in sağladığı araçlarla ve biraz pratikle kolayca yönetilebilir bir süreçtir. Çakışmalar, Git'in geliştiricilere kontrolü tam olarak verdiği anlardır, böylece hangi değişikliklerin kalacağına siz karar verirsiniz. Bu, kod tabanınızın bütünlüğünü ve doğruluğunu korumanın kritik bir parçasıdır.

Birleştirme Çakışmalarıyla Başa Çıkmak: Uygulamalı Çözümler Nelerdir?

Git birleştirme çakışmaları (merge conflicts), ekip çalışmasının ve paralel geliştirmenin doğal bir parçasıdır. Korkulacak bir durum değil, aksine Git'in size "Burada iki farklı değişiklik var, hangisinin kalacağına veya nasıl birleşeceğine sen karar ver" dediği bir an olarak görülmelidir. Bir çakışma meydana geldiğinde, Git birleştirme işlemini durdurur ve size hangi dosyalarda çakışma olduğunu bildirir. Bu dosyaları git status komutuyla görebilirsiniz:

git status

Bu komut, "Unmerged paths" (Birleştirilmemiş yollar) altında çakışan dosyaları listeler. Çakışan dosyaları bir metin düzenleyiciyle açtığınızda, Git'in eklediği özel işaretçileri göreceksiniz. Bu işaretçiler, çakışmanın nerede olduğunu ve hangi kodun hangi daldan geldiğini gösterir:

<<<<<<< HEAD
Bu kısım sizin mevcut dalınızdan (genellikle üzerine birleştirdiğiniz dal) geliyor.
=======
Bu kısım birleştirmeye çalıştığınız daldan geliyor.
>>>>>>> feature/yeni-ozellik

• <<<<<<< HEAD: Bu işaretçinin altındaki kod, şu anda üzerinde bulunduğunuz daldaki (yani birleştirmeyi yaptığınız dal, genellikle main) versiyonudur.
• =======: Bu çizgi, iki farklı versiyon arasındaki ayırıcıdır.
• >>>>>>> feature/yeni-ozellik: Bu işaretçinin altındaki kod ise, birleştirmeye çalıştığınız feature/yeni-ozellik dalından gelen versiyondur.

Çakışmayı çözmek için yapmanız gereken, bu işaretçileri ve istemediğiniz kod parçalarını silerek dosyanın nihai halini oluşturmaktır. Üç farklı yol izleyebilirsiniz:

1. Sizin Değişikliğinizi Koruma: Sadece <<<<<<< HEAD ve ======= arasındaki kodu koruyup diğerlerini silmek.
2. Birleştirdiğiniz Dalın Değişikliğini Koruma: Sadece ======= ve >>>>>>> feature/yeni-ozellik arasındaki kodu koruyup diğerlerini silmek.
3. Her İki Değişikliği Birleştirme: Her iki kodu da alıp, mantıksal bir sıra içinde birleştirmek ve ortaya çıkan kodu korumak. Bu genellikle en sık başvurulan yöntemdir.

Manuel olarak çözülmüş bir örnek:

Orijinal çakışan kod:

<<<<<<< HEAD
function helloWorld() {
    console.log("Merhaba, Dünya!");
}
=======
function greeting() {
    console.log("Hello there!");
}
>>>>>>> feature/greeting

Çakışmayı çözdükten sonra (örneğin her ikisini de koruyarak):

function helloWorld() {
    console.log("Merhaba, Dünya!");
}

function greeting() {
    console.log("Hello there!");
}

Tüm çakışmaları çözdüğünüzde ve dosyaları istediğiniz duruma getirdiğinizde, Git'e bu dosyaları çözdüğünüzü bildirmeniz gerekir. Bu, normal bir commit işlemi gibi git add ile yapılır:

git add <çakışan-dosya-adı>

Tüm çakışan dosyaları git add ile ekledikten sonra, birleştirme işlemini tamamlayan bir commit yapmanız gerekir:

git commit -m "feature/yeni-ozellik dalı main dalına birleştirildi, çakışmalar çözüldü."

Git, bu commit mesajını genellikle otomatik olarak sizin için doldurur, ancak açıklayıcı bir mesajla düzenlemek her zaman iyi bir pratiktir. Bu commit, birleştirme işleminin tamamlandığını ve çakışmaların başarıyla çözüldüğünü gösterir. Çözüm sürecinde bir sorun yaşarsanız veya baştan başlamak isterseniz, birleştirme işlemini git merge --abort komutuyla iptal edebilirsiniz. Bu, deponuzu birleştirme işleminden önceki haline döndürür ve yeni bir stratejiyle tekrar deneme imkanı sunar.

İleri Düzey Git Birleştirme Stratejileri: Rebase, Squash ve Daha Fazlası Nasıl Kullanılır?

Git'in temel birleştirme işlevleri çoğu zaman yeterli olsa da, daha karmaşık senaryolarda veya belirli bir geçmiş temizliği ihtiyacında ileri düzey stratejiler devreye girer. Özellikle git rebase ve git merge --no-ff gibi komutlar, projenizin Git geçmişini daha düzenli ve okunabilir hale getirmek için güçlü araçlardır.

Rebase vs Merge: Hangi Durumda Hangisi?

git rebase, bir dalın commit'lerini başka bir dalın üzerine "yeniden temel alma" işlemidir. Yani, bir dalın tüm geçmişini alıp, sanki o dal diğer dalın en son commit'inden yeni oluşturulmuş gibi gösterir. Bu, projenizin geçmişini doğrusal ve temiz tutar, birleştirme commit'lerinden kaçınır. Örneğin, main dalından feature/x dalını oluşturdunuz. main dalında bu süreçte yeni commit'ler yapıldı. feature/x dalını main üzerine birleştirmeden önce, feature/x dalına geçip git rebase main komutunu verirseniz, feature/x dalındaki commit'ler main dalının en son commit'inin üzerine taşınır. Bu işlemden sonra main dalına geçip git merge feature/x yaptığınızda, genellikle fast-forward bir birleştirme gerçekleşir ve geçmişte birleştirme commit'i oluşmaz.

Ne zaman rebase kullanılır?

• Yerel, henüz uzaktan paylaşılmamış bir dalda çalışırken ve geçmişi temizlemek, doğrusal bir tarih oluşturmak istediğinizde.
• Küçük, kişisel özellik dallarında sık sık main ile senkronize olmak ve geçmişi basitleştirmek için.

Ancak, uzak depoyla paylaşılmış dalları rebase etmekten kaçınmalısınız. Rebase, commit ID'lerini değiştirir ve bu, başkalarıyla aynı dal üzerinde çalışanlar için sorunlara yol açar, çünkü onların geçmişi sizin geçmişinizle uyuşmaz hale gelir.

Ne zaman merge kullanılır?

• Paylaşılan dalları birleştirirken veya bir dalın geçmişini olduğu gibi korumak istediğinizde.
• Birleştirme commit'lerinin, birleştirme olayını ve ilgili dalları kaydetmesini istediğinizde (ki bu birçok ekip için izlenebilirlik açısından önemlidir).

Squash Merge (Sıkıştırma Birleştirmesi)

Bazen, bir özellik dalı üzerinde çalışırken birçok küçük, deneysel veya ara commit yaparsınız. Bu commit'lerin her birinin ana dalın geçmişinde yer almasını istemeyebilirsiniz, ancak tüm bu değişikliklerin tek bir anlamlı commit olarak görünmesini tercih edersiniz. İşte bu noktada squash merge devreye girer. Squash merge, bir dalın tüm commit'lerini tek bir yeni commit'e sıkıştırır ve bu tek commit'i hedef dala birleştirir. Bu, ana dalın geçmişini çok daha temiz ve okunabilir hale getirir. Github veya GitLab gibi platformlar genellikle Pull Request'leri birleştirirken "Squash and Merge" seçeneğini sunar.

git merge --squash feature/kirli-dal # Bu komut, tüm commit'leri tek bir commit olarak hazırlar
git commit -m "feature/kirli-dal: Yeni özellik eklendi" # Ardından manuel olarak commit edilir

Cherry-Picking (Belirli Commit'leri Seçme)

Bazen, bir daldaki tüm değişiklikleri birleştirmek yerine, sadece belirli bir veya birkaç commit'i başka bir dala almak isteyebilirsiniz. Örneğin, bir test dalında yaptığınız acil bir hata düzeltmesi, henüz tamamlanmamış diğer özelliklerle birlikte ana dala birleştirilemeyecek durumdadır. Bu durumda, hata düzeltmesini içeren commit'i seçip doğrudan ana dala uygulayabilirsiniz. Bu işlem git cherry-pick komutuyla yapılır.

git switch main
git cherry-pick 

Bu, belirtilen commit'i hedef dala yeni bir commit olarak uygular. Çok dikkatli kullanılmalı ve gereksiz "duplicate" commit'lerden kaçınılmalıdır.

Bu ileri düzey teknikler, Git'i daha etkili bir şekilde kullanmanızı ve projenizin sürüm geçmişini daha temiz ve yönetilebilir hale getirmenizi sağlar. Doğru stratejiyi seçmek, ekibinizin ve projenizin özel ihtiyaçlarına bağlıdır.

Projelerinizde Mobil Uyumlu HTML Yapısı Nasıl Sağlanır? Pratik Yaklaşımlar

Git, kodunuzun versiyonlarını yönetir ve ekip çalışmasını kolaylaştırır. Ancak Git'in yönettiği web projelerinin kalitesi, kullanıcı deneyimi açısından hayati öneme sahiptir. Günümüz dünyasında, web sitelerinin ve uygulamaların mobil cihazlarda da sorunsuz çalışması bir zorunluluktur. Mobil uyumlu HTML (Responsive Web Design), içeriğin ve tasarımın farklı ekran boyutlarına ve cihazlara otomatik olarak uyum sağlamasını ifade eder. OSD600Lab3 gibi bir derste, Git öğrenirken aynı zamanda üzerinde çalıştığınız projenin teknik kalitesine de dikkat etmek, tam donanımlı bir geliştirici olmanın anahtarıdır. İşte Git ile yönettiğiniz projelerde mobil uyumlu HTML yapısı sağlamanın temel adımları ve pratik yaklaşımlar:

1. Viewport Meta Etiketi

Mobil uyumlu tasarımın ilk adımı, tarayıcıya sayfanın cihazın genişliğine göre ölçeklenmesi talimatını veren viewport meta etiketini eklemektir. Bu etiket, genellikle HTML belgesinin bölümünde yer alır:

Bu etiket olmadan, mobil tarayıcılar sayfanızı masaüstü boyutunda render edip küçültebilir, bu da okunabilirlik sorunlarına yol açar. width=device-width, sayfanın genişliğini cihazın ekran genişliğine ayarlarken, initial-scale=1.0 ise sayfanın ilk yüklemede %100 oranında yakınlaştırılmasını sağlar.

2. Esnek Izgaralar ve Medya Sorguları (Media Queries)

Sabit genişlikler yerine esnek birimler (yüzdeler, em, rem, vw, vh) kullanarak düzenlerinizi dinamik hale getirmelisiniz. Ayrıca, CSS Media Queries, belirli ekran genişliklerine, yüksekliklerine veya cihaz özelliklerine göre farklı stiller uygulamanıza olanak tanır. Bu, mobil cihazlar için farklı düzenler ve stiller tanımlamanın temelidir.

Yukarıdaki örnekte, .container sınıfı ve h1 başlığı için farklı ekran boyutlarına göre değişen stiller tanımlanmıştır. Bu sayede, içerik farklı cihazlarda en iyi şekilde görüntülenir.

3. Esnek Görseller (Flexible Images)

Görsellerin de esnek olması önemlidir. Sabit genişlik ve yükseklik tanımlamak yerine, genellikle maksimum genişliği %100 yaparak görsellerin kapsayıcı elementlerine uyum sağlamasını sağlayabilirsiniz:

4. Mobil İlk (Mobile-First) Yaklaşım

Mobil uyumlu tasarımda popüler ve önerilen bir yaklaşımdır. Önce en küçük ekran boyutları (mobil) için stil yazmaya başlanır, ardından medya sorguları kullanılarak daha büyük ekranlar için stiller kademeli olarak eklenir. Bu yaklaşım, gereksiz kod yükünü azaltır ve performansı artırır.

Sonuç olarak, Git ile kodunuzun değişimini ve işbirliğini yönetirken, projenizin son kullanıcıya ulaştığında nasıl göründüğü ve çalıştığı da eşit derecede önemlidir. Mobil uyumlu HTML yapıları, projenizin başarısı için kritik bir faktördür ve yukarıdaki pratik yaklaşımlar, Git depolarınızda geliştirdiğiniz web projelerinin her cihazda mükemmel bir deneyim sunmasına yardımcı olacaktır.

Sonuç: Git Dalları ve Birleştirmenin Stratejik Önemi

Git dallanma ve birleştirme mekanizmaları, modern yazılım geliştirmenin temel taşlarından biridir. Paralel geliştirme, hata düzeltmeleri ve yeni özellik entegrasyonlarını izole ve güvenli bir ortamda yürütme yeteneği, ekiplerin daha verimli çalışmasını sağlar. Bu makalede ele aldığımız temel kavramlar, dalların nasıl oluşturulduğu ve yönetildiği, birleştirme süreçleri ve çakışma çözümleri, projenizin sürüm kontrolünü sağlamak için vazgeçilmezdir. İleri düzey stratejiler (rebase, squash, cherry-pick) ve mobil uyumlu tasarım gibi ek hususlar ise, projenizin hem teknik kalitesini hem de kullanıcı deneyimini artırır. Git'in bu güçlü özelliklerini etkin bir şekilde kullanarak, OSD600Lab3 gibi projelerde hem bireysel hem de ekip olarak çok daha düzenli, kontrollü ve başarılı bir geliştirme süreci yürütebilirsiniz.

Sıkça Sorulan Sorular (SSS)