Git Nedir? Versiyon Kontrol Sistemi Başlangıç Rehberi

Bir projede saatlerce çalıştın, her şey mükemmel gidiyordu. Sonra "küçük bir değişiklik" yaptın ve her şey bozuldu. Geri almak istiyorsun ama nasıl? proje_final_v2_gercekten_final_son.zip mı açacaksın? İşte tam bu noktada Git hayatını kurtarıyor.

Bu rehberde git nedir sorusundan başlayıp, temel kavramları, komutları ve profesyonel iş akışlarını adım adım öğreneceksin. Yazının sonunda kendi projelerinde Git kullanmaya başlayacak kadar bilgi sahibi olacaksın.

Versiyon Kontrol Neden Önemli?

Versiyon kontrol sistemi (Version Control System — VCS), dosyalardaki değişiklikleri zaman içinde takip eden bir sistemdir. Bir nevi dosyaların için zaman makinesi gibi düşünebilirsin.

Versiyon kontrol olmadan projede çalışmak, kaydetme butonu olmayan bir Word belgesi yazmak gibidir — bir hata yaptığında geri dönüş yok.

Versiyon Kontrol Olmadan Yaşanan Klasik Sorunlar

• "Çalışan versiyonu kaybettim" — Yeni özellik eklerken eski, stabil kodu ezip geçtin

• "Kim bu satırı değiştirdi?" — Takımda 3 kişi aynı dosyaya dokundu, sorunlu satırı kim yazdı kimse bilmiyor

• "Dosyaları birleştiremiyorum" — Ahmet backend'i değiştirdi, Ayşe frontend'i güncelledi, ikisini birleştirmek kabusa döndü

• "Backup yok" — Bilgisayar bozuldu, 3 aylık çalışma buhar oldu

Bu sorunların tamamını versiyon kontrol sistemleri çözer. Ve bu sistemlerin tartışmasız kralı da Git'tir.

💡 İstatistik: Stack Overflow'un 2023 Developer Survey'ine göre, yazılımcıların %93'ünden fazlası Git kullanıyor. Bu, Git'in sektör standardı olduğunu açıkça gösteriyor.

Git Nedir?

Git, 2005 yılında Linus Torvalds (evet, Linux'u yaratan kişi!) tarafından geliştirilen, dağıtık (distributed) bir versiyon kontrol sistemidir.

Hikâye şöyle gelişti: Linux çekirdeği geliştirilirken kullanılan ticari VCS aracının lisansı iptal edildi. Linus Torvalds mevcut alternatifleri beğenmedi ve iki hafta içinde Git'in ilk versiyonunu çıkardı. İki hafta. Linux çekirdeğini yönetecek bir VCS. Bu adam gerçekten farklı bir seviye.

Git'in Temel Felsefesi

Git'i diğer VCS'lerden ayıran en önemli özellik dağıtık olmasıdır. Peki bu ne demek?

Merkezi (Centralized) VCS — SVN gibi sistemlerde tek bir sunucu vardır. Herkes bu sunucuya bağlanır, geçmişi görmek için sunucuya sormak gerekir. Sunucu çökerse? Geçmiş kaybolur.

Dağıtık (Distributed) VCS — Git'te ise herkes projenin tam bir kopyasına sahiptir. Tüm geçmiş, tüm branch'ler, her şey senin bilgisayarında. İnternet olmasa bile çalışabilirsin. Sunucu çökse bile herhangi birinin bilgisayarından proje kurtarılabilir.

Bunu şöyle düşün: Merkezi VCS bir kütüphane gibidir — kitabı ödünç alırsın, geri verirsin. Git ise herkese kitabın tam bir fotokopisini verir. İstediğin zaman okuyabilir, not alabilir, sonra paylaşabilirsin.

Git'in Öne Çıkan Özellikleri

Temel Git Kavramları

Git'e başlamadan önce birkaç temel kavramı anlamak çok önemli. Bunları bilmeden komutları ezberlemek, GPS olmadan yabancı şehirde araba sürmek gibidir — belki bir yere varırsın, ama çok kaybolursun.

Repository (Depo)

Repository (kısaca repo), projenin tüm dosyalarını ve bu dosyalardaki her değişikliğin geçmişini saklayan bir depo/klasördür.

İki türü vardır:

• Local repository: Senin bilgisayarındaki repo. git init veya git clone ile oluşturulur

• Remote repository: Uzak sunucudaki repo (GitHub, GitLab vb.). Takım çalışması için kullanılır

Bir repo'nun içinde gizli bir .git klasörü bulunur. Git'in tüm sihri bu klasörde saklanır — geçmiş, branch bilgileri, konfigürasyon, her şey. Bu klasörü silersen, Git geçmişi tamamen kaybolur (dosyalar kalır ama geçmiş gider).

Commit (Kayıt)

Commit, projenin belirli bir andaki anlık görüntüsüdür (snapshot). Fotoğraf çekmeye benzer: "Şu an her şey bu durumda" diye kayıt alırsın.

Her commit şunları içerir:

• Değişiklik yapılan dosyalar ve içerikleri

• Kimin, ne zaman yaptığı

• Bir commit mesajı (ne değiştiğini açıklar)

• Benzersiz bir SHA-1 hash (örn: a1b2c3d4e5f6...)

• Önceki commit'e referans (parent commit)

⚠️ Önemli: İyi commit mesajları yazmak profesyonel yazılımcılığın temel taşlarından biridir. "fix", "asdfg", "düzeltme" gibi mesajlar yazmak yerine "Kullanıcı giriş formuna validasyon eklendi" gibi açıklayıcı mesajlar yaz. 3 ay sonra bu commit'e baktığında ne yaptığını anlamalısın.

Branch (Dal)

Branch, ana koddan bağımsız bir çalışma alanı oluşturmandır. Bir ağacın dalları gibi düşün: gövdeden (ana kod) ayrılırsın, kendi dalında çalışırsın, sonra istersen tekrar gövdeye birleştirirsin.

Branch'lerin faydaları:

• Ana kodu bozmadan yeni özellik geliştirebilirsin

• Birden fazla kişi aynı anda farklı özellikler üzerinde çalışabilir

• Deneme-yanılma yapabilirsin — beğenmezsen dalı silersin, ana kod etkilenmez

Varsayılan branch genelde main (eski projelerde master) olarak adlandırılır.

Merge (Birleştirme)

Merge, bir branch'teki değişiklikleri başka bir branch'e birleştirmektir. Yeni özelliğini geliştirdin, test ettin, her şey çalışıyor — şimdi main branch'e birleştirme zamanı.

Bazen iki branch aynı dosyanın aynı satırını değiştirmiş olabilir. Bu durumda merge conflict (birleştirme çakışması) oluşur. Git, "Ben karar veremiyorum, sen seç" der ve sana iki versiyonu gösterir. Sen hangisinin kalacağına karar verirsin.

Remote (Uzak Sunucu)

Remote, projenin uzak sunucudaki kopyasıdır. Genelde origin olarak adlandırılır ve GitHub, GitLab, Bitbucket gibi platformlarda barındırılır.

Remote'lar sayesinde:

• Kodunu yedeklersin (backup)

• Takım arkadaşlarınla paylaşırsın

• Açık kaynak projelere katkıda bulunursun

Staging Area (Hazırlık Alanı)

Git'in diğer VCS'lerden farklı bir konsepti daha var: Staging area (Index olarak da bilinir). Bu, commit'e dahil edilecek değişiklikleri seçtiğin bir ara bölgedir.

Bunu şöyle düşün: Bavul topluyorsun (commit). Odandaki tüm eşyalarını (değişiklikleri) bavula koymak zorunda değilsin. Sadece istediklerini seçip bavulun yanına (staging area) koyarsın. Sonra "tamam, bu kadar yeter" deyip bavulu kapatırsın (commit).

Çalışma Dizini → [git add] → Staging Area → [git commit] → Local Repo → [git push] → Remote Repo

Bu üç aşamalı yapı (working directory → staging → commit) Git'in en güçlü özelliklerinden biridir çünkü hangi değişikliklerin hangi commit'e gireceğini tam kontrol etmeni sağlar.

Git Kurulumu

Git'i kurmak oldukça basit. İşletim sistemine göre farklı yöntemler var:

Windows

Git'in resmi sitesinden [git-scm.com](https://git-scm.com) indirip kurabilirsin. Kurulum sihirbazında varsayılan ayarlar çoğu kişi için yeterli olacaktır. Kurulumla birlikte Git Bash adlı bir terminal de gelir — Windows'ta Linux benzeri komutlar kullanabilirsin.

macOS

macOS'ta Terminal'i açıp git yazman yeterli. Eğer kurulu değilse, otomatik olarak Xcode Command Line Tools kurulumunu başlatır. Alternatif olarak Homebrew ile de kurabilirsin:

brew install git

Linux (Ubuntu/Debian)

sudo apt update
sudo apt install git

Kurulum Doğrulama ve İlk Ayarlar

Kurulumdan sonra terminal/komut satırını aç ve sırasıyla şu komutları çalıştır:

# Git versiyonunu kontrol et
git --version
# Çıktı: git version 2.43.0 (veya daha güncel bir versiyon)

# Kullanıcı adı ve e-posta ayarla (commit'lerde görünecek)
git config --global user.name "Adın Soyadın"
git config --global user.email "email@example.com"

# Varsayılan branch adını "main" yap
git config --global init.defaultBranch main

# Ayarları kontrol et
git config --list

💡 İpucu: --global bayrağı bu ayarları tüm projeler için geçerli kılar. Belirli bir projede farklı ayar kullanmak istersen, proje klasöründe --global olmadan aynı komutları çalıştırabilirsin.

İlk Repository'ni Oluşturma

Teori yeter, pratiğe geçelim! Yeni bir proje oluşturup Git ile takip etmeye başlayalım:

# Proje klasörü oluştur ve içine gir
mkdir ilk-git-projem
cd ilk-git-projem

# Git repository'si başlat
git init
# Çıktı: Initialized empty Git repository in /home/kullanici/ilk-git-projem/.git/

# Bir dosya oluştur
echo "# İlk Git Projem" > README.md
echo "Bu proje Git öğrenirken oluşturuldu." >> README.md

# Durumu kontrol et
git status
# Çıktı:
# On branch main
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#         README.md

# Dosyayı staging area'ya ekle
git add README.md

# İlk commit'i oluştur
git commit -m "İlk commit: README dosyası eklendi"
# Çıktı:
# [main (root-commit) a1b2c3d] İlk commit: README dosyası eklendi
#  1 file changed, 2 insertions(+)
#  create mode 100644 README.md

Tebrikler! 🎉 İlk commit'ini yaptın. Artık bu projenin bir geçmişi var. İstediğin zaman bu ana geri dönebilirsin.

Temel Git Komutları

Günlük çalışmada en sık kullanacağın Git komutlarını tek tek inceleyelim:

git init — Repository Başlatma

Mevcut bir klasörü Git repository'sine dönüştürür. Klasörün içinde gizli bir .git dizini oluşturur. Genelde projeye bir kez, en başında çalıştırılır.

git add — Değişiklikleri Sahneye Alma

Değiştirdiğin dosyaları staging area'ya ekler. Commit'e hazır hale getirir.

# Tek dosya ekle
git add index.html

# Tüm değişiklikleri ekle (en sık kullanılan)
git add .

# Belirli uzantıdaki dosyaları ekle
git add *.js

⚠️ Dikkat: git add . komutu çalışma dizinindeki tüm değişiklikleri ekler. Bazen istemediğin dosyalar da (log dosyaları, API anahtarları) dahil olabilir. Bu yüzden .gitignore dosyası çok önemlidir (aşağıda anlatacağız).

git commit — Değişiklikleri Kaydetme

Staging area'daki değişiklikleri kalıcı olarak kaydeder.

# Kısa mesajla commit
git commit -m "Navbar komponenti oluşturuldu"

# add + commit tek satırda (sadece daha önce takip edilen dosyalar için)
git commit -am "Buton rengi güncellendi"

İyi commit mesajı yazma kuralları:

• İlk satır 50 karakteri geçmesin

• Ne yaptığını açıkla, neden yaptığını da ekleyebilirsin

• Kötü: "fix", "wip", "aaa" → İyi: "Login sayfasında şifre validasyonu düzeltildi"

git status — Durum Kontrolü

Hangi dosyaların değiştiğini, hangilerinin staging area'da olduğunu gösterir.

git status

# Kısa formatta görmek için
git status -s
# M  style.css        (modified, staged)
#  M app.js           (modified, not staged)
# ?? yeni-dosya.txt   (untracked)

git log — Geçmişi Görüntüleme

Commit geçmişini gösterir — kim, ne zaman, ne değişiklik yapmış.

# Tek satırlık özet (en sık kullanılan)
git log --oneline
# a1b2c3d Navbar komponenti oluşturuldu
# e4f5g6h İlk commit: README dosyası eklendi

# Grafik görünüm (branch yapısını gösterir)
git log --oneline --graph --all

git diff — Farkları Görme

Dosyalardaki değişiklikleri satır satır gösterir. Code review yaparken çok faydalıdır.

# Çalışma dizini ile staging area arasındaki fark
git diff

# Staging area ile son commit arasındaki fark
git diff --staged

git push — Uzak Sunucuya Gönderme

Local commit'leri remote repository'ye gönderir.

# İlk push (upstream ayarla)
git push -u origin main

# Sonraki push'lar
git push

git pull — Uzak Sunucudan Alma

Remote repository'deki değişiklikleri local'e çeker ve birleştirir.

# Değişiklikleri çek ve birleştir
git pull

# Belirli branch'ten çek
git pull origin main

💡 İpucu: git pull aslında arka planda iki komut çalıştırır: git fetch (değişiklikleri indir) + git merge (birleştir). Daha kontrollü bir yaklaşım istersen, önce git fetch yapıp değişikliklere bakabilir, sonra git merge ile birleştirebilirsin.

Branch (Dallanma) Stratejisi

Branch'ler Git'in en güçlü özelliklerinden biridir. Doğru kullanıldığında takım çalışmasını inanılmaz kolaylaştırır.

Branch Oluşturma ve Geçiş

# Oluştur + geç (tek komut, en pratik yol)
git checkout -b feature/kullanici-kayit

# Tüm branch'leri listele
git branch

# Branch sil (birleştirilmiş olanı)
git branch -d feature/kullanici-kayit

Branch Birleştirme (Merge)

# Önce hedef branch'e geç, sonra birleştir
git checkout main
git merge feature/kullanici-kayit

Merge Conflict Çözümü

İki branch aynı dosyanın aynı satırını değiştirdiğinde merge conflict oluşur. Git dosyayı şöyle işaretler:

<<<<<<< HEAD
<h1>Hoş Geldiniz</h1>
=======
<h1>Merhaba Dünya</h1>
>>>>>>> feature/baslik-degisikligi

Çözüm: İstediğin versiyonu bırak, işaretleri sil, sonra git add . ve git commit ile kaydet.

💡 İpucu: VS Code gibi modern editörler, conflict işaretlerini otomatik algılayıp "Accept Current", "Accept Incoming", "Accept Both" butonları gösterir.

Git vs SVN: Farklar Nelerdir?

Git'ten önce en yaygın kullanılan VCS, SVN (Apache Subversion) idi. İkisi arasındaki temel farkları bilmek, Git'in neden bu kadar popüler olduğunu anlamana yardımcı olur:

Git'in öğrenme eğrisi SVN'e göre biraz daha diktir ama bir kere öğrendiğinde geri dönmek istemezsin.

GitHub, GitLab ve Bitbucket Karşılaştırması

Git bir araçtır — bilgisayarında çalışır. GitHub, GitLab, Bitbucket ise Git repository'lerini barındıran platformlardır. Bu platformlar Git'in üzerine issue tracking, code review, CI/CD gibi özellikler ekler.

Hangisini Seçmeli?

• Açık kaynak proje veya portfolio? → GitHub (en büyük topluluk, en fazla görünürlük)

• Şirket içi DevOps pipeline? → GitLab (CI/CD dahili ve güçlü, self-hosted ücretsiz)

• Atlassian ekosistemi (Jira, Confluence) kullanıyorsan? → Bitbucket (entegrasyon mükemmel)

Başlangıç için GitHub öneriyoruz — dünyanın en büyük geliştirici topluluğuna sahip ve iş başvurularında GitHub profilin büyük artı.

.gitignore Dosyası

Her dosyanın Git tarafından takip edilmesini istemezsin. .gitignore dosyası Git'e hangi dosya ve klasörleri yoksayması gerektiğini söyler.

Örnek .gitignore Dosyası

Projenin kök dizininde .gitignore adlı bir dosya oluştur:

# Bağımlılıklar
node_modules/
vendor/
__pycache__/

# Derleme çıktıları
dist/
build/
*.class
*.o

# Ortam değişkenleri (API anahtarları burada!)
.env
.env.local
.env.production

# IDE ayarları
.idea/
.vscode/
*.swp
*.swo

# İşletim sistemi dosyaları
.DS_Store
Thumbs.db

# Log dosyaları
*.log
logs/

# Geçici dosyalar
*.tmp
*.temp

⚠️ Dikkat: .gitignore dosyasını projenin en başında oluştur. Eğer bir dosya zaten Git tarafından takip ediliyorsa, .gitignore'a eklemek onu geçmişten silmez. Takip edilen dosyayı kaldırmak için git rm --cached dosya_adi komutu gerekir.

💡 İpucu: [gitignore.io](https://www.toptal.com/developers/gitignore) sitesinden kullandığın teknolojilere göre otomatik .gitignore dosyası oluşturabilirsin. Örneğin "Node, React, macOS" yazarsan hepsine uygun bir dosya üretir.

Git Workflow: Feature Branch Modeli

Profesyonel ekiplerde herkes doğrudan main branch'e commit yapmaz. Bunun yerine feature branch modeli kullanılır. Bu model hem güvenli hem de düzenlidir.

Feature Branch Workflow Adımları

main ─────●────────●──────────●─────── (her zaman stabil)
           \      /            \
            ●────●              ●────● feature/sepet
            feature/login       

1. `main` branch her zaman stabil ve deploy edilebilir durumdadır

2. Yeni bir özellik için main'den branch oluştur

3. Branch'inde çalış, commit'le

4. İşin bitince Pull Request (PR) / Merge Request (MR) aç

5. Takım arkadaşların kodu review etsin

6. Onay aldıktan sonra main'e birleştir (merge)

7. Feature branch'i sil

Pratikte Nasıl Görünür?

# 1. main'in güncel olduğundan emin ol
git checkout main
git pull origin main

# 2. Yeni feature branch oluştur
git checkout -b feature/sepet-sistemi

# 3. Kodunu yaz, commit'le
git add .
git commit -m "Sepet modeli ve temel işlevler eklendi"

# 4. Remote'a push'la ve PR aç
git push -u origin feature/sepet-sistemi
# → GitHub/GitLab'da Pull Request aç

# 5. Review + onay sonrası merge
git checkout main
git merge feature/sepet-sistemi
git push origin main

# 6. Feature branch'i temizle
git branch -d feature/sepet-sistemi

Branch İsimlendirme Kuralları

İyi bir isimlendirme, projenin düzenini korur:

Sık Kullanılan İleri Seviye Komutlar

Temel komutları öğrendiğine göre, günlük hayatında sıkça karşına çıkacak birkaç ileri komuta da göz atalım:

git clone — Var Olan Projeyi Kopyalama

# HTTPS ile clone
git clone https://github.com/kullanici/proje.git

# Sadece son commit'i clone (büyük projelerde hız kazandırır)
git clone --depth 1 https://github.com/kullanici/proje.git

git stash — Değişiklikleri Geçici Olarak Sakla

Bir branch'te çalışıyorsun ama acil başka bir branch'e geçmen gerekiyor. Henüz commit'leyecek durumda değilsin. git stash değişikliklerini geçici olarak bir kenara koyar:

# Değişiklikleri sakla
git stash

# Saklanan değişiklikleri geri al
git stash pop

# Saklananları listele
git stash list

git reset — Geri Alma

# Staging'den çıkar (dosya değişmez)
git reset HEAD dosya.txt

# Son commit'i geri al (değişiklikler korunur)
git reset --soft HEAD~1

# Son commit'i tamamen geri al (değişiklikler silinir — DİKKAT!)
git reset --hard HEAD~1

⚠️ Dikkat: git reset --hard ile silinen değişiklikler geri getirilemez (commit'lenmemişse). Bu komutu kullanmadan önce iki kere düşün!

Bu konularda daha derinlemesine bilgi için [Git İleri Seviye: Rebase, Cherry-pick ve Stash Rehberi](/blog/git-ileri-seviye-rebase-cherry-pick-stash) yazımıza göz atabilirsin.

Git Kullanırken Yapılan Yaygın Hatalar

Hemen hemen her yazılımcı bu hataların en az birini yapmıştır. Önceden bilirsen, aynı tuzaklara düşmezsin:

1. Çok Büyük veya Çok Sık Commit

Mantıksal bütünlük taşıyan değişiklikleri grupla. Bir commit, bir iş birimi olmalı. 50 dosyalık dev commit'ler de, her satır için ayrı commit de kötü pratiktir.

2. Gizli Bilgileri Commit'lemek

API anahtarları, veritabanı şifreleri, .env dosyaları — bunları asla commit'leme! Bir kere commit'ledikten sonra geçmişten silmek çok zor. Çözüm: .gitignore'u projenin en başında yapılandır.

3. main Branch'e Direkt Push

Hatalı kod production'a gidebilir. Çözüm: Her zaman feature branch + Pull Request kullan.

4. Commit Mesajlarını Ciddiye Almamak

Çözüm: [Conventional Commits](https://www.conventionalcommits.org/) standardını takip et: feat: sepet sayfası eklendi, fix: login redirect hatası düzeltildi.

5. Pull Yapmadan Push Yapmaya Çalışmak

Remote'ta değişiklik varken push yapmaya çalışırsan Git reddeder. Çözüm: Push'tan önce her zaman git pull yap.

Sıkça Sorulan Sorular (SSS)

Git ve GitHub aynı şey mi?

Hayır! Bu en yaygın karışıklıklardan biri. Git bir versiyon kontrol aracıdır — bilgisayarında çalışır, açık kaynaklıdır, Linus Torvalds tarafından geliştirilmiştir. GitHub ise Microsoft'a ait, Git repository'lerini barındıran bir web platformudur. Git olmadan GitHub olmaz, ama GitHub olmadan Git gayet çalışır. GitHub'ın alternatifleri GitLab ve Bitbucket'tır.

Git öğrenmek ne kadar sürer?

Temel komutları (add, commit, push, pull) birkaç saat içinde öğrenebilirsin. Günlük iş akışını rahatça yürütecek seviyeye 1-2 hafta pratikle ulaşırsın. Branching stratejileri, rebase, conflict çözümü gibi ileri konularda ustalaşmak birkaç ay alabilir. Ama endişelenme — başlangıç için temel komutlar fazlasıyla yeterli.

Git'i sadece yazılımcılar mı kullanır?

Hayır! Git, herhangi bir metin tabanlı dosya ile çalışan herkes için faydalıdır. Teknik yazarlar, veri bilimciler (Jupyter notebook'lar), akademisyenler (LaTeX belgeler), hatta bazı tasarımcılar bile Git kullanır. Dosyalarındaki değişiklikleri takip etmek, geri almak, paylaşmak isteyen herkes Git'ten faydalanabilir.

Merge mi rebase mi kullanmalıyım?

Bu, yazılım dünyasının en tartışmalı konularından biri! Kısa cevap: Başlangıçta merge kullan. Merge daha güvenli, daha anlaşılır ve geçmişi olduğu gibi korur. Rebase daha temiz bir geçmiş oluşturur ama yanlış kullanıldığında ciddi sorunlara yol açabilir. İleri seviye Git bilgisine ulaştığında rebase'i de öğren — ama önce merge'ü tam anla.

Sildiğim commit'i geri getirebilir miyim?

Çoğu durumda evet! Git'in reflog adlı gizli silahı vardır. git reflog komutu yaptığın tüm işlemlerin geçmişini tutar. Sildiğin commit'in hash'ini bulabilir ve git cherry-pick ile geri getirebilirsin. Ancak bu kayıtlar varsayılan 90 gün saklanır.

Özet

Bu rehberde git nedir sorusundan başlayıp kapsamlı bir yolculuk yaptık. İşte öğrendiklerinin özeti:

• Git, Linus Torvalds tarafından geliştirilen dağıtık bir versiyon kontrol sistemidir

• Repository, commit, branch, merge, remote Git'in beş temel kavramıdır

• Staging area sayesinde hangi değişikliklerin commit'e gireceğini tam kontrol edersin

• git init, git add, git commit, git push, git pull günlük en çok kullanacağın komutlardır

• Feature branch workflow profesyonel ekiplerde standart çalışma yöntemidir

• .gitignore dosyası ile gereksiz ve hassas dosyaları Git'ten uzak tutarsın

• GitHub en popüler Git hosting platformudur ve kariyerinde büyük avantaj sağlar

Git, modern yazılım geliştirmenin olmazsa olmazıdır. Bugün öğrenmeye başla, yarın projelerde fark yarat.

Sonraki Adımlar

Git'in temellerini öğrendin — tebrikler! 🎉 Ama bu sadece başlangıç. Git'in rebase, cherry-pick, stash gibi ileri seviye özellikleri seni çok daha verimli bir geliştiriciye dönüştürecek.

📚 tolgahan.dev'de [60 derslik ücretsiz Git & GitHub kursu](/courses/git-github-sifirdan-pratige) seni sıfırdan ileri seviyeye taşıyor. Kursta her konuyu interaktif alıştırmalarla, gerçek dünya senaryolarıyla pratiğe dökeceksin. Sadece okumak yerine, yaparak öğren!

İleri seviye konular için [Git İleri Seviye: Rebase, Cherry-pick ve Stash Rehberi](/blog/git-ileri-seviye-rebase-cherry-pick-stash) yazımız da hazır. Branch yönetimini, geçmiş temizliğini ve profesyonel Git kullanımını öğrenmek istersen bir sonraki durağın orası.

Haydi, terminalini aç ve ilk git init'i yaz! 🚀