Sıfırdan İleri Seviyeye: Git Versiyon Kontrol Sistemi ☕️

Git Nedir? 🤔

Git; yazılım geliştirme sürecinde dosyalarda yapılan değişiklikleri zamana bağlı olarak kaydeden, dağıtık (distributed) bir versiyon kontrol sistemidir.

Git’in Kısa Tarihi 📖

Git, Linux’un yaratıcısı Linus Torvalds tarafından 2005 yılında geliştirildi.

Linux projesi, 2002'den beri BitKeeper adlı ücretli bir versiyon kontrol sistemini ücretsiz olarak kullanıyordu. 2005'te BitKeeper, Linux geliştiricilerinden Andrew Tridgell’ın kaynak koduna ters-mühendislik uyguladığını iddia ederek ücretsiz lisansı iptal etti. Bunun üzerine Linus Torvalds, kendi versiyon kontrol sistemini yazmaya karar verdi ve Git ortaya çıktı.

Neden Versiyon Kontrolü? 🧐

Tek başımıza çalışırken dosyaları elle yedeklemek mümkün. Ancak birden fazla kişinin aynı proje üzerinde çalıştığı durumlarda; kimin, ne zaman, neyi değiştirdiğini takip etmek zorlaşır. Versiyon kontrol sistemi bu süreci otomatize eder ve şu sorunları çözer:

• Dosyaların farklı sürümlerini güvenle saklar
• Birden fazla kişinin aynı anda çalışmasına olanak tanır
• Hata durumunda önceki bir sürüme kolayca geri dönülmesini sağlar
• Kimin hangi değişikliği yaptığını kaydeder

Git Nasıl Çalışır? ⚙️

Git üç temel katmandan oluşur:

• Working Directory (Çalışma Dizini): Dosyalarımızın bulunduğu, üzerinde aktif olarak çalıştığımız yerel dizindir.
• Staging Area (Hazırlık Alanı): Değişiklikleri tamamlayıp Git deposuna göndermeye hazır hale getirdiğimiz ara katmandır. “Commit öncesi bekleme odası” olarak düşünebiliriz.
• Repository (Depo — Kısaca “Repo” da denir): Değişikliklerin kalıcı olarak kaydedildiği Git deposudur. Proje dizinimizdeki .git klasörüdür.

Temel iş akışı şudur:

1. Çalışma dizininde değişiklik yaparız
2. git add ile bu değişiklikleri staging area'ya ekleriz
3. git commit ile staging area'daki değişiklikleri Git deposuna kaydederiz

Kurulum 💻

git-scm.com adresinden işletim sistemimize uygun sürümü indirip kurulum adımlarını tamamlayabiliriz.

Kurulumu doğrulamak için terminalde:

Konfigürasyon (git config) 🔧

Git’i kullanmaya başlamadan önce kullanıcı bilgilerimizi tanımlamamız gerekir. Her commit’te bu bilgiler kayıt altına alınır.

★ Global Konfigürasyon

Bilgisayardaki tüm Git repository’leri için geçerli olan varsayılan konfigürasyon aşağıdaki gibi tanımlanır:

★ Local konfigürasyon

Yalnızca bulunduğumuz repository için geçerli olan konfigürasyon tanımıdır. Aynı isimde bir global ayar varsa, local ayar onu ezer:

💡 Bu örneğe göre, bilgisayardaki ana Git, tüm respository’lerde “Yasin” kullanır ancak bir tane proje özelinde local komutu globaldeki tanımı ezmiş olur ve ilgili projede “Beril” kullanılmaya devam eder.

★ Faydalı Ek Ayarlar

★ Git Alias (Kısayollar)

Sık kullandığımız komutlar için kısayollar tanımlayabiliriz:

Artık git status yerine git st, git checkout yerine git co yazabiliriz.

★ Konfigürasyonları Kontrol Etme

Tüm konfigürasyonları kontrol etmek için:

Repository Oluşturma (git init) 📂

Çalışma dizinimizi bir Git repository’sine dönüştürmek için terminal üzerinden ilgili dizine geldikten sonra:

Bu komut dizinimizde .git adında gizli bir klasör oluşturur. Git'in tüm verileri (commit geçmişi, branch bilgileri, yapılandırma vb.) bu klasörde saklanır. Varsayılan branch adı, Git sürümümüze ve yapılandırmamıza göre master veya main olabilir. Günümüzde GitHub gibi platformlar varsayılan olarak main kullanır. Terminalimizde parantez içinde branch adını (örneğin (main)) göreceğiz.

💡 Branch kavramını makalenin ilerleyen bölümlerinde detaylı ele aldım

Dosya Durumunu İzleme (git status) 🔍

Repository’deki değişikliklerin durumunu görmek için:

Bu komut; hangi dosyaların değiştiğini, hangilerinin staging area’da olduğunu ve hangilerinin henüz Git tarafından izlenmediğini (untracked) gösterir.

git init komutundan hemen sonra çalıştırırsak, henüz hiçbir commit bulunmadığını ve git add komutunu kullanmamız gerektiğini söyler. git status'u Git'in bize sürekli yol gösteren pusulası olarak düşünebiliriz; ne zaman emin olamazsak bu komutu çalıştıralım.

Staging Area’ya Değişiklikleri Eklemek (git add) ➕

Bir dosya oluşturarak başlayalım. Çalışma dizinimizde isimler.txt adında bir dosya oluşturalım:

git status komutunu çalıştırdığımızda Git bu dosyayı untracked (izlenmeyen) olarak gösterecektir. Bu dosyayı staging area'ya eklemek, yani Git'in bu dosyayı izlemeye başlamasını sağlamak için:

Tek bir dosya eklemek:

Tüm değişiklikleri tek seferde eklemek:

⚠️ git add . pratik olsa da istemeden alakasız dosyaları da staging area'ya ekleyebilir. Özellikle büyük projelerde önce git status ile kontrol etmek iyi bir alışkanlıktır.

Staging Area Değişikliklerini İzleme 👀

git add komutundan sonra git status komutunu tekrar çalıştıralım:

Artık dosyamızın “Changes to be committed” (commit edilmeye hazır) bölümünde listelendiğini göreceğiz. Git, staging area’daki değişikliklerin tipini otomatik olarak algılar.

★ Değişiklik Tipleri

Yeni Dosya (new file): Daha önce Git tarafından izlenmeyen, yeni eklenen bir dosyadır.

Değiştirilmiş Dosya (modified): İçeriği değiştirilen, daha önce Git tarafından izlenen bir dosyadır.

Değişikliği geri almak istersek:

Silinmiş Dosya (deleted): Git tarafından izlenen bir dosyanın silinmesidir.

Silme işlemini geri almak istersek:

★ Staging Area’dan Çıkarma

Yanlışlıkla staging area’ya eklenen bir dosyayı çıkarmak (unstage) için:

💡 Eski kaynaklarda staging’den çıkarma için git reset HEAD <dosya> görebilirsiniz. Modern Git'te bunun yerine git restore --staged önerilir.

Git’in bir dosyayı tamamen izlemeyi bırakmasını istiyorsak (dosya diskten silinmez ama Git artık takip etmez):

Bu komut özellikle .gitignore'a sonradan eklenen dosyaları Git takibinden çıkarmak için kullanılır.

★ “git add” Komutu Hakkında Daha Fazlası

Kısmi ekleme (-p): Dosyadaki değişiklikleri parça parça (hunk) göstererek hangilerini eklemek istediğimizi sorar:

Bu komut her değişiklik bloğu için bize seçenekler sunar:

• y — Bu bloğu ekle
• n — Bu bloğu ekleme
• s — Bloğu daha küçük parçalara böl
• q — Çık

Bu sayede bir dosyadaki değişikliklerin yalnızca bir kısmını staging area’ya ekleyebiliriz.

📌 git add komutunun tüm parametreleri için: git-scm.com/docs/git-add

Git’e Kaydetme (git commit) 📸

Staging area’daki değişiklikleri Git’e kalıcı olarak kaydetmek için:

Bu komutu parametresiz çalıştırdığımızda varsayılan metin editörü (genellikle Vim) açılır ve commit mesajı yazmamızı bekler. Vim’den çıkmak için :wq yazıp Enter'a basabiliriz.

★ “git commit” Komutu Parametreleri

-m parametresi — Commit mesajını doğrudan terminalde yazmaya yarar:

-a parametresi — git add kullanmadan, yalnızca değişen (modified) dosyaları doğrudan commit eder. ⚠️ Yeni (untracked) dosyaları eklemez:

--amend parametresi — Son commit mesajını düzeltir veya son commit'e yeni değişiklikler ekler:

⚠️ --amend commit hash'ini değiştirir. Push edilmiş commit'lere amend yaparsak --force push gerekir. Ekip çalışmasında dikkatli olmamızda yarar var.

📌 git commit komutunun tüm parametreleri için: git-scm.com/docs/git-commit

★ İyi Commit Mesajı Nasıl Yazılır?

💡 Bu kısım makalenin en önemli kısımlarından birisi. Çünkü Git kullanırken yapılan en yaygın hatalardan biri kötü commit mesajlarıdır. Oysa iyi yazılmış bir commit mesajı, projenin geçmişini okunabilir hale getirir ve ekip içi iletişimi ciddi şekilde kolaylaştırır.

İyi commit mesajı nasıl olmalı?

• Kısa ve açıklayıcı (50 karakter altı ideal)
• Ne yaptığını anlatsın
• Açık fiiller kullanalım: “düzeltildi”, “eklendi”, “güncellendi”

Örnek:

• ❌ Kötü: degisiklik
• ✅ İyi: Kullanıcı giriş formunda validasyon hatası düzeltildi

💡 Genelde büyük projelerde ve ekiplerde veya open source projelerde commit mesajlarını standart hale getirmek için bazı linter araçları kullanılır.

★ Commit Mesajı Standartları (Conventional Commits)

Büyük projelerde commit mesajlarının belirli bir standartta yazılması gerekir. Bu standartlar:

• Commit geçmişini okunabilir yapar
• Otomatik changelog üretimini sağlar
• CI/CD süreçleri ile entegre çalışabilir
• Semantic versioning ile uyumludur

Bu amaçla yaygın olarak Conventional Commits standardı kullanılır.

★ Commit Formatı

• feat — Yeni özellik eklendi
• fix — Bir hata düzeltildi
• docs — Dokümantasyon değişiklikleri
• style — Kod formatı değişiklikleri (lint, boşluk vb.)
• refactor — Kod davranışını değiştirmeyen refactor
• test — Test eklendi veya güncellendi
• chore — Build, config veya yardımcı işler
• ci — CI/CD pipeline değişiklikleri
• perf — Performans iyileştirmeleri
• build — Build sistemi veya dependency değişiklikleri

Bu standardı otomatik kontrol etmek için:

• commitlint → commit mesajlarını lint eder
• Commitizen → commit yazarken interaktif yardım sağlar

💡 Her commit bir branch’e, tag’e veya HEAD’e bağlı olmak zorundadır. Bağlı olmayan commit’ler Git’in çöp toplama mekanizması (garbage collection) tarafından belirli bir zaman sonra (varsayılan 90 gün) otomatik olarak silinir. Garbage collection hakkında detaylara makalenin ilerleyen kısımlarında değindim.

Commit Geçmişi Görüntüleme (git log) 📜

Commit geçmişini görmek için:

Örnek çıktı:

★ Sık Kullanılan Parametreler

git log çıktısında gördüğümüz commit hash'leri (örn. a1b2c3d), git checkout, git reset, git revert gibi komutlarda belirli bir commit'e referans vermek için kullanılır.

📌 git log komutunun tüm parametreleri için: git-scm.com/docs/git-log

Farkları Görüntüleme (git diff) 🔎

Dosyalardaki değişiklikleri satır satır görmek için:

Bu komut, çalışma dizinindeki değişiklikler ile staging area arasındaki farkları gösterir.

★ Farklı Karşılaştırma Senaryoları

Çıktıyı okumak:

📌 git diff komutunun tüm parametreleri için: git-scm.com/docs/git-diff

Dosya Silme ve Taşıma (git rm & git mv) 🗑️

★ git rm

Git tarafından izlenen bir dosyayı hem diskten hem de Git takibinden silmek için:

Dosyayı diskten silmeden yalnızca Git takibinden çıkarmak için:

★ git mv

Dosyayı taşımak veya yeniden adlandırmak için:

💡 Git, dosya yeniden adlandırmalarını aslında içerik benzerliğinden algılar. git mv, arka planda dosyayı silip yeni isimle eklemekle aynı şeyi yapar; ancak tek komutla halletmek daha pratiktir.

Dallanma (git branch) 🌿

Branch’ler, aynı proje üzerinde bağımsız çalışma alanları oluşturmamızı sağlar. Her branch, türetildiği branch’in o anki halinin bir kopyasıdır. Asıl kodumuzu bozmadan yeni özellikler geliştirebilir veya hataları düzeltebiliriz.

Git’in kendisi varsayılan olarak master branch adını kullanır. Ancak GitHub gibi platformlar 2020'den itibaren varsayılan branch adını main olarak belirlemiştir. Bu makalede örneklerde main kullanacağız.

★ Branch Listeleme

💡 git branch -a çıktısında remotes/origin/main gibi görünen referanslar, uzak branch'in doğrudan kendisi değil; son fetch veya pull sonrası güncellenen yerel takip referanslarıdır.

★ Branch Oluşturma

Bu komutu çalıştırdıktan sonra git branch komutunu tekrar çalıştırırsak, yeni-isimler branch'inin oluştuğunu görürüz. Ancak hala main branch'indeyiz; branch'e geçiş yapmak için sonraki bölümü okuyalım.

★ Branch Silme

★ Branch’i Yeniden Adlandırma

Branch ve Commit’ler Arasında Geçiş (git checkout / git switch) 🔄

Git 2.23 sürümünde git checkout komutunun iki farklı sorumluluğu (branch değiştirme + dosya geri alma) ayrıştırıldı. git switch branch geçişi, git restore dosya geri alma için önerilir. Ancak git checkout hala her iki iş için de çalışır.

★ Branch’ler Arasında Geçiş Yapmak

veya Git 2.23+ sürümlerinde:

Kısayol, Oluştur ve Geç:

git branch komutunu ayrıca çalıştırmadan, yeni bir branch oluşturup o branch'e geçiş yapmak için:

★ Commit’e Geçiş Yapmak

git log çıktısında gördüğümüz herhangi bir commit hash'ini kullanarak, o commit'in durumuna geri dönebiliriz:

⚠️ Bu komut bizi Detached HEAD durumuna geçirir. Bu durumda yaptığımız commit’ler hiçbir branch’e bağlı olmaz ve branch değiştirdiğimizde bu commit’lere erişmek zorlaşabilir. Değişikliklerimizi korumak istiyorsak yeni bir branch oluşturalım:

💡 HEAD ve Detached HEAD kavramları makalenin ilerleyen bölümlerinde detaylı olarak açıklanıyor.

★ Belirli Bir Commit’ten veya Branch’ten Dosya Almak

Belirli bir commit’teki veya branch’teki dosyanın halini çalışma dizinine getirmek için:

Bu komut, dosyayı çalışma dizinimize ve staging area’ya kopyalar. Mevcut branch’imizden ayrılmayız.

💡 Eski kaynaklarda dosya geri alma için git checkout -- <dosya> görebilirsiniz. Modern kullanımda bunun yerine git restore önerilir.

Branch’leri Birleştirmek (git merge) 🤝

Bir branch’teki değişiklikleri başka bir branch ile birleştirmek için git merge komutu kullanılır.

Örnek senaryo:

★ Merge Türleri

Fast-Forward Merge: Hedef branch’te (main) hiçbir yeni commit yoksa Git, branch pointer’ını ilerletir. Yeni bir merge commit oluşmaz:

Fast-forward merge’ü engelleyip her zaman merge commit oluşturmak için:

Three-Way Merge: Her iki branch’te de yeni commit varsa Git, ortak bir atayı bularak üç yönlü karşılaştırma yapar ve yeni bir merge commit oluşturur.

💡 Feature branch’imizi güncel tutmak için ana branch’ten değişiklikleri düzenli olarak alabiliriz. Bu işlem merge veya rebase ile yapılabilir:

git checkout yeni-isimler

git merge main

veya

git rebase main

Çakışmalar (Git Conflicts) ⚡

İki branch’te aynı dosyanın aynı satırları farklı şekilde değiştirildiğinde çakışma (conflict) oluşur.

Örnek senaryo:

main branch'inde isimler.txt dosyamız şöyle olsun:

1. Yeni branch oluşturup 3. satırdaki Tuvana'yı Beril olarak değiştirelim:

2. main’e dönüp aynı satırı farklı bir isimle değiştirelim:

3. Birleştirmeyi deneyelim:

Git şu çakışma mesajını verir:

Dosyayı açtığımızda Git, çakışan bölümleri işaretler:

• <<<<<<< HEAD ile ======= arasındaki kısım: Bizim branch'imizdeki değişiklik
• ======= ile >>>>>>> main arasındaki kısım: Birleştirmeye çalıştığımız branch'teki değişiklik

Çakışmayı çözmek için:

1. Dosyayı düzenleyip istediğimiz içeriği bırakalım
2. <<<<<<<, =======, >>>>>>> işaretlerini silelim
3. Kaydedelim ve commit edelim:

★ Hızlı Çözüm: Ours veya Theirs

Çakışmada doğrudan bir tarafı seçmek istersek:

★ Birleştirmeyi İptal Etmek ( — abort)

Çakışma çıktığında henüz çözüm yapmadan birleştirme işlemini tamamen iptal etmek istersek:

Bu komut, merge işlemini iptal eder ve dosyalarımızı merge öncesindeki durumuna geri döndürür.

★ Birleştirmeye Devam Etmek ( — continue)

Çakışmaları dosya üzerinde çözdükten ve git add ile staging area'ya ekledikten sonra:

Bu komut, git commit ile aynı işlevi görür ancak devam eden bir merge işlemi olduğunu açıkça ifade eder.

💡 VS Code gibi editörler, conflict işaretlerini otomatik algılar ve “Accept Current”, “Accept Incoming”, “Accept Both” gibi butonlarla çözümü kolaylaştırır. Alternatif olarak git mergetool komutuyla yapılandırdığımız harici araçları da kullanabiliriz.
Ek olarak bir çok IDE’nin (WebsStorm, PhpStorm, PyCharm vb.) kendi merge editörü mevcut, arayüzden daha hızlı şekilde ilerlememizi sağlıyor.

Commitleri Başka Bir Branch Üzerine Yeniden Uygulama (git rebase) 🔀

Rebase, bir branch’in commit’lerini başka bir branch’in ucuna yeniden uygulayarak doğrusal (linear) bir geçmiş oluşturur.

Bu komut şunu yapar:

1. yeni-ozellik branch'indeki commit'leri geçici olarak kaldırır
2. main branch'indeki son commit'leri alır
3. yeni-ozellik'in commit'lerini main'in en son commit'inin üzerine tek tek yeniden uygular

★ Interactive Rebase

Son commit’leri düzenlemek, birleştirmek, sırasını değiştirmek veya silmek için:

Açılan editörde her commit’in başındaki komutu değiştirebiliriz:

Kullanılabilir komutlar:

• pick — Commit’i olduğu gibi bırak
• reword — Commit mesajını değiştir
• squash — Bir önceki commit ile birleştir (mesajları birleştirir)
• fixup — Bir önceki commit ile birleştir (bu commit’in mesajını siler)
• drop — Commit’i tamamen sil
• edit — Commit’i düzenlemek için dur

★ Rebase — onto

Bir branch’i, türetildiği branch’ten ayırıp başka bir branch’in üzerine taşımak için:

★ Rebase vs Merge

• Merge

1. Branch’leri birleştirir ve merge commit oluşturur
2. Commit geçmişini değiştirmez (güvenlidir)
3. Conflict varsa tek seferde çözülür

• Rebase

1. Commit’leri başka bir branch’in üzerine yeniden uygular
2. Daha temiz bir geçmiş oluşturur
3. Commit hash’lerini yeniden yazar
4. Conflict oluşursa her commit için ayrı ayrı çözülür
5. Genellikle kişisel branch’lerde kullanılır

⚠️ Başkalarının da kullandığı paylaşılan commit geçmişi bulunan branch’lerde sorunlara yol açabilir. Kendi branch’imizde (kimse kullanmıyorsa) dikkatli şekilde kullanabiliriz.

Rebase sırasında conflict çıkarsa:

HEAD Kavramı 🎯

HEAD, Git’te “şu anda neredeyiz?” sorusunun cevabıdır. Üzerinde çalıştığımız commit’i gösteren bir işaretçidir (pointer).

Normalde HEAD bir branch’i işaret eder ve o branch’in son commit’ine karşılık gelir:

Bu, “HEAD → main → son commit” anlamına gelir. Yeni bir commit yaptığımızda HEAD otomatik olarak bu yeni commit’e ilerler.

★ Detached HEAD

git checkout <commit-hash> ile doğrudan bir commit'e geçtiğimizde, HEAD artık bir branch'i değil doğrudan o commit'i işaret eder:

Bu durumda yapılan commit’ler hiçbir branch’e bağlı olmadığından, başka bir branch’e geçtiğimizde bu commit’lere erişmek zorlaşabilir. Değişikliklerimizi korumak istiyorsak:

💡 Detached HEAD’de yapılan commit’ler hemen yok olmaz. git reflog ile hash'lerini bulup kurtarabiliriz; ancak reflog süresi (varsayılan olarak 90 gün olarak gelir) dolduktan sonra garbage collection tarafından temizlenirler.

Etiketleme (git tag) 🏷️

Tag’ler, belirli commit’lere kalıcı etiketler (yer işaretleri) eklemek için kullanılır. Genellikle sürüm numaralarını işaretlemek için tercih edilir. Branch’lerden farkı, tag’lerin sabit olması ve hareket etmemesidir.

★ Lightweight Tag

Basit bir işaretçidir, ek bilgi saklamaz:

★ Annotated Tag (Açıklamalı)

Yazar, tarih ve mesaj bilgisi içeren tag’dir. Sürüm etiketleri için önerilir:

★ Belirli Bir Commit’e Tag Ekleme

★ Tag İşlemleri

Değişiklikleri Geri Alma ↩️

Çalışma dizinindeki veya staging area’daki değişiklikleri geri alır:

★ git reset

Commit geçmişini geri almak için kullanılır. git reset, esas olarak branch'in işaret ettiği commit'i geriye taşır; kullanılan moda göre staging area ve çalışma dizini de buna uyarlanır.

Üç modu vardır:

--soft: Commit geri alınır ama değişiklikler staging area'da kalır. Commit mesajını veya commit grubunu düzeltmek istediğimizde kullanışlıdır:

--mixed (varsayılan): Commit geri alınır, değişiklikler çalışma dizininde kalır ama staging area'dan çıkar:

--hard: Commit ve tüm değişiklikler tamamen silinir:

⚠️ --hard parametresi değişiklikleri kalıcı olarak siler. Dikkatli olmamızda yarar var.

Hard reset yaptığımız commit (makalenin diğer bölümlerinde bahsettiğim) “garbage collection” içinde duruyorsa, git reflog ile halen kurtarmamız mümkün. Ancak herhangi bir brach, tag veya HEAD’e bağlı olmayabilir. Garbage collection süresi default 90 gün. Yani bu durumda 90 gün içinde yaptığımız hard reset commit’lerini, biraz bulması zor olsa da kurtarabiliriz. Burada da en önemli konu, commit mesajlarını nasıl yazdığımız. Commit mesajlarını aynı ya da birbirine benzer şekilde yazdıysak vay halinize, kaybolan commit’ler için bir bardak soğuk su içebiliriz 😁

HEAD~1: Bir önceki commit. HEAD~3: Üç önceki commit. Belirli bir commit hash'i de kullanabiliriz:

★ git revert

Belirli bir commit’in değişikliklerini geri alan yeni bir commit oluşturur. Geçmişi silmez, bu yüzden paylaşılan branch’lerde güvenle kullanılabilir:

Merge commit revert etmek:

Merge commit’leri revert ederken hangi parent’ı temel alacağımızı -m parametresiyle belirtmemiz gerekir:

★ Hangisini kullanmalıyız?

• Henüz commit etmediğimiz dosya değişiklikleri → git restore
• Henüz push etmediğimiz commit’ler → git reset
• Push edilmiş commit’leri güvenle geri almak → git revert

Referans Geçmişi (git reflog) 🕵️

git reflog, HEAD'in tüm hareketlerini kronolojik olarak kaydeden bir güvenlik ağıdır. git reset --hard gibi tehlikeli bir komut çalıştırdıktan sonra bile kaybolan commit'leri buradan bulabiliriz:

Örnek çıktı:

Kaybolan commit’in hash’ini bulup geri dönebiliriz:

💡 reflog kayıtları varsayılan olarak 90 gün boyunca saklanır.

Değişiklikleri Rafa Kaldırma (git stash) 📦

Üzerinde çalıştığımız değişiklikleri commit etmeden geçici olarak saklamak için kullanılır. Acil bir iş çıktığında branch değiştirmemiz gerektiğinde çok işe yarar.

★ Temel Komutlar

💡 Eski kaynaklarda git stash save "Açıklama" görebilirsiniz. Modern Git'te bunun yerine git stash push -m "Açıklama" önerilir.

⚠️ Varsayılan git stash komutu untracked dosyaları dahil etmez. Bunları da saklamak için -u parametresini kullanabiliriz.

★ Geri Getirme

★ Temizleme

★ Örnek Senaryo

isimler.txt üzerinde yeni isimler ekliyoruz. Tam o sırada acil bir düzeltme yapmamız gerekiyor:

Dosya Yoksayma (.gitignore) 🙈

Git’in belirli dosya ve klasörleri izlememesi için proje kök dizininde .gitignore dosyası oluşturulur:

★ Önemli Notlar

• .gitignore dosyası oluşturulmadan önce Git tarafından izlenmeye başlanan dosyalar, .gitignore'a eklendiğinde otomatik olarak izlenmekten çıkmaz. Bu dosyaları izlemeden çıkarmak için:

• Boş klasörler Git tarafından izlenmez. Boş bir klasörü repository’ye eklemek istiyorsak içine .gitkeep adında boş bir dosya koyabiliriz. .gitkeep Git'e özgü bir özellik değil; topluluk tarafından benimsenen bir konvansiyondur. Dosya adı herhangi bir şey olabilir ama .gitkeep yaygın olarak tercih edilir.

★ Global .gitignore

Tüm projelerimizde geçerli olacak global bir .gitignore dosyası tanımlayabiliriz. Bu, .DS_Store, Thumbs.db, editör geçici dosyaları gibi sisteme özel dosyalar için kullanışlıdır:

Ardından ~/.gitignore_global dosyasına global kurallarımızı ekleyelim.

📌 Farklı proje türleri için hazır .gitignore şablonları: github.com/github/gitignore

Uzak Repository (Remote) 🌐

Şu ana kadar tüm işlemler yerel makinemizde gerçekleşti. Projemizi GitHub, GitLab veya Bitbucket gibi platformlarda barındırmak ve başkalarıyla paylaşmak için uzak (remote) repository kullanılır.

★ HTTPS vs SSH

Uzak repository’ye bağlanırken iki yöntem kullanılır:

💡 SSH kullanmak için önce SSH key oluşturmamız ve platformumuza (GitHub, GitLab vb.) eklememiz gerekir. Detaylı adımlar için: docs.github.com/en/authentication/connecting-to-github-with-ssh

★ Uzak Repo Ekleme

Burada origin, uzak repository'nin yerel takma adıdır. Geleneksel olarak origin kullanılır ancak istediğimiz herhangi bir isim verebiliriz.

★ Remote-Tracking Branch Kavramı

origin/main gibi referanslar, uzak repodaki main branch'inin yerelde tutulan takip kopyasıdır. Bu, doğrudan uzak sunucunun canlı hali değil; son fetch veya pull sonrası güncellenen yerel referanstır. Bu sayede çevrimdışıyken bile uzak branch'in en son bilinen durumunu görebiliriz.

★ Uzak Repoları Listeleme

Örnek çıktı:

★ Uzak Repo URL Değiştirme

★ Uzak Repo Kaldırma

Klonlama (git clone) 📥

Uzak bir repository’yi yerel makinemize kopyalamak için:

Bu komut:

1. Proje adında bir klasör oluşturur
2. .git klasörünü oluşturur
3. Tüm geçmişi ve dosyaları indirir
4. origin remote'unu otomatik olarak ayarlar

★ Ek Parametreler

Değişiklikleri Çekme (git fetch & git pull) ⬇️

★ git fetch

Uzak repository’deki değişiklikleri indirir ama yerel dosyalarımıza birleştirmez. Değişiklikleri önce incelemek istediğimizde kullanışlıdır:

Fetch sonrası uzak branch’teki değişiklikleri incelemek için:

Beğenirsek birleştiririz:

★ git pull

fetch + merge işlemini tek komutla yapar. Uzak repository'deki değişiklikleri hem indirir hem yerel branch'imizle birleştirir:

Daha temiz bir geçmiş için rebase ile pull:

💡 git pull --rebase'i varsayılan davranış yapmak için:

git config --global pull.rebase true

★ Pull vs Fetch

• git fetch: İndirir ama birleştirmez, daha güvenlidir çünkü önce inceleme şansı verir, inceleyip sonra birleştirmek istediğimizde kullanırız
• git pull: İndirir ve otomatik birleştirir, conflict çıkabilir, hızlıca güncellemek istediğimizde kullanırız

💡 git pull = git fetch + git merge

Değişiklikleri Gönderme (git push) ⬆️

Yerel commit’lerimizi uzak repository’ye göndermek için:

★ İlk Push için Upstream Ayarlama

Yeni bir branch’i ilk kez gönderirken -u (upstream) parametresi kullanılır. Bu, yerel branch ile uzak branch arasında kalıcı bir bağlantı (tracking relationship) kurar. Bu sayede sonraki push'larda yalnızca git push yazmamız yeterli olur:

Mevcut bir branch’in upstream’ini değiştirmek veya ayarlamak için:

★ Diğer Parametreler

⚠️ --force parametresi uzak repository'deki geçmişi yeniden yazar. Ekip arkadaşlarımızın çalışmalarını kaybettirebilir. --force-with-lease tercih edersek; uzak branch'te bizim bilmediğimiz bir commit varsa push'u reddeder.

Fork ve Pull Request 🍴

★ Fork

Başka birinin repository’sini kendi GitHub/GitLab hesabımıza kopyalamaktır. Platformun arayüzündeki Fork butonu ile yapılır. Fork, orijinal repo ile bağlantısını korur.

★ Pull Request (PR) / Merge Request (MR)

Fork’ladığımız veya oluşturduğumuz branch’teki değişikliklerin ana repository’ye kabul edilmesi için açılan istektir. GitHub’da Pull Request, GitLab’da Merge Request olarak adlandırılır.

Tipik iş akışı:

1. Repository’yi fork’layalım
2. Yerel makinemize klonlayalım
3. Yeni bir branch oluşturalım
4. Değişikliklerimizi yapalım, commit edelim
5. Fork’umuza push edelim
6. Platform üzerinden Pull Request açalım
7. Kod incelemesi (code review) yapılır
8. Onaylanırsa ana branch’e birleştirilir

Branching Stratejileri 🗺️

Ekiplerin Git’i nasıl kullandığına dair yaygın stratejiler:

★ Git Flow

En yaygın ve kapsamlı strateji. Uzun süreli projelerde tercih edilir:

• main — Yayınlanan kararlı sürüm
• develop — Geliştirme branch’i
• feature/* — Yeni özellikler için
• release/* — Sürüm hazırlığı için
• hotfix/* — Acil düzeltmeler için

★ GitHub Flow

Basit ve sürekli dağıtım (CD / continuous deployment) yapan ekipler için:

• main — Her zaman dağıtılabilir durumda
• feature branch — Yeni özellik veya düzeltme
• Pull Request — Kod incelemesi ve birleştirme

★ Trunk-Based Development

Kısa ömürlü branch’ler kullanılır ve sürekli olarak ana branch’e (trunk) merge edilir. Büyük ekiplerde sürekli entegrasyon (CI) ile birlikte kullanılır.

💡 Hangi stratejiyi kullanacağımız ekip büyüklüğüne, proje türüne ve dağıtım sıklığına bağlıdır. Küçük ekipler için GitHub Flow genellikle yeterlidir.

Seçerek Alma (git cherry-pick) 🍒

Başka bir branch’ten tüm branch’i birleştirmek yerine, yalnızca belirli bir commit’i kendi branch’imize almak için:

Örnek senaryo:

yeni-ozellik branch'inde 5 commit var ama yalnızca birinde yapılan hata düzeltmesini main'e almak istiyoruz:

Birden fazla commit almak için:

Cherry-pick sırasında conflict çıkarsa, normal merge conflict’te olduğu gibi çözüp devam edelim:

Satır Bazında Geçmiş (git blame) 🔬

Bir dosyanın her satırını en son kimin, ne zaman değiştirdiğini görmek için:

Örnek çıktı:

💡 Yukarıdaki örnekte ilk ve son satır aynı kişi tarafından değiştirilmiş farklı satırlar. Arada kalan 2 ve 3. satır ise farklı kişiler taradından değiştirilmiş satırlar

★ Ek Parametreler

Bir hatanın veya değişikliğin kaynağını bulmak için kullanışlıdır.

Arama (git grep) 🔎

Repository’deki dosyaların içeriğinde metin aramak için:

Örnek çıktı:

★ Ek Parametreler

💡 git grep, grep'ten farklı olarak yalnızca Git tarafından izlenen dosyalarda arar. .gitignore'da listelenen dosyaları atlar, örneğin bir Node.js projesinde node_modules gibi klasörlerde boşuna aramaz ve çok daha hızlıdır. Çünkü node_modules klasörünü genelde .gitignore ‘a yazarız

node_modules gibi klasörlerde boşuna aramaz ve çok daha hızlıdır.

İkili Arama ile Hata Bulma (git bisect) 🐛

Projemizde bir hata var ama hangi commit’te ortaya çıktığını bilmiyoruz. git bisect, ikili arama (binary search) algoritmasıyla yüzlerce commit arasından hatayı oluşturan commit'i hızlıca bulur.

★ Kullanım

Git otomatik olarak ortadaki bir commit’e checkout yapar. Projeyi test edelim:

Git, her adımda arama alanını yarıya indirir. Birkaç adımda hatalı commit’i bulur:

İşimiz bittiğinde:

💡 128 commit varsa git bisect en fazla 7 adımda hatalı commit'i bulur. (log₂128 = 7)

Commit Detaylarını Görüntüleme (git show) 🔍

Tek bir commit’in detaylarını (yazar, tarih, mesaj ve yapılan değişiklikler) görmek için:

git log geçmişin listesini gösterirken, git show tek bir commit'in tam içeriğini (diff dahil) gösterir.

İzlenmeyen Dosyaları Temizleme (git clean) 🧹

Git tarafından izlenmeyen (untracked) dosyaları çalışma dizininden silmek için:

⚠️ git clean geri alınamaz. Silmeden önce mutlaka -n (dry-run) ile kontrol edelim.

Git Hooks🪝

Hooks, belirli Git olaylarında otomatik olarak çalışan script’lerdir. .git/hooks/ klasöründe bulunurlar.

★ Sık Kullanılan Hook’lar

• pre-commit — Commit öncesi çalışır (lint, format kontrolü)
• commit-msg — Commit mesajı yazıldıktan sonra çalışır (mesaj formatı kontrolü)
• pre-push — Push öncesi çalışır (test çalıştırma)
• post-merge — Merge sonrası çalışır (bağımlılık güncelleme)

★ Örnek: Commit Öncesi Lint Kontrolü

.git/hooks/pre-commit dosyası oluşturalım ve çalıştırılabilir yapalım:

💡 .git/hooks/ klasöründeki hook'lar repository ile paylaşılmaz. Ekip genelinde hook paylaşımı için Husky gibi araçlar kullanılabilir.

Alt Projeler (Submodule & Subtree) 📦

Büyük projelerde başka repository’leri kendi projemize dahil etmemiz gerekebilir.

★ git submodule

Bir repository içinde başka bir repository’yi referans olarak tutar. Alt proje bağımsız kalır, sadece belirli bir commit’e işaret edilir:

Submodule içeren bir repo klonlandığında alt projeler otomatik inmez:

★ git subtree

Başka bir repository’nin kodunu doğrudan projemize kopyalar. Submodule’dan daha basittir ama repo boyutunu artırır:

💡 Submodule daha yaygın kullanılır ancak yönetimi karmaşıktır. Subtree daha basit bir alternatiftir. İhtiyacımıza göre tercih edebiliriz

Git Garbage Collection (git gc) 🗑️

Git, iç yapısında kullanılmayan nesneleri (commit, blob, tree) biriktirir. git gc bu nesneleri temizler ve repository'yi optimize eder:

★ Ne Zaman Çalışır?

• Git bazı komutlarda (git merge, git rebase vb.) otomatik olarak gc tetikler
• Manuel olarak da çalıştırabiliriz

★ Neler Temizlenir?

• Hiçbir branch, tag veya HEAD tarafından referans edilmeyen orphan (yetim) commit’ler
• reflog süresi dolan kayıtlar (varsayılan 90 gün)
• Kullanılmayan Git objeleri

⚠️ Normal şartlarda git gc'yi manuel çalıştırmamız gerekmez. Git bunu arka planda otomatik olarak yapar.

📌 Detaylı bilgi: git-scm.com/docs/git-gc

Git Internals: Kısa Bir Bakış 🧬

Git’in .git klasörünün içinde neler olduğuna kısaca bakalım:

★ Git’in Üç Temel Objesi

• Blob — Dosya içeriğini saklar (dosya adını saklamaz)
• Tree — Bir dizinin yapısını saklar (hangi blob hangi dosya adına karşılık geliyor)
• Commit — Bir anlık görüntüyü (snapshot) temsil eder; tree, yazar, tarih ve mesaj bilgisini içerir

Git, geleneksel olarak her objeyi SHA-1 hash’i ile tanımlar. Bu hash, objenin içeriğinden üretilir. Yeni sürümlerde SHA-256 desteği de bulunmaktadır.

💡 Git Internals konusu başlı başına kapsamlı bir konu olduğu için bu konuyu ayrı bir makalede detaylı olarak ele alacağız.

Git Komutlarını Özetleyelim 📋

★ Temel Komutlar

• git init — Yeni repository oluşturur
• git clone <url> — Uzak repoyu klonlar
• git status — Durumu gösterir
• git add <dosya> — Staging area'ya ekler
• git add . — Tüm değişiklikleri ekler
• git commit -m "mesaj" — Commit oluşturur
• git commit -am "mesaj" — Değişen dosyaları ekler ve commit oluşturur
• git show <hash> — Commit detaylarını gösterir

★ Dosya İşlemleri

• git rm <dosya> — Dosyayı siler ve staging'e ekler
• git rm --cached <dosya> — Git takibinden çıkarır (disk silinmez)
• git mv <eski> <yeni> — Dosyayı taşır/yeniden adlandırır
• git clean -fd — İzlenmeyen dosya ve klasörleri siler

★ Geçmiş ve Farklar

• git log — Commit geçmişini gösterir
• git log --oneline --graph --decorate --all — Görsel commit geçmişi
• git diff — Dosya farklarını gösterir
• git blame <dosya> — Satır satır kimin değiştirdiğini gösterir
• git reflog — HEAD hareket geçmişini gösterir
• git shortlog -sn — Kişi bazlı commit sayıları

★ Dallanma ve Birleştirme

• git branch <ad> — Yeni branch oluşturur
• git branch -d <ad> — Branch siler
• git checkout <branch> — Branch'e geçiş yapar
• git checkout -b <ad> — Oluştur ve geç
• git switch <branch> — Branch'e geçiş yapar (modern)
• git merge <branch> — Branch'leri birleştirir
• git merge --no-ff <branch> — Her zaman merge commit oluşturur
• git merge --abort — Birleştirmeyi iptal eder
• git rebase <branch> — Commit'leri yeniden temellendirir
• git rebase --onto <yeni-temel> <eski-temel> <branch> — Branch'i farklı bir temele taşır
• git cherry-pick <hash> — Belirli commit'i alır

★ Geri Alma

• git restore <dosya> — Dosya değişikliğini geri alır
• git restore --staged <dosya> — Staging'den çıkarır
• git reset --soft HEAD~1 — Commit'i geri alır, değişiklikler staging'de
• git reset --hard HEAD~1 — Commit ve değişiklikleri tamamen siler
• git revert <hash> — Geri alma commit'i oluşturur

★ Geçici Saklama

• git stash — Değişiklikleri geçici saklar
• git stash push -m "mesaj" — Açıklamayla saklar
• git stash -u — Untracked dosyalar dahil saklar
• git stash pop — Son saklananı geri getirir
• git stash list — Saklananları listeler

★ Uzak Repository

• git remote add <ad> <url> — Uzak repo ekler
• git remote -v — Uzak repoları listeler
• git fetch — Uzak değişiklikleri indirir
• git pull — İndirir ve birleştirir
• git pull --rebase — İndirir ve rebase ile birleştirir
• git push — Uzak repoya gönderir
• git push -u origin <branch> — Branch'i ilk kez gönderir
• git push --force-with-lease — Güvenli zorla gönderme

★ Etiketleme ve Arama

• git tag <ad> — Etiket ekler
• git tag -a <ad> -m "mesaj" — Açıklamalı etiket ekler
• git grep "metin" — Dosya içeriğinde arar
• git bisect start — İkili arama ile hata bulur

★ Yapılandırma Kısayolları

• git config --global alias.st status — git st kısayolu
• git config --global alias.co checkout — git co kısayolu
• git config --global alias.br branch — git br kısayolu
• git config --global alias.lg "log --oneline --graph --decorate --all" — git lg kısayolu

📬 Geri Bildirim

Makaleyi yazarken, Kaynakları belirleme ve araştırma için kendi notlarımı yazım denetimi ve ek araştırma için “Claude Opus 4.6” modelini kullandım. Resimleri üretmek için ise “Gemini 3 Pro Preview 2k (Nano Banana Pro)” modelini kullandım.

Yazı ile ilgili tavsiye, öneri, eleştirileri dikkate alıyorum. İletişime geçmek isterseniz bana websitemdeki sosyal medya adreslerimden veya Linkedin üzerinden ulaşabilirsiniz.

Sevgiyle kalın, Yasin 🤗

📚 Makaleyi Yazarken Kullandığım Kaynaklar

• Git Documentation — git-scm.com/doc
• Pro Git Book — git-scm.com/book
• GitHub Docs — docs.github.com
• Atlassian Git Tutorials — atlassian.com/git/tutorials
• Git Commit — Tower
• Git Bisect — Fatih AÇET
• Yeni Başlayanlar İçin Git 101 — Medium
• Başarılı Bir Git Branch Modeli Nasıl Oluşturulur — Medium
• Git: Understanding the Basics — Medium
• Git Notları 5: Branch Kavramı — Medium
• Git Checkout — Atlassian
• Yeni Başlayanlar İçin Git — Medium
• Git Nedir? — Medium
• Git Sunucu Servisleri Alternatifler — Medium
• Conventional Commits
• https://commitizen-tools.github.io/commitizen/
• https://commitlint.js.org/