Git ile GitHub Arasındaki Fark: Yeni Başlayanlar için Rehber

Yıllarca “Git mi, GitHub mı?” sorusunu alan biri olarak şunu söyleyeyim: bu kavram karmaşası, aslında çok temel bir yanlış anlamadan kaynaklanıyor. Pek çok yeni başlayan, bu iki kavramı birbirinin yerine kullanıyor ya da birinin diğerini kapsadığını düşünüyor. Oysa Git bir araç, GitHub ise bu aracın üzerine inşa edilmiş bir hizmet. Bu farkı gerçekten kavradığınız anda, sürüm kontrolü dünyasının kapıları önünüzde açılıyor.

Git Nedir? Bilgisayarınızdaki Zaman Makinesi

Git, Linus Torvalds tarafından 2005 yılında Linux çekirdeği geliştirme sürecini yönetmek için yazılmış, dağıtık bir sürüm kontrol sistemidir. Bunu anlamanın en kolay yolu şu analoji: düşünün ki bir Word belgesi üzerinde çalışıyorsunuz ve her önemli değişiklikten sonra “belge_v1.docx”, “belge_v2_final.docx”, “belge_v2_final_GERCEKTEN_FINAL.docx” gibi kopyalar alıyorsunuz. Git tam olarak bu işi, ama çok daha akıllıca yapıyor.

Git, tamamen yerel çalışan bir araçtır. Yani internet bağlantısına ihtiyaç duymaz, bir sunucuya bağlı olmak zorunda değilsiniz. Değişiklikleriniz bilgisayarınızın diskinde, .git adlı gizli bir dizinde saklanır. Bu, aynı zamanda Git’in en güçlü özelliklerinden biridir: uçakta, dağ başında, internet olmayan bir yerde bile kodunuzu versiyonlayabilirsiniz.

Basit bir örnekle başlayalım. Yeni bir proje dizini oluşturup Git deposu başlatmak için:

mkdir projem
cd projem
git init

Bu komutun ardından dizinde .git klasörü oluşur. Artık bu dizin bir Git deposudur. Şimdi bir dosya oluşturup bunu takibe alalım:

echo "Merhaba, bu benim ilk projem" > README.md
git add README.md
git commit -m "İlk commit: README dosyası eklendi"

İşte bu kadar. Bu üç adım, Git’in temel döngüsünü özetliyor: değişiklik yap, sahneye al (stage), kayıt oluştur (commit). Hiçbir sunucu, hiçbir internet bağlantısı, hiçbir hesap gerekmedi.

Git’in Temel Kavramları

Git’i gerçekten anlamak için birkaç kavramı netleştirmek gerekiyor.

Repository (Depo)

Projenizin tüm dosyalarını ve bu dosyaların tarihçesini içeren yapıya repository (kısaca repo) diyoruz. git init ile yerel bir repo oluştururken, ilerleyen bölümlerde göreceğimiz gibi GitHub’dan bir repo klonlamak da mümkün.

Commit

Her commit, projenizin belirli bir andaki anlık görüntüsüdür. Git, değişikliklerin tamamını saklamaz; onun yerine her commit, bir öncekine göre farkları (diff) kaydeder. Bu sayede depo boyutu makul kalır.

# Tüm değişiklikleri görmek için
git log --oneline

# Belirli bir commit'teki değişiklikleri incelemek için
git show a1b2c3d

Branch (Dal)

Branch sistemi, Git’in en güçlü özelliklerinden biridir. Ana kodu bozmadan deneysel özellikler geliştirmenize, hata düzeltmeleri yapmanıza olanak tanır.

# Yeni bir branch oluştur ve geç
git checkout -b yeni-ozellik

# Mevcut branch'leri listele
git branch -a

# Ana branch'e geri dön
git checkout main

# Branch'i birleştir
git merge yeni-ozellik

Şunu düşünün: bir web sitesinin hem üretim ortamında çalışan sürümünü korurken hem de yeni bir ödeme modülü geliştiriyorsunuz. Branch olmadan ya üretimi riske atarsınız ya da geliştirmeyi tamamen ayrı bir yerde yapıp sonra elle birleştirirsiniz. Git’in branch sistemi bu sorunu zarif bir şekilde çözüyor.

GitHub Nedir? Git’in Buluttaki Evi

GitHub, 2008 yılında kurulan ve 2018’de Microsoft tarafından satın alınan bir web platformudur. Özünde, Git repolarını internette barındıran bir hizmet sunar. Ama bunu “sadece bir dosya depolama servisi” olarak düşünmek büyük bir hata olur.

GitHub’ın üzerine inşa edildiği temel: Git protokolü. Yani GitHub olmadan Git kullanabilirsiniz, ama GitHub’u Git olmadan kullanamazsınız. Bu ilişkiyi şöyle özetleyebiliriz: Git bir motor, GitHub ise bu motorun takıldığı araçtır.

GitHub’ın sağladıkları:

• Uzak depo barındırma: Kodunuzu bulutta saklar, ekip üyeleriyle paylaşmanızı sağlar
• Pull Request sistemi: Kod değişikliklerini incelemek ve tartışmak için yapılandırılmış bir süreç sunar
• Issues (Sorun takibi): Hataları, özellik isteklerini ve görevleri takip etmenizi sağlar
• Actions (CI/CD): Otomatik test ve dağıtım süreçleri oluşturmanıza olanak tanır
• Wiki ve Dokümantasyon: Proje belgelerini kodla birlikte tutmanızı sağlar
• Erişim kontrolü: Kim neyi görebilir, kim neyi değiştirebilir bunu yönetir

Git ve GitHub Birlikte Nasıl Çalışır?

Şimdi gerçek dünyaya gelelim. Diyelim ki bir web uygulaması geliştiriyorsunuz ve ekibinizle çalışmanız gerekiyor. İşte tipik bir iş akışı:

Adım 1: GitHub’da repo oluşturun ve yerel makinenize klonlayın.

# GitHub'da oluşturduğunuz repoyu yerel makinenize kopyalayın
git clone https://github.com/kullanici_adiniz/proje-adi.git
cd proje-adi

Adım 2: Değişikliklerinizi yapın ve commit edin.

# Yeni bir özellik için branch aç
git checkout -b kullanici-kimlik-dogrulama

# Değişikliklerinizi yapın, sonra...
git add .
git commit -m "Kullanıcı giriş formu eklendi"
git commit -m "JWT token doğrulama implementasyonu"

Adım 3: Değişikliklerinizi GitHub’a gönderin.

# Yerel branch'i uzak repoya gönder
git push origin kullanici-kimlik-dogrulama

Adım 4: Pull Request açın ve ekip incelemesi alın.

Bu adım artık GitHub’ın web arayüzünde gerçekleşir. Ekip üyeleriniz kodunuzu inceler, yorum yapar, gerekirse değişiklik ister. Bu süreç tamamen GitHub’ın sunduğu bir özelliktir, Git’in kendisiyle doğrudan ilgisi yoktur.

Adım 5: Merge işlemi ve güncelleme.

# Ana branch'e geçin ve güncel hale getirin
git checkout main
git pull origin main

Bu iş akışında dikkat edin: Git komutları (commit, push, pull, merge) yerel iş mantığını yönetirken, GitHub platformu iş birliği ve kod inceleme süreçlerini yönetiyor.

Uzak Depo Kavramı: Remote

Git’te remote kavramı, yerel deponuzun bağlı olduğu uzak depoyu ifade eder. Bu uzak depo GitHub’da olabileceği gibi, GitLab’da, Bitbucket’ta ya da kendi sunucunuzda da olabilir.

# Mevcut uzak depoları listele
git remote -v

# Yeni bir uzak depo ekle
git remote add origin https://github.com/kullanici/repo.git

# Uzak depodaki değişiklikleri çek ama birleştirme
git fetch origin

# Uzak depodaki değişiklikleri çek ve birleştir
git pull origin main

# Yerel değişiklikleri uzak repoya gönder
git push origin main

origin burada sadece bir isimdir. Git geleneği gereği ana uzak depoya origin denir, ama bunu istediğiniz gibi değiştirebilirsiniz. Birden fazla uzak depo kullanmak da mümkündür, örneğin hem GitHub hem de GitLab’a aynı anda push yapabilirsiniz.

Gerçek Dünya Senaryosu: Bir Felaket Anı

Bir production sunucusunda yaşanan gerçek bir senaryoyu paylaşmak istiyorum. Gece 02:00’de bir e-ticaret sitesinin ödeme modülünde kritik bir hata keşfedildi. Geliştirici ekibi hızla bir hotfix branch’i açtı:

# Ana branch'ten hotfix oluştur
git checkout main
git pull origin main
git checkout -b hotfix/odeme-hata-duzeltme

# Hata düzeltmesi yapıldı
git add src/payment/processor.py
git commit -m "fix: Ödeme işlemcisindeki null pointer exception düzeltildi

Kullanıcı kart bilgisi girilmeden ödeme butonu tıklandığında
uygulama çöküyordu. Null kontrol eklendi."

# GitHub'a gönder
git push origin hotfix/odeme-hata-duzeltme

GitHub’da bu branch için acil bir Pull Request açıldı, tek bir kıdemli geliştirici tarafından incelendi ve merge edildi. Otomatik deployment pipeline devreye girdi. Tüm bu süreç 23 dakika sürdü. Git’in branch sistemi olmasa, bu acil düzeltmeyi canlı koda doğrudan müdahale etmek zorunda kalacaklardı ve durum çok daha karmaşık bir hale gelebilirdi.

Yanlış Anlaşılan Bir Nokta: GitHub Tek Seçenek Değil

Pek çok yeni başlayan “Git kullanmak için GitHub hesabı açmak gerekir” sanıyor. Bu tamamen yanlış. Git’i şu senaryolarda GitHub’suz kullanabilirsiniz:

• Tamamen yerel bir projede (kişisel notlar, konfigürasyon dosyaları, script koleksiyonu)
• Kendi sunucunuzda barındırılan bir Git deposuyla (bare repository)
• GitLab, Bitbucket veya Gitea gibi alternatif platformlarla
• Ekibinizin iç ağındaki bir Git sunucusuyla

# Kendi sunucunuzda bare repository oluşturmak
# Sunucuda:
git init --bare /opt/git/projem.git

# İstemcide bu sunucuya bağlanmak:
git remote add sirket-sunucu ssh://[email protected]/opt/git/projem.git
git push sirket-sunucu main

Öte yandan GitHub da tek Git barındırma hizmeti değildir. Pek çok şirket, özellikle hassas kod geliştiren kurumsal yapılar, GitLab Community Edition’ı kendi altyapılarında çalıştırıyor.

Yeni Başlayanların Sık Yaptığı Hatalar

Commit Mesajlarını Hafife Almak

# Kötü örnek
git commit -m "değişiklik"
git commit -m "düzeltme"
git commit -m "asdf"

# İyi örnek
git commit -m "feat: kullanıcı profil fotoğrafı yükleme özelliği eklendi"
git commit -m "fix: mobil görünümde navbar overflow sorunu giderildi"
git commit -m "docs: API endpoint dokümantasyonu güncellendi"

Üç ay sonra bir hatanın nereden geldiğini araştırırken “düzeltme” yazılı 47 commit arasında boğulmak istemezsiniz.

Her Şeyi Main Branch’e Commit Etmek

Doğrudan main branch üzerinde çalışmak, özellikle ekip ortamlarında felakete davet çıkarmaktır. Her yeni özellik veya hata düzeltmesi için ayrı bir branch açın.

.gitignore Dosyasını Oluşturmamak

# .gitignore dosyası oluştur
cat > .gitignore << 'EOF'
# Node.js
node_modules/
npm-debug.log

# Python
__pycache__/
*.pyc
venv/
.env

# IDE
.vscode/
.idea/
*.swp

# OS
.DS_Store
Thumbs.db
EOF

git add .gitignore
git commit -m "chore: .gitignore dosyası eklendi"

Özellikle .env dosyalarını, veritabanı şifrelerini ya da API anahtarlarını yanlışlıkla commit edip GitHub’a push etmek ciddi güvenlik açıklarına yol açabilir. Bu konuda benim de bir “ah keşke” anım var ama o konuyu başka bir yazıya bırakalım.

GitHub’ın Ötesi: Platform Olarak Düşünmek

GitHub’ı sadece “kodu koyduğum yer” olarak görmek, onun potansiyelinin küçük bir parçasını kullanmak demektir. GitHub Actions, otomasyonun kapısını aralamaktadır.

Örneğin, her main branch’e push yapıldığında otomatik test çalıştıran ve ardından sunucuya deploy eden basit bir pipeline:

# .github/workflows/deploy.yml
name: Test ve Deploy

on:
  push:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Testleri çalıştır
        run: |
          pip install -r requirements.txt
          python -m pytest tests/

  deploy:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - name: Sunucuya deploy et
        run: |
          ssh [email protected] "cd /app && git pull && systemctl restart uygulama"

Bu dosyayı .github/workflows/ dizinine koyup commit etmeniz yeterli. Git değişikliği algılar, GitHub bu YAML dosyasını okur ve pipeline otomatik çalışır. Git’le GitHub’ın birlikte güç yarattığı nokta işte burası.

Hangi Durumda Hangisini Kastettiğimizi Bilelim

Teknoloji dünyasında dil kirliliği gerçek bir sorun. “GitHub’a atayım” derken aslında “Git ile commit edip push yapayım” kastediliyor çoğunlukla. “Git’i öğren” tavsiyesi verilirken aynı zamanda GitHub’ın kullanımı da bekleniyor. Bu belirsizlik, yeni öğrencilerin kafasını karıştırıyor.

Şunu netleştirelim:

• Git öğrenmek: Versiyon kontrol mantığını, branch yönetimini, merge/rebase kavramlarını ve komut satırı kullanımını öğrenmektir
• GitHub öğrenmek: Pull Request süreçlerini, Issues yönetimini, Actions pipeline’larını ve platform özelliklerini kullanmayı öğrenmektir

İkisi birbirini tamamlar ama ikisi aynı şey değildir. Öğrenme yolculuğunuzda önce Git’i anlayın, sonra GitHub’ı bunun üzerine inşa edin. Tersini yapmak, araba kullanmayı öğrenmeden navigasyon uygulaması kullanmaya çalışmak gibidir.

Sonuç

Git ve GitHub, modern yazılım geliştirmenin ayrılmaz iki parçası ama birbirinden farklı iki varlık. Git, bilgisayarınızda çalışan ve projenizin tarihçesini yöneten güçlü bir araç. GitHub ise bu aracı buluta taşıyan, üzerine iş birliği ve otomasyon özellikleri ekleyen bir platform.

Eğer bugün bu konuya yeni başlıyorsanız tavsiyem şu: önce birkaç gün sadece Git komutlarını öğrenmek için kullanın. Bir proje oluşturun, commit’ler atın, branch’ler açın, merge edin. Hiç GitHub olmadan. Temel Git akışını içselleştirince GitHub’a geçiş çok daha anlamlı olacak.

Öte yandan, Git’i ciddiye almanın getirisi büyük. İş görüşmelerinde “Git kullanıyorum” demek ile branch stratejilerini, cherry-pick’i, rebase vs merge farkını, etkileşimli staging’i anlatmak çok farklı izlenimler bırakıyor. Sürüm kontrolü, özellikle ekip çalışmasında, salt teknik bir beceriden öte bir iletişim aracına dönüşüyor.

Son olarak: GitHub’a rakip olarak görülen GitLab ve Bitbucket de aynı Git altyapısı üzerine kurulu. Bir platformda öğrendikleriniz diğerine kolayca transfer olur. Çünkü temelde hepsi aynı dili konuşuyor: Git.