Git’e Başlangıç: İlk Deponuzu Oluşturun

Git’i yalnızca bir komut listesinden ibaret görmek yerine bir iş akışı olarak düşünmeye başladığınızda öğrenmek çok daha kolay hale gelir. Bir dosya çalışma dizininde oluşturulur veya değiştirilir, hazırlama alanı üzerinden seçilir ve depo geçmişinin bir parçası olarak kaydedilir.

Bu rehber, söz konusu modeli baştan sona uygulamalı bir çalışmaya dönüştürür. Küçük bir proje oluşturacak, bir Git deposu başlatacak, dosya durumlarını inceleyecek, değişiklikleri hazırlayacak, commit oluşturacak, üretilen dosyaları yok sayacak, sürümleri karşılaştıracak ve deponun temiz durumda olduğunu doğrulayacaksınız.

Amaç komutları ezberlemek değil, çalıştırdığınız her komuttan sonra Git içinde neyin değiştiğini anlamaktır.

Ne Oluşturacağız?

Task Notes adlı küçük bir komut satırı projesi oluşturacağız. Proje bir README dosyası ve basit bir metin tabanlı görev listesiyle başlayacak.

Projenin son yapısı şöyle görünecek:

task-notes/
├── .gitignore
├── README.md
├── notes/
│   └── tasks.txt
└── src/
    └── app.txt

Çalışma boyunca şunları öğreneceksiniz:

Yeni bir proje dizini oluşturmak.
Bir Git deposu başlatmak.
Gizli .git dizinini incelemek.
git status çıktısını okumak.
İzlenmeyen, izlenen, değiştirilmiş, hazırlanmış ve commit edilmiş dosya durumlarını anlamak.
Tek tek dosyaları veya dosya gruplarını hazırlama alanına eklemek.
Tek bir amaca odaklanan commit’ler oluşturmak.
Commit oluşturmadan önce git diff kullanmak.
Geçici ve hassas dosyaları yok saymak.
Yerel kopyayı silmeden bir dosyayı Git takibinden çıkarmak.
Proje geçmişini kısa bir biçimde görüntülemek.
Çalışma ağacının temiz olduğunu doğrulamak.

Ön Koşullar

Devam etmeden önce Git’in kurulu olduğunu ve kimlik bilgilerinizin yapılandırıldığını doğrulayın:

git --version
git config --get user.name
git config --get user.email

Ad ve e-posta komutları, yeni commit’lere yazılmasını istediğiniz kimliği döndürmelidir.

Değerlerden biri eksikse aşağıdaki şekilde yapılandırın:

git config --global user.name "Jane Developer"
git config --global user.email "jane@example.com"

Varsayılan başlangıç dalı adını da kontrol edin:

git config --get init.defaultBranch

Herhangi bir değer görünmüyorsa projeyi doğrudan git init -b main ile başlatabilir veya genel varsayılanı ayarlayabilirsiniz:

git config --global init.defaultBranch main

Bir Git Deposu Edinmenin İki Yolu

Bir Git deposuyla çalışmaya başlamanın iki temel yolu vardır:

Yeni veya mevcut yerel bir proje içinde Git’i başlatmak.
Mevcut bir depoyu başka bir konumdan klonlamak.

Bu rehber ilk yönteme odaklanır; çünkü sıradan bir klasörün ilk commit’e kadar nasıl bir Git deposuna dönüştüğünü tüm aşamalarıyla gösterir.

Klonlama konusu, uzak depolar ve ekip çalışması ele alındığında daha sonra açıklanacaktır.

Adım 1: Proje Dizinini Oluşturun

macOS, Linux veya Git Bash

mkdir task-notes
cd task-notes

PowerShell

New-Item -ItemType Directory task-notes
Set-Location task-notes

Bu noktada task-notes yalnızca normal bir dizindir. Git henüz bu dizini takip etmez.

Geçerli konumu kontrol edin:

pwd

PowerShell’de aynı bilgiyi Get-Location komutu verir:

Get-Location

Git’i başlatmadan önce doğru proje dizininin içinde olduğunuzdan emin olun. git init komutunu yanlış dizinde çalıştırmak, istemediğiniz dosyaların Git tarafından takip edilmesine neden olabilir.

Adım 2: Depoyu Başlatın

Şu komutu çalıştırın:

git init -b main

İşlem başarılı olduğunda boş bir Git deposunun başlatıldığını belirten bir mesaj görürsünüz.

Git sürümünüz veya kullandığınız ortam -b seçeneğini desteklemiyorsa şu komutu çalıştırın:

git init

Ardından başlangıç dalının adını doğrulayın:

git branch --show-current

İlk commit oluşturulmadan önce bazı komutlar dalı “unborn” olarak tanımlayabilir. Bunun nedeni, dal adının kavramsal olarak var olması ancak henüz herhangi bir commit’e işaret etmemesidir.

git init Gerçekte Ne Yapar?

git init, projenin içinde .git adlı gizli bir dizin oluşturur. Bu dizin, Git’in depoyu yönetmek için ihtiyaç duyduğu tüm iç verileri barındırır.

Bu dizinde şu yapılar bulunur:

Proje içeriğini ve commit’leri temsil eden nesneler.
Dal ve etiket referansları.
Depoya özel yapılandırma.
Index olarak da adlandırılan hazırlama alanı.
Git işlemlerinin kullandığı günlükler ve meta veriler.

Görünür proje dosyaları çalışma dizininde kalır. Git, depoya ait meta verileri ayrı olarak .git içinde saklar.

Gizli Dizini İnceleyin

macOS, Linux veya Git Bash üzerinde:

ls -la

PowerShell üzerinde:

Get-ChildItem -Force

Listede .git dizinini görmelisiniz.

Git’in iç yapısını bilmiyor ve bir kurtarma planına sahip değilseniz .git içindeki dosyaları manuel olarak düzenlemeyin veya silmeyin. Bu dizinin silinmesi, çalışma klasöründeki depo geçmişini ve yapılandırmayı kaldırır.

git init Tekrar Çalıştırılabilir mi?

Mevcut bir depo içinde git init çalıştırmak genellikle commit geçmişini silmeden depoyu yeniden başlatır. Ancak komutu tekrar tekrar çalıştırmak gereksizdir. Ayrı bir alt dizinin içinde çalıştırmadığınız sürece iç içe yeni bir depo oluşturmaz.

Adım 3: Deponun İlk Durumunu Kontrol Edin

Şu komutu çalıştırın:

git status

Çıktı, başlangıç dalında olduğunuzu, henüz commit bulunmadığını ve şu anda commit edilecek bir şey olmadığını göstermelidir.

git status, günlük kullanımda en önemli Git komutlarından biridir. Şu sorulara yanıt verir:

Hangi daldayım?
Hangi dosyalar izlenmiyor?
Hangi izlenen dosyalar değiştirildi?
Hangi değişiklikler bir sonraki commit için hazırlandı?
Çalışma ağacı temiz mi?

Bu komutu sık kullanın. Yalnızca bilgi veren güvenli bir komuttur; dosyaları veya depo geçmişini değiştirmez.

Kısa Durum Çıktısı

Git daha kısa bir çıktı biçimi de sunar:

git status --short

Bu aşamada proje dosyası bulunmadığı için komut herhangi bir çıktı üretmemelidir.

Adım 4: İlk Proje Dosyasını Oluşturun

macOS, Linux veya Git Bash

cat > README.md <<'EOF'
# Task Notes

Temel Git iş akışını uygulamak için küçük bir proje.

## Özellikler

- Görev notlarını saklama
- Proje dosyalarını düzenleme
- Anlamlı Git commit’leri oluşturma
EOF

PowerShell

@"
# Task Notes

Temel Git iş akışını uygulamak için küçük bir proje.

## Özellikler

- Görev notlarını saklama
- Proje dosyalarını düzenleme
- Anlamlı Git commit’leri oluşturma
"@ | Set-Content README.md

Şimdi çalıştırın:

git status

Git, README.md dosyasını Untracked files başlığı altında göstermelidir.

İzlenmeyen Dosya Nedir?

İzlenmeyen bir dosya çalışma dizininde bulunur ancak henüz Git geçmişinin takip edilen bir parçası değildir.

Git dosyanın varlığını fark eder, ancak onu otomatik olarak bir commit’e eklemez.

Bu önemli bir güvenlik özelliğidir. Bir proje dizini geçici dosyalar, loglar, üretilen çıktılar, kimlik bilgileri veya kişisel editör ayarları içerebilir. Git, hangi yeni dosyaların takip edileceğini bilinçli olarak seçmenizi ister.

Kısa durum çıktısında izlenmeyen bir dosya iki soru işaretiyle gösterilir:

git status --short

Beklenen çıktı:

?? README.md

Adım 5: README Dosyasını Hazırlama Alanına Ekleyin

Şu komutu çalıştırın:

git add README.md

Ardından durumu tekrar inceleyin:

git status

Dosya artık Changes to be committed başlığı altında görünmelidir.

Kısa biçimde:

A  README.md

A harfi, dosyanın hazırlama alanına eklendiği anlamına gelir.

git add Ne Anlama Gelir?

git add birbiriyle ilişkili iki görevi yerine getirir:

Yeni bir dosyayı takip etmeye başlar.
Takip edilen bir dosyanın hazırlanmış sürümünü günceller.

Bu komut commit oluşturmaz. Bir sonraki commit’in kaydedeceği içeriği tam olarak hazırlar.

Şu modeli aklınızda tutabilirsiniz:

Çalışma Dizini
       |
       | git add README.md
       v
   Hazırlama Alanı
       |
       | git commit
       v
Depo Geçmişi

Hazırlama Alanı Bir Dosya Listesi Değil, Bir Anlık Görüntüdür

Yeni başlayanlar hazırlama alanını çoğu zaman bir dosya adları listesi olarak düşünür. Daha doğru bir ifadeyle hazırlama alanı, bir sonraki commit için seçilmiş dosya sürümlerini içerir.

Bu fark önemlidir. Bir dosya hazırlanıp daha sonra tekrar değiştirilebilir. Git, commit için hazırlanan sürümü korurken daha yeni düzenleme çalışma dizininde hazırlanmış olmayan değişiklik olarak kalır.

Bu davranışı çalışmanın ilerleyen bölümünde göreceksiniz.

Adım 6: Hazırlanmış Değişikliği İnceleyin

Şu komutu çalıştırın:

git diff --staged

Aynı işlevi gören şu biçimle de karşılaşabilirsiniz:

git diff --cached

Çıktı, mevcut commit’e göre bir sonraki commit’in neleri içereceğini gösterir. Bu depoda henüz önceki bir commit bulunmadığı için Git yeni dosyanın tamamını eklenmiş içerik olarak görüntüler.

Önemli commit’lerden önce bu komutu kullanın. Şunları fark etmenize yardımcı olur:

Yanlışlıkla bırakılmış hata ayıklama kodları.
Konuyla ilgisiz değişiklikler.
Kimlik bilgileri veya özel bilgiler.
Gereksiz biçimlendirme farkları.
Yanlışlıkla hazırlanan dosyalar.

git status hangi yolların hazırlandığını söyler. git diff --staged ise satır düzeyinde gerçek içeriği gösterir.

Adım 7: İlk Commit’i Oluşturun

Şu komutu çalıştırın:

git commit -m "Proje README dosyasını oluştur"

-m seçeneği commit mesajını doğrudan komut satırında vermenizi sağlar.

Başarılı bir commit, depodaki ilk kayıtlı anlık görüntüyü oluşturur.

Durumu kontrol edin:

git status

Beklenen sonuç:

On branch main
nothing to commit, working tree clean

Tam ifade Git sürümüne göre biraz değişebilir, ancak anlam aynıdır: çalışma dizini ve hazırlama alanı en son commit ile eşleşmektedir.

İlk Commit Neleri İçerir?

Commit şu bilgileri saklar:

README.md dosyasının hazırlanmış sürümü.
Yazar ve commit’i oluşturan kişinin kimliği.
Tarih ve saat.
Proje README dosyasını oluştur mesajı.
Benzersiz bir commit kimliği.
Proje anlık görüntüsüne bir referans.

İlk commit’in üst commit’i yoktur; çünkü proje geçmişini başlatan kayıttır.

Adım 8: Commit Geçmişini Görüntüleyin

Şu komutu çalıştırın:

git log

Çıktı commit kimliğini, yazarı, tarihi ve mesajı gösterir.

Daha kısa bir geçmiş için:

git log --oneline

Örnek:

7a93c2e Proje README dosyasını oluştur

Sizde görünen kimlik farklı olacaktır.

En son commit’i ve içerdiği değişiklikleri incelemek için:

git show --stat
git show --oneline

İlk commit’in başarıyla oluşturulması, Git’in kurulu ve yapılandırılmış olduğunu ve geçmiş kaydedebildiğini gösterir.

Adım 9: Proje Dizinlerini ve Dosyalarını Ekleyin

macOS, Linux veya Git Bash

mkdir -p notes src

cat > notes/tasks.txt <<'EOF'
[ ] git status öğren
[ ] git add öğren
[ ] git commit öğren
EOF

cat > src/app.txt <<'EOF'
Task Notes Uygulaması
Sürüm: 0.1.0
EOF

PowerShell

New-Item -ItemType Directory notes, src

@"
[ ] git status öğren
[ ] git add öğren
[ ] git commit öğren
"@ | Set-Content notes/tasks.txt

@"
Task Notes Uygulaması
Sürüm: 0.1.0
"@ | Set-Content src/app.txt

Şu komutu çalıştırın:

git status --short

Git’in izlenmeyen dizinleri nasıl özetlediğine bağlı olarak şunu görebilirsiniz:

?? notes/
?? src/

Git boş dizinleri değil, dosyaları takip eder. Bir dizin ancak içindeki takip edilen içerik aracılığıyla depo geçmişinde yer alır.

Tek Bir Dosyayı, Bir Dizini veya Geçerli Ağacı Hazırlamak

Belirli bir dosyayı hazırlayabilirsiniz:

git add notes/tasks.txt

Bir dizin içindeki ilgili tüm değişiklikleri hazırlayabilirsiniz:

git add src/

Geçerli dizin altındaki değişiklikleri hazırlayabilirsiniz:

git add .

Depo genelindeki güncellemeleri hazırlamak için şu komutu da kullanabilirsiniz:

git add -A

Yeni başlayan biri için önemli olan her farklı seçeneği ezberlemek değil, neyi hazırladığını kontrol etmeden geniş kapsamlı işlem yapmamaktır.

git add . gibi kapsamlı bir komuttan sonra her zaman şunları inceleyin:

git status
git diff --staged

Geniş kapsamlı hazırlama kullanışlıdır, ancak commit’e dahil etmek istemediğiniz dosyaları da ekleyebilir.

Adım 10: Tek Amaca Odaklanan İkinci Commit’i Oluşturun

Yalnızca görev listesini hazırlayın:

git add notes/tasks.txt

Durumu kontrol edin:

git status --short

Görev dosyasının hazırlandığını, kaynak dizininin ise hâlâ izlenmediğini görmelisiniz.

Hazırlanmış içeriği inceleyin:

git diff --staged

Commit oluşturun:

git commit -m "İlk öğrenme görevlerini ekle"

Şimdi uygulama açıklamasını ayrı olarak hazırlayın ve commit edin:

git add src/app.txt
git commit -m "Uygulama sürüm bilgilerini ekle"

Böylece ilgisiz fikirleri tek bir geniş commit’e koymak yerine iki ayrı ve odaklı commit oluşturmuş olursunuz.

Geçmişi görüntüleyin:

git log --oneline

Örnek:

ca52d10 Uygulama sürüm bilgilerini ekle
34e8c91 İlk öğrenme görevlerini ekle
7a93c2e Proje README dosyasını oluştur

Odaklı Commit’ler Neden Önemlidir?

Bir commit anlaşılabilir tek bir iş birimini temsil etmelidir.

Odaklı commit’ler şunları kolaylaştırır:

İnceleme.
Açıklama.
Test etme.
Geçmişte arama.
Sorun çıktığında geri alma.
Daha sonra değişiklikleri dallar arasında taşıma.

projeyi güncelle adlı tek bir commit’in belgeleri, uygulama mantığını, biçimlendirmeyi ve yapılandırmayı aynı anda değiştirmesi faydalı bir geçmiş oluşturmaz.

Daha iyi bir commit geçmişi, projenin bilinçli adımlarla nasıl geliştiğini açıklar.

Adım 11: İzlenen Mevcut Bir Dosyayı Değiştirin

README.md dosyasına yeni bir bölüm ekleyin.

macOS, Linux veya Git Bash

cat >> README.md <<'EOF'

## Kullanım

`notes/tasks.txt` dosyasını açın ve görev durumlarını güncelleyin.
EOF

PowerShell

@"

## Kullanım

`notes/tasks.txt` dosyasını açın ve görev durumlarını güncelleyin.
"@ | Add-Content README.md

Şu komutu çalıştırın:

git status --short

Beklenen sonuç:

 M README.md

Kısa durum çıktısında harfin bulunduğu konum önemlidir. Buradaki değişiklik çalışma dizininde bulunur ancak henüz hazırlanmamıştır.

Adım 12: Hazırlanmamış Değişiklikleri İnceleyin

Şu komutu çalıştırın:

git diff

Ek bir seçenek verilmediğinde git diff, çalışma dizininde bulunan ancak hazırlanmamış değişiklikleri gösterir.

Şunları karşılaştırır:

Çalışma Dizini ile Hazırlama Alanı

Buna karşılık:

git diff --staged

şunları karşılaştırır:

Hazırlama Alanı ile En Son Commit

Bu ayrım temel öneme sahiptir.

Komut	Gösterdiği Bilgi
`git status`	Dosya durumlarının özeti
`git diff`	Hazırlanmamış satır düzeyindeki değişiklikler
`git diff --staged`	Bir sonraki commit için hazırlanmış satır düzeyindeki değişiklikler
`git log --oneline`	Kısa commit geçmişi
`git show`	Bir commit’in veya başka bir Git nesnesinin ayrıntıları

Adım 13: Aynı Dosyanın Hazırlanmış ve Hazırlanmamış Sürümlerini Görün

README dosyasının mevcut sürümünü hazırlayın:

git add README.md

Şimdi hazırlama alanına eklemeden bir satır daha ekleyin.

macOS, Linux veya Git Bash

echo "" >> README.md
echo "Bu proje Git pratiği için kullanılmaktadır." >> README.md

PowerShell

"" | Add-Content README.md
"Bu proje Git pratiği için kullanılmaktadır." | Add-Content README.md

Şu komutu çalıştırın:

git status --short

Şunu görmelisiniz:

MM README.md

İlk M, değiştirilmiş bir sürümün hazırlandığı anlamına gelir. İkinci M ise çalışma dizininde ek bir hazırlanmış olmayan değişiklik bulunduğunu gösterir.

Her katmanı ayrı ayrı inceleyin:

# Ek hazırlanmamış satırı gösterir
git diff

# Daha önce hazırlanmış README değişikliğini gösterir
git diff --staged

Bu durum, hazırlama alanının neden bir anlık görüntü olduğunu gösterir. git add README.md çalıştırıldığında dosya o anki haliyle yakalandı. Daha sonra yapılan düzenlemeler hazırlanmış sürümü otomatik olarak güncellemedi.

Çalışma dizinindeki en güncel sürümü commit’e dahil etmek için dosyayı tekrar hazırlayın:

git add README.md

Artık:

git diff

hazırlanmamış bir fark göstermemeli; buna karşılık:

git diff --staged

README güncellemesinin tamamını göstermelidir.

Commit oluşturun:

git commit -m "Temel proje kullanımını belgele"

Adım 14: .gitignore Dosyası Oluşturun

Projeler çoğu zaman loglar, geçici çıktılar, yerel ortam dosyaları, bağımlılık dizinleri ve editör önbellekleri gibi sürüm kontrolüne girmemesi gereken dosyalar üretir.

Yerelde kalması gereken bazı dosyalar oluşturun.

macOS, Linux veya Git Bash

mkdir logs
echo "Geçici uygulama çıktısı" > logs/app.log
echo "APP_SECRET=commit-etme" > .env
echo "Geçici notlar" > scratch.tmp

PowerShell

New-Item -ItemType Directory logs
"Geçici uygulama çıktısı" | Set-Content logs/app.log
"APP_SECRET=commit-etme" | Set-Content .env
"Geçici notlar" | Set-Content scratch.tmp

Durumu kontrol edin:

git status --short

Git yeni izlenmeyen yolları göstermelidir.

.gitignore dosyasını oluşturun.

macOS, Linux veya Git Bash

cat > .gitignore <<'EOF'
# Yerel ortam sırları
.env
.env.*

# Uygulama logları
logs/
*.log

# Geçici dosyalar
*.tmp

# Yaygın işletim sistemi dosyaları
.DS_Store
Thumbs.db
EOF

PowerShell

@"
# Yerel ortam sırları
.env
.env.*

# Uygulama logları
logs/
*.log

# Geçici dosyalar
*.tmp

# Yaygın işletim sistemi dosyaları
.DS_Store
Thumbs.db
"@ | Set-Content .gitignore

Şu komutu çalıştırın:

git status --short

Yok sayılan dosyalar normal durum çıktısından kaybolmalıdır. .gitignore dosyasının kendisi görünmeye devam eder; çünkü projenin ortak kuralı olarak commit edilmelidir.

Hazırlayın ve commit edin:

git add .gitignore
git commit -m "Yerel sırları, logları ve geçici dosyaları yok say"

.gitignore Kalıpları Nasıl Çalışır?

Yaygın kalıplar şunlardır:

# Belirli bir dosyayı yok say
.env

# Tüm .log dosyalarını yok say
*.log

# Bir dizini ve içeriğini yok say
logs/

# Her yerdeki geçici dosyaları yok say
*.tmp

# Yalnızca depo kökündeki bir dosyayı yok say
/config.local.php

# build içindeki her şeyi yok say, ancak gerekli bir dosyayı koru
build/*
!build/.gitkeep

Boş satırlar dikkate alınmaz. Kaçış karakteriyle yazılmadığı sürece # ile başlayan satırlar yorumdur.

Depo seviyesindeki .gitignore, tüm ekip için geçerli proje kurallarını tanımlamalıdır. Kişisel editör veya işletim sistemi kalıpları ise geliştiriciye özel genel bir yok sayma dosyasında saklanabilir.

.gitignore İzlenen Dosyaları Etkilemez

Bu durum yeni başlayanların en sık şaşırdığı konulardan biridir.

Bir dosya zaten izleniyorsa adını .gitignore dosyasına eklemek onu Git geçmişinden çıkarmaz ve sonraki değişikliklerinin izlenmesini durdurmaz.

Yok sayma kuralları, özellikle izlenmeyen dosyalara uygulanır.

Dosyayı çalışma dizininde tutarken Git takibinden çıkarmak için:

git rm --cached path/to/file

Ardından dosyanın index’ten çıkarılmasını commit edin.

Bir dizin için:

git rm -r --cached path/to/directory

Bu komutları dikkatli kullanın ve commit oluşturmadan önce hazırlanmış sonucu inceleyin.

Bir Yok Sayma Kuralında Hata Ayıklayın

Git’in bir dosyayı neden yok saydığını anlamıyorsanız şu komutu kullanın:

git check-ignore -v logs/app.log

Çıktı, eşleşmeye neden olan yok sayma dosyasını ve kalıbı gösterir.

Yok sayılan dosyaları durum çıktısında görmek için:

git status --ignored --short

Bu komut, gerekli bir dosya depoda görünmüyorsa özellikle faydalıdır.

Adım 15: Yeni Bir Görev Ekleyin ve Commit Edin

notes/tasks.txt dosyasını güncelleyin.

macOS, Linux veya Git Bash

cat > notes/tasks.txt <<'EOF'
[x] git status öğren
[x] git add öğren
[x] git commit öğren
[ ] Git dallarını öğren
EOF

PowerShell

@"
[x] git status öğren
[x] git add öğren
[x] git commit öğren
[ ] Git dallarını öğren
"@ | Set-Content notes/tasks.txt

Değişikliği inceleyin:

git status
git diff

Hazırlayın:

git add notes/tasks.txt

Hazırlanan içeriği tam olarak inceleyin:

git diff --staged

Commit oluşturun:

git commit -m "Tamamlanan Git öğrenme görevlerini güncelle"

Adım 16: İzlenen Bir Dosyayı Yeniden Adlandırın

src/app.txt dosyasını src/version.txt olarak yeniden adlandırın.

Git’in taşıma komutunu kullanın:

git mv src/app.txt src/version.txt

Durumu kontrol edin:

git status --short

Git, çoğu zaman R harfiyle gösterilen hazırlanmış bir yeniden adlandırma raporlamalıdır.

Commit oluşturun:

git commit -m "Uygulama bilgi dosyasını yeniden adlandır"

Git Yeniden Adlandırmaları Doğrudan Saklar mı?

Git genellikle anlık görüntüleri kaydeder ve yeniden adlandırmaları daha sonra içerik benzerliğini karşılaştırarak tespit eder. git mv komutu, dosya sistemindeki taşıma işlemiyle ilgili silme ve ekleme değişikliklerinin hazırlanmasını birleştiren kullanışlı bir kısayoldur.

Dosyayı işletim sistemi komutuyla yeniden adlandırıp ardından değişiklikleri de hazırlayabilirsiniz. Git sonucu yine yeniden adlandırma olarak algılayabilir.

Adım 17: İzlenen Bir Dosyayı Silin

Gösterim amacıyla eski bir dosya oluşturun ve commit edin.

macOS, Linux veya Git Bash

echo "Eski taslak" > old-notes.txt
git add old-notes.txt
git commit -m "Geçici proje taslağını ekle"

PowerShell

"Eski taslak" | Set-Content old-notes.txt
git add old-notes.txt
git commit -m "Geçici proje taslağını ekle"

Şimdi Git üzerinden kaldırın:

git rm old-notes.txt

Bu komut dosyayı çalışma dizininden siler ve silme işlemini hazırlar.

İnceleyin:

git status
git diff --staged

Commit oluşturun:

git commit -m "Eski proje taslağını kaldır"

Takip edilen bir dosyayı işletim sistemi komutuyla da silebilirsiniz; ancak daha sonra silme değişikliğini ayrıca hazırlamanız gerekir.

Dosya Yaşam Döngüsünü Anlamak

Bir dosya çeşitli durumlar arasında ilerleyebilir:

Yeni dosya
   |
   v
İzlenmeyen
   |
   | git add
   v
Hazırlanmış
   |
   | git commit
   v
İzlenen ve commit edilmiş
   |
   | dosyayı düzenle
   v
İzlenen ve değiştirilmiş
   |
   | git add
   v
Yeniden hazırlanmış
   |
   | git commit
   v
Yeni commit edilmiş sürüm

İzlenen bir dosya ayrıca silinebilir, yeniden adlandırılabilir veya bilinçli olarak index’ten çıkarılabilir.

Durum	Anlamı	Tipik Sonraki İşlem
Untracked	Dosya var ancak Git tarafından takip edilmiyor	`git add` kullanmak veya bir yok sayma kuralı eklemek
Modified	İzlenen dosya, hazırlanmış sürümünden farklı	`git diff` ile incelemek
Staged	Seçilen sürüm bir sonraki commit için hazır	İncelemek ve commit etmek
Committed	Sürüm depo geçmişine kaydedilmiş	Geliştirmeye devam etmek
Ignored	İzlenmeyen yol bir yok sayma kuralıyla eşleşiyor	Genellikle yerelde bırakmak

git status --short Çıktısını Okumak

Kısa biçim iki durum sütunu kullanır:

XY PATH

X: En son commit ile hazırlama alanı arasındaki fark.
Y: Hazırlama alanı ile çalışma dizini arasındaki fark.

Yaygın örnekler:

?? file.txt       İzlenmeyen dosya
A  file.txt       Yeni dosya hazırlanmış
 M file.txt       İzlenen dosya değiştirilmiş ancak hazırlanmamış
M  file.txt       Değiştirilmiş sürüm hazırlanmış
MM file.txt       Hazırlanmış değişiklik ve ek hazırlanmış olmayan değişiklik
D  file.txt       Silme işlemi hazırlanmış
R  old -> new     Yeniden adlandırma hazırlanmış

Uzun durum çıktısı yeni başlayanlar için daha kolaydır. Kısa biçim ise günlük hızlı kontrollerde ve betiklerde kullanışlı hale gelir.

Yola Özel Kullanışlı Komutlar

Yalnızca bir dosyanın durumunu inceleyin:

git status --short README.md

Bir dosyadaki hazırlanmış olmayan değişiklikleri görüntüleyin:

git diff -- README.md

Bir dosyadaki hazırlanmış değişiklikleri görüntüleyin:

git diff --staged -- README.md

Bir dizini hazırlayın:

git add notes/

Çift tire, komut seçeneklerini dosya yollarından ayırır. Dosya adı bir seçeneğe benzediğinde veya komut sözdizimi karmaşıklaştığında özellikle faydalıdır.

git add . Yanlışlıkla Neleri Dahil Edebilir?

Şu komut:

git add .

kullanışlıdır ancak şunları da hazırlayabilir:

Hata ayıklama çıktıları.
Geçici dosyalar.
Üretilmiş build çıktıları.
Büyük medya dosyaları.
Yerel yapılandırmalar.
Yok sayılmamış kimlik bilgileri.
Başka bir göreve ait ilgisiz düzenlemeler.

Şu güvenli sırayı kullanın:

git status
git add .
git status
git diff --staged
git commit -m "Mantıksal değişikliği açıklayın"

Geniş kapsamlı bir hazırlama komutunun yalnızca istediğiniz dosyaları seçtiğini asla varsaymayın.

Gizli Bilgileri Commit Etmeyin

İlk commit’ten önce ve yeni yapılandırma dosyaları eklerken şunları kontrol edin:

Parolalar.
API anahtarları.
Veritabanı bağlantı bilgileri.
Bulut hizmeti kimlik bilgileri.
Özel SSH anahtarları.
Erişim token’ları.
Gerçek üretim ortamı dosyaları.

.env dosyasını .gitignore içine eklemek yanlışlıkla takip edilmesini önlemeye yardımcı olur; ancak yok sayma kuralları bir güvenlik sistemi değildir. Commit oluşturmadan önce hazırlanmış içeriği mutlaka inceleyin.

Gerçek bir gizli bilgi commit edilirse onu sonraki commit’te silmek eski değeri güvenli hale getirmez. Bilgiyi hemen yenileyin veya iptal edin, ardından uygun bir süreçle geçmişi temizleyin.

Son Depoyu Kontrol Edin

Şu komutları çalıştırın:

git status
git log --oneline --decorate

Durum çıktısı temiz bir çalışma ağacı göstermelidir.

İzlenen dosyaları inceleyin:

git ls-files

Beklenen takip edilen içerik:

.gitignore
README.md
notes/tasks.txt
src/version.txt

Yok sayılan .env, logs/app.log ve scratch.tmp dosyaları listede görünmemelidir.

Yok sayılan dosyaları ayrı olarak inceleyin:

git status --ignored --short

Geçmişi grafik biçiminde görüntüleyin:

git log --oneline --graph --decorate --all

Henüz ayrışan dallar bulunmadığı için grafik düz bir commit dizisi olarak görünmelidir.

Manuel İzleme: Her Komuttan Sonra Ne Değişti?

Aşağıdaki manuel izleme, çalışma boyunca oluşan iç durumu özetler.

1. git init Öncesi

Çalışma dizini: Var
.git dizini: Yok
Depo geçmişi: Yok
Hazırlama alanı: Yok

2. git init -b main Sonrası

Çalışma dizini: Var
.git dizini: Oluşturuldu
Geçerli dal: main
Commit’ler: Yok
Hazırlama alanı: Boş

3. README.md Oluşturulduktan Sonra

README.md: İzlenmiyor
Hazırlama alanı: Boş
Commit’ler: Yok

4. git add README.md Sonrası

README.md: İzleniyor ve hazırlanmış
Hazırlama alanı: README.md anlık görüntüsünü içeriyor
Commit’ler: Yok

5. İlk git commit Sonrası

README.md: İzleniyor ve commit edilmiş
En son commit: Proje README dosyasını oluştur
Hazırlama alanı: En son commit ile eşleşiyor
Çalışma ağacı: Temiz

6. README.md Düzenlendikten Sonra

Commit edilmiş sürüm: Korunmaya devam ediyor
Hazırlanmış sürüm: Commit edilmiş sürümle eşleşiyor
Çalışma sürümü: Değiştirilmiş
git diff: Yeni düzenlemeyi gösteriyor

7. Hazırlama ve Tekrar Düzenleme Sonrası

Commit edilmiş sürüm: İlk commit içeriği
Hazırlanmış sürüm: İlk yeni düzenleme
Çalışma sürümü: İlk ve ikinci düzenlemeyi içeriyor
git diff --staged: İlk düzenlemeyi gösteriyor
git diff: İkinci düzenlemeyi gösteriyor

8. Tekrar Hazırlama ve Commit Sonrası

Commit edilmiş sürüm: Her iki düzenlemeyi içeriyor
Hazırlama alanı: En son commit ile eşleşiyor
Çalışma dizini: Hazırlama alanıyla eşleşiyor
Çalışma ağacı: Temiz

Bu, temel Git modelinin uygulamadaki karşılığıdır.

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

git init Komutunu Yanlış Dizinde Çalıştırmak

Başlatmadan önce her zaman geçerli yolu kontrol edin. Dosya sisteminde gereğinden üst bir dizinde oluşturulan depo, ilgisiz dosyaları da gözlemlemeye başlayabilir.

git add Komutunun Commit Oluşturduğunu Sanmak

git add içeriği hazırlar. git commit ise onu geçmişe kaydeder.

git commit Komutunun Değişen Her Dosyayı Dahil Ettiğini Sanmak

Normal bir commit yalnızca hazırlanmış içeriği kaydeder. Hazırlanmamış ve izlenmeyen değişiklikler commit dışında kalır.

git add . Komutunu İncelemeden Kullanmak

Geniş kapsamlı hazırlama ilgisiz veya hassas dosyaları dahil edebilir. Hem durumu hem de hazırlanmış farkları inceleyin.

İncelemeden Tek ve Büyük Bir “İlk Commit” Oluşturmak

İlk commit bile üretilen dosyaları, bağımlılıkları, logları, gizli bilgileri ve yerel yapılandırmayı dışarıda bırakmalıdır.

Takip Edilen Bir Gizli Dosyayı .gitignore’a Eklemek

Yok sayma kuralları geçmişte zaten izlenen bir dosyanın takibini durdurmaz.

.git İçindeki Dosyaları Düzenlemek

.git dizini depo altyapısıdır. Git’in iç yapısını bilinçli olarak incelemiyorsanız onu dahili sistem verisi olarak kabul edin.

Anlamsız Commit Mesajları Yazmak

değişiklikler, güncelleme veya düzeltme gibi mesajlar anlık görüntünün amacını açıklamaz.

Birden Fazla Görevi Aynı Commit’e Karıştırmak

Belgeler, yeniden düzenlemeler, hata düzeltmeleri ve yeni özellikler farklı mantıksal değişiklikleri temsil ediyorsa genellikle ayrı commit’ler halinde tutulmalıdır.

İlk Depolarınız İçin En İyi Uygulamalar

Git’i proje kök dizininde başlatın.
Büyük bir projeyi hazırlamadan önce .gitignore oluşturun.
git status komutunu sık çalıştırın.
Hazırlanmamış çalışmaları git diff ile inceleyin.
Bir sonraki commit’i git diff --staged ile gözden geçirin.
Dosyaları bilinçli olarak hazırlayın.
Commit’leri tek bir amaca odaklı tutun.
Açık ve eylem odaklı commit mesajları yazın.
Gizli bilgileri asla commit etmeyin.
Mümkün olduğunda tamamlanan her görevi temiz bir çalışma ağacıyla bitirin.

Bu Eğitimde Kullanılan Komutlar

Komut	Amacı
`git init -b main`	Başlangıç dalı main olan bir depo oluşturur
`git status`	Çalışma ağacı ve hazırlama alanı hakkında ayrıntılı bilgi gösterir
`git status --short`	Kısa durum kodlarını gösterir
`git add file`	Bir dosyanın mevcut sürümünü hazırlar
`git add .`	Geçerli dizin altındaki ilgili değişiklikleri hazırlar
`git diff`	Hazırlanmamış değişiklikleri gösterir
`git diff --staged`	Bir sonraki commit için hazırlanmış değişiklikleri gösterir
`git commit -m "message"`	Hazırlanmış içerikten commit oluşturur
`git log --oneline`	Kısa commit geçmişini görüntüler
`git show`	Varsayılan olarak en son commit’i inceler
`git check-ignore -v path`	Bir yolun hangi yok sayma kuralıyla eşleştiğini açıklar
`git mv old new`	Bir dosyayı taşır veya yeniden adlandırır ve sonucu hazırlar
`git rm file`	Takip edilen bir dosyayı siler ve silme işlemini hazırlar
`git ls-files`	Index’te takip edilen dosyaları listeler

Başlangıç Kontrol Listesi

Hazırlama alanı ve commit’leri daha ayrıntılı ele alan sonraki makaleye geçmeden önce şunları yapabildiğinizden emin olun:

Bir proje dizini oluşturmak.
git init ile depo başlatmak.
.git dizininin amacını açıklamak.
İzlenmeyen bir dosyayı tanımak.
Belirli bir dosyayı hazırlamak.
Anlamlı bir mesajla commit oluşturmak.
git diff ile git diff --staged arasındaki farkı bilmek.
Hazırlanmış bir dosyanın neden aynı zamanda hazırlanmış olmayan değişiklikler içerebildiğini açıklamak.
.gitignore dosyası oluşturmak ve test etmek.
Yeni yok sayma kurallarının takip edilen dosyaları etkilemediğini bilmek.
Yaygın kısa durum kodlarını okumak.
Deponun temiz bir çalışma ağacına sahip olduğunu doğrulamak.

Sık Sorulan Sorular

Mevcut Bir Projenin İçinde git init Çalıştırabilir miyim?

Evet. Git mevcut bir proje dizininde başlatılabilir. İlk commit’i hazırlamadan önce uygun bir .gitignore oluşturun ve tüm izlenmeyen dosyaları inceleyin.

git init Projeyi İnternete Yükler mi?

Hayır. Yalnızca yerel bir depo oluşturur. Commit’leri yüklemek veya paylaşmak için uzak bir depo ve daha sonra gerçekleştirilecek bir push işlemi gerekir.

Git Boş Dizinleri Takip Eder mi?

Hayır. Git dosya içeriğini takip eder. Projeler bazen boş kalması gereken dizinlere .gitkeep adlı bir dosya koyar; ancak bu dosya adının Git için özel bir yerleşik anlamı yoktur.

git add ile git commit Arasındaki Fark Nedir?

git add, seçilen dosya sürümlerini hazırlama alanına ekler. git commit ise hazırlanmış anlık görüntüyü depo geçmişine kaydeder.

git add Sonrasında git diff Neden Hiçbir Şey Göstermiyor?

Normal git diff yalnızca hazırlanmış olmayan değişiklikleri gösterir. Hazırlamadan sonra bir sonraki commit için seçilen içeriği görmek üzere git diff --staged kullanın.

Yalnızca Bir Dosyayı Commit Edebilir miyim?

Evet. Yalnızca o dosyayı hazırlayın, hazırlanmış farkı inceleyin ve commit oluşturun.

Her Zaman git add . Kullanmalı mıyım?

Hayır. Tüm mevcut değişiklikler aynı işe aitse kullanışlıdır. Ancak birden fazla görev karışmışsa belirli yolları hazırlamak veya etkileşimli hazırlama kullanmak daha fazla kontrol sağlar.

Yok Sayılan Bir Dosya Neden Hâlâ İzleniyor?

Dosya muhtemelen yok sayma kuralı eklenmeden önce commit edilmiş veya hazırlanmıştır. Yok sayma kalıpları zaten takip edilen dosyaları etkilemez.

“Working Tree Clean” Ne Anlama Gelir?

Git’in mevcut commit ve yok sayma kurallarına göre takip edilen değişiklik, hazırlanmış fark veya raporlanabilir izlenmeyen dosya görmediği anlamına gelir.

.git Dizinini Silebilir miyim?

Bu dizini silmek çalışma klasörünü yeniden normal bir dizine dönüştürür ve yerel depo meta verileriyle geçmişini kaldırır. Bunu yalnızca açıkça yapmak istediğinizden ve gerekli geçmişin başka bir yerde güvenle saklandığından emin olduğunuzda yapın.

Sonuç

İlk Git deponuz temel iş akışının tamamını gösterir: projeyi başlatmak, dosyalar oluşturmak, durumlarını incelemek, seçilen sürümleri hazırlamak, hazırlanmış içeriği gözden geçirmek ve tek amaca odaklanan commit’ler kaydetmek.

En önemli ders, Git’in aynı anda birden fazla durumu yönettiğidir. Çalışma dizini mevcut düzenlemeleri, hazırlama alanı önerilen bir sonraki anlık görüntüyü, depo ise commit edilmiş geçmişi içerir. git status, git diff ve git diff --staged gibi komutlar bu durumlar arasındaki farkları görünür hale getirir.

Disiplinli bir iş akışı basittir: durumu inceleyin, düzenleyin, tekrar inceleyin, bilinçli olarak hazırlayın, hazırlanmış farkı gözden geçirin, anlamlı bir mesajla commit edin ve son durumu doğrulayın.

Bir sonraki makalede kısmi hazırlama, değişiklikleri hazırlama alanından çıkarma, commit düzeltme, commit mesajı yapısı ve temiz, kullanışlı bir geçmiş oluşturma stratejileri dahil olmak üzere staging ve commit konuları daha ayrıntılı ele alınacaktır.

Resmî Kaynaklar ve Ek Okumalar