Git ve GitHub ile Versiyon Kontrolüne Pratik Giriş: Baştan Sona Rehber

Yazılım geliştirme serüveninizde kodlarınızı kaybetmekten veya ekip arkadaşlarınızla koordinasyon sağlamakta zorlanmaktan mı sıkıldınız? Bu atölye, Git ve GitHub’ı kullanarak projelerinizi nasıl daha verimli yöneteceğinizi adım adım gösteriyor, sürüm kontrolünü pratik örneklerle öğretiyor.

Modern yazılım geliştirme dünyasında, tek başına veya bir ekiple çalışırken kodlarımızın kontrolünü elinde tutmak, geçmişe dönmek, değişiklikleri takip etmek ve olası hatalardan kurtulmak hayati öneme sahiptir. İşte tam da bu noktada versiyon kontrol sistemleri (VCS) devreye giriyor. Peki, versiyon kontrol sistemi tam olarak nedir ve neden özellikle Git ve GitHub ikilisi bu kadar popüler hale geldi?

Versiyon kontrol sistemi, zaman içindeki dosya değişikliklerini izleyen bir yazılımdır. Yani, kodunuzun her bir sürümünü bir “anlık görüntü” olarak kaydedebilir, istediğiniz zaman eski bir sürüme geri dönebilir veya farklı sürümleri karşılaştırabilirsiniz. Bu, özellikle karmaşık projelerde veya çok sayıda geliştiricinin aynı anda çalıştığı ortamlarda büyük bir kolaylık sağlar. Git, bu sistemlerin en popüler ve dağıtık olanlarından biridir. Dağıtık olması, her geliştiricinin kendi bilgisayarında projenin tam bir kopyasına sahip olduğu ve internet bağlantısı olmadan bile çoğu işlemi gerçekleştirebileceği anlamına gelir. Bu da esneklik ve hız açısından önemli avantajlar sunar.

GitHub ise, Git depolarınızı barındıran, sosyal kodlama ve işbirliği platformudur. Git’in yerel versiyon kontrol yeteneklerini alıp, onu bulut tabanlı bir platformla birleştirerek, dünya genelindeki geliştiricilerin projeler üzerinde kolayca işbirliği yapmasını sağlar. Açık kaynak projelerin kalbi adeta GitHub’da atar. Projelerinizi GitHub’a yükleyerek hem güvende tutar hem de diğer geliştiricilerin katkılarına açabilirsiniz. Ayrıca, pull request’ler, code review araçları ve issue tracker gibi özellikleriyle ekip içi iletişimi ve proje yönetimini de üst düzeye taşır.

Bu makalede, Git’in temel komutlarından başlayarak, GitHub ile entegrasyonuna, ileri düzey özelliklerine ve gerçek dünya senaryolarına kadar her şeyi adım adım öğreneceğiz. İster yeni başlayan bir geliştirici olun ister tecrübeli, bu pratik rehber sayesinde versiyon kontrolü ve işbirliği süreçlerinizi bir sonraki seviyeye taşıyacaksınız. Hadi, “Manos a la obra” diyelim ve Git ile GitHub dünyasına dalalım!

Git’in Temelleri: Versiyon Kontrol Sistemi Nedir ve Nasıl Başlarsınız?

Git, Torvalds tarafından Linux çekirdeği geliştirilmesi için tasarlanmış, dağıtık bir versiyon kontrol sistemidir. Diğer merkezi sistemlerin aksine, Git’te her geliştiricinin çalışma dizininde projenin tam geçmişinin bir kopyası bulunur. Bu sayede, internet bağlantısı olmadan bile ‘commit’ yapabilir, geçmişi inceleyebilir ve ‘branch’ler arasında geçiş yapabilirsiniz. Git’i anlamanın ilk adımı, temel iş akışını ve kullandığı kavramları öğrenmekten geçer. Git, çalışma dizini (working directory), hazırlık alanı (staging area) ve yerel depo (local repository) olmak üzere üç ana alana sahiptir. Değişiklikleriniz bu alanlar arasında dolaşarak son halini alır.

Git’e başlamak için öncelikle bilgisayarınıza Git’i kurmanız gerekmektedir. İşletim sisteminize göre farklı kurulum yöntemleri bulunur. Örneğin, Windows için Git Bash veya Git for Windows installer’ı, macOS için Homebrew (brew install git) ya da Linux dağıtımları için paket yöneticileri (sudo apt-get install git) kullanılabilir. Kurulumdan sonra, terminalinizde veya komut istemcinizde Git’in düzgün çalıştığını doğrulamak için git --version komutunu çalıştırabilirsiniz.

İlk projenizi başlatmadan önce, Git’e kim olduğunuzu tanıtmanız gerekir. Bu, yaptığınız her ‘commit’in kim tarafından yapıldığını belirtmek için önemlidir:

git config --global user.name "Adınız Soyadınız"
git config --global user.email "eposta@adresiniz.com"

Artık yeni bir projeyi Git ile yönetmeye hazırsınız. Mevcut bir klasörü Git deposuna dönüştürmek için o klasörün içine girip git init komutunu çalıştırmanız yeterlidir. Bu komut, klasörünüze gizli bir .git dizini ekleyerek Git'in izleme sürecini başlatır.

cd /path/to/your/project
git init

Git'in temel felsefesi, değişiklikleri "anlık görüntüler" halinde kaydetmektir. Bir dosya üzerinde değişiklik yaptığınızda, Git bu değişikliği hemen kaydetmez. Önce bu değişikliği bir sonraki 'commit'e dahil etmek üzere "hazırlık alanına" almanız gerekir:

git add dosya_adi.txt
git add . # Tüm değişiklikleri hazırlık alanına alır

Hazırlık alanına aldığınız değişiklikleri kalıcı olarak yerel deponuza kaydetmek için git commit komutunu kullanırız. Her 'commit'e, yapılan değişiklikleri açıklayan kısa ve öz bir mesaj eklemek önemlidir:

git commit -m "İlk commit: Proje başlangıcı ve temel dosyalar eklendi"

Bu temel adımlarla, Git'in yerel bir depo üzerindeki gücünü hissetmeye başlayabilirsiniz. Dosyalarınızı versiyonlamanın ve değişikliklerinizi kaydetmenin ne kadar kolay olduğunu göreceksiniz. Projenizin geçmişini görmek için git log komutunu kullanabilir, önceki 'commit'lere ait detayları inceleyebilirsiniz. Git'in bu temel yapısını kavramak, daha karmaşık iş akışlarına ve ekip çalışmalarına geçişte sağlam bir zemin oluşturacaktır.

GitHub ile Depo Yönetimi ve Uzak Bağlantılar Nasıl Kurulur?

Git'in yerel bilgisayarınızdaki gücünü anladıktan sonra, sıra bu gücü GitHub'ın bulut tabanlı platformuyla birleştirmeye geliyor. GitHub, Git depolarınızı barındırmanın yanı sıra, ekip üyeleriyle işbirliği yapmanızı, projelerinizi dünyaya açmanızı ve kodunuzu güvenli bir şekilde saklamanızı sağlayan bir dizi özellik sunar. Peki, yerel bir Git deposunu GitHub ile nasıl entegre edebiliriz?

Öncelikle, GitHub üzerinde bir hesap oluşturmanız ve yeni bir depo (repository) yaratmanız gerekiyor. GitHub arayüzünde "New repository" düğmesine tıklayarak depo adını, açıklamasını girip, public mi yoksa private mı olacağını seçerek kolayca bir depo oluşturabilirsiniz. Bu aşamada README dosyası, .gitignore veya lisans eklemek isteyip istemediğinizi de belirleyebilirsiniz. Yeni bir depo oluşturduğunuzda, GitHub size yerel deponuzu bu uzak depoya nasıl bağlayacağınıza dair komutlar sunacaktır.

Yerel deponuzu GitHub'daki uzak depoyla bağlamak için git remote add komutunu kullanırız. Genellikle uzak deponuza "origin" adını veririz:

git remote add origin https://github.com/kullaniciadi/repo-adi.git

Bu komut, yerel deponuza GitHub'daki depoyu "origin" adıyla tanıtır. Artık yerel 'commit'lerinizi GitHub'a gönderebilirsiniz. İlk gönderme işleminde -u (upstream) veya --set-upstream bayrağını kullanarak yerel 'master' (veya 'main') branch'inizi uzak deponun 'master' branch'ine bağlamanız önerilir:

git push -u origin main

Bu adımdan sonra, yerel deponuzdaki yeni 'commit'leri GitHub'a göndermek için sadece git push komutunu kullanmanız yeterli olacaktır. Benzer şekilde, ekip arkadaşlarınızın GitHub'a gönderdiği değişiklikleri kendi yerel deponuza çekmek için git pull komutunu kullanırsınız:

git pull origin main

GitHub ile çalışmanın bir diğer popüler yolu ise mevcut bir depoyu klonlamaktır. Eğer bir projeye katkıda bulunmak istiyorsanız veya açık kaynak bir projeyi incelemek istiyorsanız, o depoyu kendi bilgisayarınıza kopyalamanız gerekir:

git clone https://github.com/kullaniciadi/repo-adi.git

Bu komut, uzak depoyu tüm geçmişiyle birlikte kendi bilgisayarınıza indirir ve otomatik olarak uzak depoyu "origin" olarak ayarlar. Böylece hemen çalışmaya başlayabilirsiniz. GitHub, sadece kod barındırma değil, aynı zamanda projelerinizi yönetmek, hata izlemek (issues), pull request'ler aracılığıyla kod incelemeleri yapmak ve projelerinize yıldız vermek gibi birçok sosyal özellik sunar. Bu araçlar, geliştiricilerin daha organize ve işbirlikçi bir şekilde çalışmasına olanak tanır.

GitHub entegrasyonu, hem kişisel projelerinizde bir yedekleme ve sürüm geçmişi tutmanızı sağlar hem de profesyonel iş akışlarında ekip çalışmasının temelini oluşturur. Bu adımları uygulayarak, Git ve GitHub'ın sunduğu bu güçlü ekosisteme ilk adımlarınızı atmış olacaksınız.

Ekip Çalışmasını Kolaylaştıran Branching, Merging ve Pull Request Süreçleri

Git'in belki de en güçlü özelliklerinden biri, 'branching' yani dallanmadır. 'Branch'ler, ana kod tabanından (genellikle 'main' veya 'master' branch) ayrı, bağımsız geliştirme hatları oluşturmanıza olanak tanır. Bu sayede, yeni bir özellik üzerinde çalışırken veya bir hatayı düzeltirken ana kod tabanını etkilemeden denemeler yapabilir ve değişikliklerinizi izole bir ortamda geliştirebilirsiniz. Bu, özellikle bir ekip ortamında birden fazla kişinin aynı anda farklı görevler üzerinde çalıştığı durumlarda kritik öneme sahiptir.

Yeni bir 'branch' oluşturmak ve ona geçiş yapmak oldukça basittir:

git branch yeni-ozellik
git checkout yeni-ozellik

Veya daha kısa yoldan hem oluşturup hem geçiş yapmak için:

git checkout -b yeni-ozellik

Artık 'yeni-ozellik' branch'indesiniz ve yaptığınız tüm 'commit'ler bu branch üzerinde kaydedilecektir. Ana branch'e geri dönmek için git checkout main komutunu kullanabilirsiniz. Mevcut branch'leri listelemek ve hangi branch'te olduğunuzu görmek için ise git branch komutu yeterlidir.

'Branch'inizdeki geliştirmeler tamamlandığında ve testlerinizden geçtiğinde, bu değişiklikleri ana branch'e entegre etmeniz gerekir. Bu işleme 'merging' (birleştirme) denir. Ana branch'e geçiş yaptıktan sonra, geliştirmelerinizi içeren branch'i ana branch ile birleştirebilirsiniz:

git checkout main
git merge yeni-ozellik

Bu komut, 'yeni-ozellik' branch'indeki tüm 'commit'leri 'main' branch'ine taşır. Birleştirme işlemi sırasında, aynı dosyaların aynı satırlarında farklı değişiklikler yapılmışsa 'çatışmalar' (conflicts) meydana gelebilir. Bu durumda Git, hangi değişikliğin kalması gerektiğine karar vermenizi ister. Çatışmaları manuel olarak çözdükten sonra, değişen dosyaları git add ile hazırlık alanına alıp bir 'merge commit'i yapmanız gerekir.

GitHub bağlamında, 'branching' ve 'merging' süreçlerinin en iyi pratik uygulaması 'Pull Request' (PR) veya 'Merge Request' (MR) kullanımıdır. Kendi geliştirdiğiniz 'branch'i uzak depoya (GitHub'a) gönderdikten sonra, GitHub arayüzü üzerinden bir 'Pull Request' açarsınız:

git push origin yeni-ozellik

Bir 'Pull Request', değişikliklerinizin ana branch'e birleştirilmesi için resmi bir talep oluşturur. Bu süreç, ekip üyelerinin kodunuzu incelemesine (code review), yorum yapmasına ve potansiyel sorunları erken aşamada tespit etmesine olanak tanır. Kod incelemesi tamamlandığında ve gerekli düzeltmeler yapıldığında, 'Pull Request' birleştirilerek değişiklikler ana branch'e dahil edilir. Bu döngü, yazılım geliştirme ekiplerinde temiz ve hatasız kod tabanı sürdürmenin anahtarıdır.

Aşağıdaki tablo, Git branch tiplerinin yaygın kullanım senaryolarını özetlemektedir:

'Branching', 'merging' ve 'Pull Request' süreçlerini etkin bir şekilde kullanmak, ekip çalışmasında verimliliği artırmanın ve karmaşık projeleri yönetmenin temel taşlarındandır. Bu süreçleri iyi kavramak, profesyonel bir geliştiricinin olmazsa olmazıdır.

Profesyonel Geliştirici İçin İleri Düzey Git Teknikleri ve Çatışma Çözümleri

Git'in temel komutlarına ve GitHub ile işbirliğine hakim olduktan sonra, daha karmaşık durumlarla başa çıkmak ve iş akışınızı optimize etmek için ileri düzey tekniklere geçiş yapabiliriz. Bu bölümde, özellikle 'rebase', 'cherry-pick', 'stash' gibi güçlü komutları ve çatışma çözümü stratejilerini ele alacağız. Bu teknikler, daha temiz bir 'commit' geçmişi oluşturmanıza, projeler arasında kod taşımanıza ve beklenmedik durumları daha zarif bir şekilde yönetmenize yardımcı olacaktır.

Git Rebase: Daha Temiz Bir Geçmiş İçin

'Rebase', 'merge' işlemine alternatif olarak 'branch' geçmişinizi yeniden yazmanıza olanak tanır. Temelde, bir 'branch'teki 'commit'leri başka bir 'branch'in üzerine taşıyarak, doğrusal ve temiz bir geçmiş oluşturur. Bu, özellikle küçük, kişisel 'branch'lerde çalışırken ve değişikliklerinizi 'main' branch'ine göndermeden önce geçmişi düzenlemek istediğinizde faydalıdır. Örneğin, 'feature' branch'inizdeki 'commit'leri 'main' branch'inin en son haline göre yeniden düzenlemek isteyebilirsiniz:

git checkout feature-branch
git rebase main

Bu komut, 'feature-branch'indeki 'commit'leri 'main' branch'inin en son 'commit'inden sonraymış gibi yeniden uygular. 'Rebase' sırasında da 'merge'de olduğu gibi çatışmalar ortaya çıkabilir. Bu durumda Git, çatışmaları çözmenizi ve ardından git rebase --continue ile devam etmenizi ister. 'Rebase'in en önemli kuralı, paylaşılan 'branch'lerde (yani başkalarının da kullandığı 'branch'lerde) 'rebase' yapmaktan kaçınmaktır, çünkü bu onların geçmişini karıştırabilir.

Git Cherry-pick: Seçici Kod Aktarımı

Bazen bir 'branch'ten sadece belirli bir 'commit'i başka bir 'branch'e taşımak isteyebilirsiniz. İşte bu noktada git cherry-pick komutu devreye girer. Bu komut, başka bir 'branch'ten belirli bir 'commit'i seçer ve onu mevcut 'branch'inize yeni bir 'commit' olarak uygular. Bu, özellikle bir 'bug fix'in farklı 'branch'lere hızla aktarılması veya bir 'feature' 'commit'inin erken entegrasyonu gibi durumlarda kullanışlıdır.

git checkout hedef-branch
git cherry-pick 

Burada , taşımak istediğiniz 'commit'in benzersiz kimliğidir.

Git Stash: Geçici Değişiklikleri Saklama

Bir 'branch' üzerinde çalışırken, acil bir hata düzeltmesi yapmanız veya başka bir 'branch'e geçmeniz gerekebilir, ancak mevcut değişiklikleriniz 'commit' edilecek kadar hazır değildir. Bu durumda git stash, mevcut değişikliklerinizi geçici olarak bir kenara koymanızı (saklamanızı) sağlar, böylece çalışma dizininizi temizleyebilir ve başka bir işe geçebilirsiniz:

git stash save "Devam eden iş: Kullanıcı kayıt formu"

İşiniz bittiğinde ve sakladığınız değişikliklere geri dönmek istediğinizde:

git stash pop # En son saklanan değişikliği uygular ve listeden çıkarır
git stash apply # En son saklanan değişikliği uygular, listede bırakır

Sakladığınız tüm değişiklikleri görmek için git stash list komutunu kullanabilirsiniz.

Çatışma Çözümü Stratejileri ve Gerçek Dünya Senaryoları

'Merge' veya 'rebase' sırasında çatışmalar kaçınılmazdır. İyi bir geliştirici, bu çatışmaları etkin bir şekilde çözmeyi bilmelidir. Çatışma çözümü, Git'in çatışan bölgeyi işaretlediği dosyalarda hangi kodun kalacağına karar vermek ve ardından dosyaları git add ile işaretleyip 'commit' etmektir. İşte bir vaka analizi:

Vaka Analizi: Ortak Bir Dosyadaki Çatışma

Bir ekipte iki geliştirici, Ayşe ve Can, aynı musteri_bilgileri.py dosyasında çalışıyor. Ayşe, müşteri veritabanı bağlantısını güncellerken, Can ise aynı dosyadaki müşteri bilgileri formatlama fonksiyonunu değiştiriyor. Her ikisi de kendi 'branch'lerinde değişikliklerini 'commit' edip 'main' branch'ine birleştirmek istiyor.

1. Ayşe, kendi 'feature/db-update' branch'inde değişikliklerini yapar ve 'main' branch'ine 'merge' eder.
2. Can, 'feature/format-customer' branch'inde çalışır. Kendi değişikliklerini 'main' branch'ine 'merge' etmeye çalıştığında, Git bir çatışma olduğunu bildirir çünkü her ikisi de musteri_bilgileri.py dosyasının belirli bir bölümünü değiştirmiştir.

Can'ın yapması gerekenler:

git checkout main
git pull origin main # En son değişiklikleri çek
git checkout feature/format-customer
git merge main # Can'ın branch'ini main ile birleştirirken çatışma yaşanır.

Git, çatışma yaşanan dosyalarda <<<<<<<, ======= ve >>>>>>> işaretçileriyle çatışan bölgeleri gösterir. Can, bu dosyayı açar, Ayşe'nin değişiklikleriyle kendi değişikliklerini dikkatlice inceleyerek doğru kodu birleştirir. Ardından:

git add musteri_bilgileri.py
git commit -m "Merge main into feature/format-customer and resolve conflicts"
git push origin feature/format-customer # Güncellenmiş branch'i GitHub'a gönderir

Can, şimdi bir 'Pull Request' açabilir ve kod incelemesi sonrası 'feature/format-customer' branch'i 'main' ile birleştirilebilir. Çatışma çözümünde sabır ve dikkat esastır. Hangi kodun ne işe yaradığını anlamak ve ekiple iletişimde kalmak, bu süreci çok daha kolay hale getirir. Bu ileri düzey teknikler ve stratejiler, Git ve GitHub kullanımınızı daha verimli, güvenli ve profesyonel bir seviyeye taşıyacaktır.

Git ve GitHub ile Verimliliği Artırma: En İyi Uygulamalar ve Sıkça Sorulan Sorular

Git ve GitHub'ı etkin bir şekilde kullanmak, sadece komutları bilmekten öte, belirli en iyi uygulamaları benimsemeyi ve iş akışınızı optimize etmeyi gerektirir. Bu bölüm, projelerinizde daha verimli olmanızı sağlayacak ipuçlarını, sürdürülebilir bir geliştirme süreci için kritik uygulamaları ve sıkça sorulan soruları ele almaktadır.

En İyi Uygulamalar (Best Practices)

1. Küçük ve Sık 'Commit'ler Yapın: Her 'commit'in tek bir mantıksal değişikliği içermesi önemlidir. Bu, geçmişi daha okunabilir yapar, hataları izlemeyi kolaylaştırır ve 'revert' veya 'cherry-pick' gibi işlemlerin etkinliğini artırır. Bir 'commit' mesajı, değişikliğin neden yapıldığını ve neyi çözdüğünü net bir şekilde açıklamalıdır.

   
   git commit -m "feat: Kullanıcı giriş sayfası eklendi"
   git commit -m "fix: Giriş formu doğrulama hatası giderildi"
           

2. Anlamlı 'Branch' Adları Kullanın: 'Branch' adları, üzerindeki işi yansıtmalıdır. Örneğin, feature/login-page, bugfix/user-profile-bug veya refactor/database-queries gibi isimler, o 'branch'te ne yapıldığını ilk bakışta gösterir.
3. 'Pull Request'leri (PR) Etkin Kullanın: PR'lar sadece kod birleştirme talepleri değildir; aynı zamanda kod incelemesi, tartışma ve işbirliği platformlarıdır. PR'larınıza açıklayıcı başlıklar ve detaylı açıklamalar ekleyin. Değişikliğin amacını, yapılan testleri ve varsa ilişkili 'issue'ları belirtin.
4. .gitignore Dosyasını Kullanın: Derleme çıktıları, IDE ayarları, hassas bilgiler (API anahtarları) gibi dosyaların Git deposuna yanlışlıkla dahil edilmesini engellemek için .gitignore dosyasını akıllıca yapılandırın.
5. Sürekli Entegrasyon/Sürekli Dağıtım (CI/CD) Entegre Edin: GitHub Actions gibi CI/CD araçları, her 'push' veya 'pull request'te otomatik testler çalıştırmanıza, kod kalitesi kontrolleri yapmanıza ve hatta otomatik dağıtım yapmanıza olanak tanır. Bu, hataları erken yakalar ve geliştirme sürecini hızlandırır.

   
   # Örnek bir GitHub Actions YAML snippet'i
   name: CI
   on: [push, pull_request]
   jobs:
     build:
       runs-on: ubuntu-latest
       steps:
       - uses: actions/checkout@v2
       - name: Set up Node.js
         uses: actions/setup-node@v2
         with:
           node-version: '14'
       - run: npm install
       - run: npm test
           

6. Belgeleme ve README Dosyası: Projenizin nasıl kurulacağını, çalıştırılacağını ve katkıda bulunulacağını açıklayan kapsamlı bir README.md dosyası bulundurun. Bu, yeni ekip üyeleri veya açık kaynak katkıcıları için yol göstericidir.

Bu uygulamalar, sadece bireysel geliştirici olarak değil, aynı zamanda bir ekip içinde çalışırken de daha düzenli, hatasız ve hızlı bir geliştirme süreci sağlamanıza yardımcı olacaktır. Git ve GitHub'ı bir araç olmaktan çıkarıp, iş akışınızın doğal bir parçası haline getirmek, uzun vadede verimliliğinizi önemli ölçüde artıracaktır.

Sonuç: Git ve GitHub Ustalığına Giden Yol ve Sıkça Sorulan Sorular

Bu makalede, Git ve GitHub'ın temellerinden başlayarak, ileri düzey özelliklerine ve gerçek dünya kullanım senaryolarına kadar geniş bir yelpazeyi ele aldık. Versiyon kontrol sistemlerinin neden bu kadar önemli olduğunu, Git'in yerel çalışma prensiplerini, GitHub ile uzaktan işbirliğinin nasıl yapıldığını ve 'branching', 'merging', 'Pull Request' gibi ekip odaklı süreçleri derinlemesine inceledik. Ayrıca, 'rebase', 'cherry-pick', 'stash' gibi profesyonel geliştirici teknikleri ve çatışma çözümü stratejileri üzerinde durarak, temiz bir kod geçmişi oluşturmanın ve verimli bir iş akışı sürdürmenin yollarını öğrendik.

Git ve GitHub, günümüz yazılım geliştirme ekosisteminin vazgeçilmez araçlarıdır. Onları ustaca kullanmak, sadece kodunuzu yönetmekle kalmaz, aynı zamanda ekip içinde iletişimi güçlendirir, geliştirme süreçlerini hızlandırır ve yazılım kalitesini artırır. Unutmayın, Git'i öğrenmek bir maratondur, sprint değil. Pratik yaparak, farklı senaryolarla karşılaşarak ve sürekli öğrenerek bu araçlarda ustalaşacaksınız. Bu atölyede edindiğiniz bilgilerle, "Manos a la obra" diyerek kendi projelerinizi başarıyla yönetmeye ve açık kaynak topluluğuna katkıda bulunmaya hazırsınız!

Sıkça Sorulan Sorular (SSS)

1. Git ve GitHub arasındaki temel fark nedir?

   Git, yerel bilgisayarınızda çalışan, dağıtık bir versiyon kontrol sistemidir. Dosya değişikliklerini izlemenizi, geçmişe dönmenizi ve farklı sürümleri yönetmenizi sağlar. GitHub ise, Git depolarınızı barındıran, bulut tabanlı bir platformdur. Git depolarınızı uzak bir sunucuda tutarak yedekleme, ekip işbirliği, kod incelemesi ve proje yönetimi gibi özellikler sunar.

2. Branching (dallanma) neden önemlidir?

   'Branching', ana kod tabanından bağımsız geliştirme hatları oluşturmanızı sağlar. Bu sayede, yeni özellikler üzerinde çalışırken veya hataları düzeltirken ana kodu bozmadan izole bir ortamda denemeler yapabilirsiniz. Özellikle ekip çalışmalarında, her geliştiricinin kendi 'branch'inde güvenle çalışmasına olanak tanır ve ana 'branch'in stabilitesini korur.

3. Merge (birleştirme) ve Rebase (yeniden temel alma) arasındaki fark nedir?

   'Merge', iki 'branch'in geçmişini birleştirerek yeni bir 'merge commit'i oluşturur. Bu, geçmişi olduğu gibi korur. 'Rebase' ise, bir 'branch'teki 'commit'leri başka bir 'branch'in üzerine taşıyarak geçmişi yeniden yazar, daha doğrusal ve temiz bir geçmiş oluşturur. Genellikle, paylaşılan 'branch'lerde 'merge' tercih edilirken, kişisel 'branch'lerde 'rebase' daha temiz bir geçmiş için kullanılabilir.

4. Çatışma (conflict) nasıl çözülür?

   Çatışma, aynı dosyanın aynı satırlarında farklı değişiklikler yapıldığında meydana gelir. Git, çatışan bölgeleri özel işaretleyicilerle gösterir. Çatışmayı çözmek için, dosyayı açmalı, hangi kodun kalacağına karar vermeli veya iki değişikliği birleştirmelisiniz. Çatışma çözüldükten sonra, dosyayı git add ile hazırlık alanına alıp bir 'commit' yapmanız gerekir.

5. .gitignore dosyası ne işe yarar?

   .gitignore dosyası, Git'in izlememesi gereken dosya ve klasörleri belirtmek için kullanılır. Derleme çıktıları, log dosyaları, bağımlılık klasörleri (node_modules/ gibi), işletim sistemine özel dosyalar (.DS_Store) veya hassas veriler (API anahtarları) gibi dosyaların Git deposuna yanlışlıkla dahil edilmesini engeller, böylece deponuzu temiz ve güvenli tutar.