Temel akış

Model kuruldu; şimdi günlük döngü: depo aç ya da klonla, durumu oku, değişikliği seçerek hazırla, anlamlı bir mesajla kaydet, geçmişi oku, farkı incele. Bu altı fiil kariyerin boyunca her gün onlarca kez tekrarlanacak; ama "çalışıyor" ile "iyi yapılıyor" arasında büyük fark var. Kıdemli geliştiricinin geçmişi okunabilirdir: her commit tek bir şey yapar, mesajı nedeni anlatır, sır ve çöp depoya girmez. Bu ders, 15-05'te açılan "her yeşilde commit" senedini de öder: TDD ritmi, commit ritmiyle birleşince anlam kazanır. Bir de sessiz tuzaklar var — satır sonu dönüşümü, izlenen dosyayı ignore etme, add . ile giren istenmeyen dosya — hepsi bu derste.

01Ne öğreneceksin

02Başlangıç: init, clone ve yapılandırma

İki başlangıç var. git init mevcut dizinde boş bir .git yaratır; git clone <url> ise uzak bir depoyu tam geçmişiyle indirir, uzak depoyu origin adıyla kaydeder ve varsayılan dalı çalışma alanına açar (yani clone = init + remote add + fetch + switch; 4. derste bu parçaları ayrı ayrı göreceksin). Kurumda neredeyse her zaman clone ile başlarsın; init, kendi deneme ve araç projelerin içindir.

İlk commit'ten önce Git kim olduğunu bilmeli — commit nesnesinin author satırı buradan dolar ve geçmişe kalıcı olarak yazılır:

git config --global user.name "Cihat Yılmaz"
git config --global user.email "cihat@kurum.gov.tr"
git config --global init.defaultBranch main
git config --list --show-origin

Yapılandırma üç seviyede yaşar ve dar olan genişi ezer: system (makine geneli) → global (~/.gitconfig, kullanıcı) → local (.git/config, depo). Pratik sonucu: kurum e-postan global'de, açık kaynak katkıların için farklı e-posta o deponun local'inde; --show-origin hangi değerin nereden geldiğini gösterir — "e-postam neden yanlış çıkıyor" sorusunun aracı. init.defaultBranch satırı, Git'in tarihsel varsayılanı master yerine yeni depoların main ile açılmasını sağlar; barındırma platformlarının varsayılanı budur ve ekip içinde tek ad kullanmak küçük ama gerçek sürtünme giderir.

Satır sonu tuzağı. Windows dosyaları satırı CRLF (\r\n), Linux ve macOS LF ile bitirir. Karışık bir ekipte bu, "hiçbir şey değiştirmedim ama git tüm dosyayı değişmiş gösteriyor" ve yüzlerce satırlık sahte diff'lerin, çatışmaların kaynağıdır. Eski çözüm core.autocrlf ayarıydı ama kişisel ayar olduğu için ekipte tutarsız kalır. Doğru çözüm depoya commit edilen bir .gitattributes dosyasıdır:

* text=auto eol=lf
*.cmd text eol=crlf
*.png binary
*.pdf binary

İlk satır "metin dosyalarını depoda LF sakla, çalışma alanında da LF ver" der; Windows'a özgü betikler istisna alır; ikili dosyalar dönüşümden ve metin diff'inden korunur. Bu dosya depoda yaşadığı için herkeste aynı davranır — kişisel ayarın aksine. Windows'ta ikinci sessiz tuzak core.ignorecase'tir: Rapor.cs → rapor.cs gibi yalnız büyük-küçük harf değişen yeniden adlandırmayı Git görmez; Linux'taki CI (18. hat) dosyayı bulamaz. Çözüm, yeniden adlandırmayı git mv -f Rapor.cs rapor.cs ile Git'e açıkça yaptırmaktır.

03status'u okumak

git status, 1. dersteki üç bölgenin farkını üç liste hâlinde verir:

On branch main
Your branch is ahead of 'origin/main' by 1 commit.

Changes to be committed:                 ← index ≠ HEAD   (commit'e girecek)
        modified:   Basvuru/Kural.cs
Changes not staged for commit:           ← çalışma alanı ≠ index
        modified:   Basvuru/Kural.cs
        deleted:    eski-notlar.md
Untracked files:                         ← Git'in hiç bilmediği dosyalar
        Basvuru/YeniKural.cs

Aynı dosyanın iki listede birden görünmesi hata değildir — 1. dersteki "add içeriği kopyalar" kuralının doğrudan sonucu: add ettin, sonra yine düzenledin; ilk hâl index'te, ikinci hâl diskte. İlk satırdaki "ahead by 1" ise yerel dalın uzak izleme dalıyla karşılaştırmasıdır (4. ders). Günlük kullanımda kısa biçim yeterlidir: git status -sb — her satırda iki sütun, sol index'in, sağ çalışma alanının durumu (M staged, M unstaged, MM ikisi de, ?? izlenmeyen, A yeni eklenmiş). Bu iki sütunu okuyabilmek, Git'in üç bölgesini içselleştirdiğinin işaretidir.

04add: dosya değil, değişiklik seç

Yeni başlayanın komutu git add .'dir: çalışma dizinindeki her şeyi index'e koyar. Sorunları: izlenmeyen çöp dosyaları (derleme çıktısı, editör ayarı, yanlışlıkla kaydedilmiş appsettings.Development.json — 13-10'un sızıntı yolu) commit'e girer; bir saatlik karışık çalışma tek commit'e dolar. Üç seçenek ve farkı:

add -p (patch) her değişiklik parçasını (hunk) tek tek gösterir ve sorar: y al, n alma, s daha küçük parçalara böl, e elle düzenle, q çık. Bir dosyada hem hata düzeltmesi hem biçimlendirme varsa, düzeltmeyi y, biçimlendirmeyi n ile ayırırsın; iki ayrı commit çıkar. (*) Yeni dosya henüz izlenmediği için -p onu göstermez; önce git add -N dosya ("izlemeye niyet et") dersen parça parça alabilirsin. Kıdemli disiplin: commit'e ne gireceğine add anında karar verilir, sonradan değil. Bunun bir de güvenlik yüzü var: her hunk'ı gözle görmek, sırrın ve hata ayıklama artığının depoya girmesine karşı en ucuz kontroldür — 13-10'daki commit öncesi kanca bunun otomasyonudur, yerine geçmez.

05commit ve iyi mesaj

git commit editör açar; -m "mesaj" tek satır için kısayoldur; -v editörde diff'i de gösterir — mesaj yazarken neyi yazdığını görmek için önerilir. Mesajın biçimi bir gelenektir ve araçlar (log, GitHub, blame) bu geleneğe göre tasarlanmıştır:

Başvuru son gününü saat 23:59'a kadar kabul et

Kural, son günü tarih olarak karşılaştırdığı için son gün
öğleden sonra yapılan başvurular reddediliyordu. Karşılaştırma
günün sonuna taşındı; sınır testi eklendi.

İlgili kayıt: DESTEK-4821

• Özet satırı: 50 karakter civarı, sonda nokta yok, emir kipi ("ekle", "düzelt" — İngilizcede "Add", "Fix"); bir boş satır; gövde 72'de kırılır. Emir kipinin nedeni: mesaj, "bu commit uygulanırsa ... olur" cümlesinin devamıdır ve Git'in kendi ürettiği mesajlarla (Merge branch, Revert) uyumludur.
• Gövde "ne"yi değil "neden"i anlatır. Ne değiştiği diff'te zaten yazılıdır; diff'in söyleyemediği şey gerekçe, reddedilen alternatif ve yan etkidir. Altı ay sonra blame ile bu satıra gelen kişi (çoğu kez sen) diff'i değil bu gövdeyi arar.
• Atomik commit: tek commit, tek mantıksal değişiklik; mesajda "ve" geçiyorsa genellikle iki commit'tir. Atomik commit revert edilebilir, cherry-pick edilebilir, bisect ile suçlanabilir (6. ders) — bileşik commit bunların hiçbirine izin vermez.
• Ekipler çoğu kez Conventional Commits önekini benimser: feat:, fix:, refactor:, test:, docs:; kırıcı değişiklik feat!: ya da gövdede BREAKING CHANGE:. Değeri biçim değil, 15-11'deki changelog ve SemVer kararının commit geçmişinden otomatik türetilebilmesidir: fix → PATCH, feat → MINOR, ! → MAJOR.

Ritim. 15-05'in senedi: TDD döngüsünde her yeşil, güvenli bir geri dönüş noktasıdır — ve bunun somut karşılığı yeşilde commit'tir. Kırmızı-yeşil-refactor turu bitince commit; refactor bitince commit. Bu ritmin iki getirisi var: reset ile dönebileceğin nokta hep birkaç dakika geridedir ve 6. dersteki bisect, her commit'in "testleri geçen bir durum" olduğu bir geçmişte çalışır. Kırmızıda commit atılmaz; atılması gerekiyorsa (gün bitti) mesaja WIP yazılır ve paylaşılmadan önce düzeltilir (6. dersin interactive rebase'i). Karşıt uç da hatadır: günün sonunda tek "günlük çalışma" commit'i, geçmişi kullanılmaz kılar.

06log: geçmişi sorgulamak

git log ham hâliyle uzun ve az bilgilidir; işe yarayan biçimler:

git log --oneline --graph --all --decorate    # graf, tüm dallar, ref adları
git log --stat -5                             # son 5 commit, dosya bazlı özet
git log -p -- Basvuru/Kural.cs                # tek dosyanın fark geçmişi
git log --follow -- Basvuru/Kural.cs          # yeniden adlandırmayı da izle
git log -S "23:59" --oneline                  # bu metni ekleyen/silen commit'ler (pickaxe)
git log --author=Cihat --since="2 weeks"      # kişi ve zaman filtresi
git log --first-parent main                   # yalnız ana hattın commit'leri
git show a1b2c3d                              # tek commit: meta + diff

Üçü kıdem aracıdır. -S (pickaxe), "bu sihirli sayı ne zaman ve neden girdi" sorusunu saniyede cevaplar — 15-09'daki "en son ne değişti" sorusunun geçmiş boyutu. --first-parent, merge commit'lerin ikinci ebeveynine dalmadan yalnız ana hattın ilerleyişini gösterir; dal başına tek satırlık üst düzey tarih okuması için. git blame her satırın son değiştiği commit'i gösterir; ama biçimlendirme commit'i tüm dosyayı "değiştirmiş" göründüğü için gerçek yazarı gizler. Çözüm: blame -w (boşluk değişikliklerini yoksay) ve toplu biçimlendirme commit'lerinin özetlerini bir .git-blame-ignore-revs dosyasına yazıp blame.ignoreRevsFile ayarına bağlamak — 15-10'daki "biçimlendirmeyi makineye devret" kararının geçmişi kirletmemesi için gereken tamamlayıcı.

07diff: hangi iki şeyi karşılaştırıyorsun

Diff'in üç sık biçimi, 1. dersin üç bölgesinin ikili karşılaştırmalarıdır:

Çıktının hunk başlığı @@ -12,7 +12,9 @@ "eski dosyada 12. satırdan 7 satır, yeni dosyada 12. satırdan 9 satır" demektir; sonrasındaki metin (varsa) Git'in tahmin ettiği kapsayan fonksiyon adıdır. --word-diff uzun satırlardaki tek kelimelik değişikliği bulur; --stat yalnız dosya ve satır sayısı verir. Commit öncesi ritüel şudur: git diff --staged — ekranda gördüğün şey, tam olarak commit'e girecek olandır; mesajı ona bakarak yazarsın.

08.gitignore: neyin depoya girmeyeceği

Depoya üretilebilen hiçbir şey girmez: derleme çıktısı (bin/, obj/, dist/), bağımlılık dizinleri (node_modules/), editör ve işletim sistemi artıkları, yerel ortam dosyaları. Ve hiçbir sır girmez — 13-10'un kuralı: bağlantı dizesi, API anahtarı, sertifika. .NET için tipik başlangıç:

bin/
obj/
*.user
.vs/
node_modules/
appsettings.*.json
!appsettings.Development.json.example
*.pfx
.env

Desen kuralları: sondaki / yalnız dizinle eşleşir; başta / yoksa desen her seviyede aranır; * tek seviye, ** çok seviye; ! ile önceki dışlama geri alınır — ama üst dizini dışlanmış bir dosya ! ile geri alınamaz (Git dizinin içine hiç bakmaz). Kişisel dosyalar (.idea/, kendi not dosyan) projenin .gitignore'una değil global ignore dosyana (core.excludesFile) ya da .git/info/exclude'a yazılır: proje dosyası ekibin, exclude seninkidir.

En sık tuzak: .gitignore yalnız izlenmeyen dosyalar için çalışır. Bir dosya bir kez commit edildiyse sonradan ignore'a eklemek onu durdurmaz — değişiklikleri izlenmeye devam eder. Çözüm iki adımdır: git rm --cached dosya (diskte bırak, izlemeyi bırak) + commit. Bu dosya bir sırsa 13-10'un hükmü bakidir: geçmişten silmek ikincil iştir, asıl iş sırrı döndürmektir; geçmiş temizliği 6. derste.

09--amend ve yerel/paylaşılan çizgisi

Son commit'e bir dosya unuttun ya da mesajda yazım hatası var: git add unutulan.cs && git commit --amend (mesaj aynı kalsın: --no-edit). 1. dersin çerçevesiyle ne olduğunu biliyorsun: eski commit değiştirilmez, yeni bir commit yazılır ve dal ref'i ona taşınır; eski commit erişilemez olur, reflog'da kalır. Bu yüzden amend, geçmişi yeniden yazmanın en küçük biçimidir ve hattın en önemli kuralının ilk yüzüdür: yayımlanmamış geçmiş senindir, yayımlanmış geçmiş ekibindir. Push edilmiş bir commit'i amend edersen ekibin elinde eski, sende yeni bir commit olur; 4. derste bunun push'ta nasıl reddedildiğini, 6. derste kuralın tam hâlini göreceksin. Yerel dalda, henüz push etmediğin sürece amend serbest ve teşvik edilir — "düzeltme commit'i" ("typo", "unutulan dosya") yerine temiz commit.

10Mini alıştırma — kurgulanmış geçmiş

11Kendini sına

git diff, git diff --staged ve git diff HEAD neyi neyle karşılaştırır? Aynı dosya status'ta hem "staged" hem "not staged" listesinde nasıl görünür?

Üçü, Git'in üç bölgesinin ikili karşılaştırmalarıdır: git diff çalışma alanını index ile karşılaştırır — "henüz add etmediğim ne var"; git diff --staged (eş anlamlısı --cached) index'i HEAD ile — "commit'e ne girecek", commit öncesi bakılması gereken tam olarak budur; git diff HEAD çalışma alanını HEAD ile — "son commit'ten beri toplam ne değişti". İki commit ya da dal arasında git diff main..dal iki tree'yi karşılaştırır. Aynı dosyanın iki listede görünmesi, add'in dosyayı işaretlemeyip o anki içeriğini blob olarak index'e kopyalamasından kaynaklanır: add ettikten sonra dosya yeniden düzenlenirse ilk hâl index'te (staged), ikinci hâl diskte (not staged) kalır; commit yalnız index'teki hâli alır. Bu, "add etmiştim ama commit'te son değişiklik yok" şikâyetinin açıklamasıdır; çözüm, commit öncesi diff --staged ile doğrulamak ve gerekiyorsa yeniden add etmektir. Hunk başlığı @@ -12,7 +12,9 @@ eski dosyada 12'den 7 satır, yeni dosyada 12'den 9 satır anlamına gelir.

İyi bir commit mesajının biçimi ve içeriği nasıl olmalıdır? "Atomik commit" ne demektir ve neden değerlidir? Yeşilde commit ritmi nedir?

Biçim: 50 karakter civarı, noktasız, emir kipinde bir özet satırı ("Başvuru son gününü 23:59'a kadar kabul et"); bir boş satır; 72'de kırılan gövde. Emir kipi, Git'in kendi mesajlarıyla (Merge, Revert) uyumludur ve "bu commit uygulanırsa ... olur" cümlesini tamamlar. İçerik: gövde "ne"yi değil "neden"i anlatır — ne değiştiği diff'te zaten vardır; diff'in söyleyemediği gerekçe, reddedilen alternatif ve yan etki mesaja yazılır, çünkü altı ay sonra blame ile satıra gelen kişi bunu arar. Ekipler çoğu kez Conventional Commits öneki kullanır (feat/fix/refactor/test/docs, kırıcı değişiklik için !); değeri SemVer ve changelog'un geçmişten otomatik türetilebilmesidir. Atomik commit tek mantıksal değişiklik içerir — mesajda "ve" varsa genellikle iki commit'tir; değeri, tek başına revert, cherry-pick ve bisect ile suçlanabilir olmasıdır; bileşik commit bunların hiçbirine izin vermez. Aracı add -p'dir: hunk bazında seçim. Yeşilde commit ritmi TDD'den gelir: her kırmızı-yeşil-refactor turu ve her refactor sonunda commit; kırmızıda commit atılmaz. Getirisi, geri dönüş noktasının hep birkaç dakika geride olması ve bisect'in her commit'i "testleri geçen durum" olan bir geçmişte çalışabilmesidir. Karşıt uç — gün sonunda tek "günlük çalışma" commit'i — geçmişi kullanılmaz kılar.

.gitignore nasıl çalışır, en sık yapılan hata nedir ve nasıl düzeltilir? Satır sonu (CRLF/LF) sorunu neden çıkar, kalıcı çözümü nedir?

.gitignore, izlenmeyen dosyaların hangilerinin Git tarafından yok sayılacağını desenlerle belirler: sondaki / yalnız dizin, başta / yoksa her seviyede arama, ** çok seviye, ! ile geri alma — ancak üst dizini dışlanmış dosya geri alınamaz. Depoya üretilebilen hiçbir şey (bin/obj/dist/node_modules) ve hiçbir sır girmez; kişisel dosyalar proje dosyasına değil global ignore'a ya da .git/info/exclude'a yazılır. En sık hata: dosya zaten commit edilmişken ignore'a eklemek — ignore yalnız izlenmeyen dosyalar için çalışır, izlenen dosya izlenmeye devam eder. Düzeltme: git rm --cached dosya (diskte kalır, izleme biter) + commit; dosya sırsa asıl iş sırrı döndürmektir, geçmiş temizliği ikincildir. Satır sonu sorunu Windows'un CRLF, Linux/macOS'un LF kullanmasından çıkar: karışık ekipte dosyalar "hiç değiştirilmeden" tümüyle değişmiş görünür, sahte diff ve çatışma üretir. Kişisel core.autocrlf ayarı ekipte tutarsız kalır; kalıcı çözüm depoya commit edilen .gitattributes'tır: * text=auto eol=lf, Windows betikleri için eol=crlf istisnası, ikili dosyalar için binary. Windows'ta ikinci tuzak büyük-küçük harf: yalnız harf durumu değişen yeniden adlandırma core.ignorecase nedeniyle görülmez, git mv -f ile yapılır.

git commit --amend gerçekte ne yapar? "Yayımlanmamış geçmiş senindir" kuralı ne anlama gelir? log -S, --first-parent ve blame'in ignore-revs dosyası ne işe yarar?

Amend, son commit'i düzenlemez — nesneler değişmezdir; yeni bir commit yazar (aynı ebeveynle, güncellenmiş tree ve mesajla) ve dal ref'ini ona taşır; eski commit erişilemez olur ve reflog'da kalır. Bu, geçmişi yeniden yazmanın en küçük hâlidir ve hattın temel kuralını kurar: henüz push edilmemiş geçmiş yerel ve düzenlenebilirdir (amend, interactive rebase serbest ve teşvik edilir — "typo" commit'i yerine temiz commit); push edilmiş geçmiş ekibindir, çünkü amend sonrası ekipte eski, sende yeni commit olur ve push reddedilir, zorlanırsa başkalarının işi bozulur. git log -S "metin" (pickaxe) bu metnin sayısını değiştiren — yani ekleyen ya da silen — commit'leri bulur: "bu sihirli sayı ne zaman girdi" sorusunun aracı. --first-parent merge commit'lerin ikinci ebeveynine dalmadan yalnız ana hattın ilerleyişini gösterir; üst düzey tarih okuması içindir. Blame her satırın son değiştiği commit'i verir ama toplu biçimlendirme commit'i tüm dosyayı değiştirmiş göründüğü için gerçek yazarı gizler; -w boşluk değişikliklerini yoksayar ve biçimlendirme commit'lerinin özetlerini içeren .git-blame-ignore-revs dosyası blame.ignoreRevsFile ayarıyla bağlanınca blame onları atlar — biçimlendirmeyi makineye devretme kararının geçmişi kirletmemesi için gereken tamamlayıcıdır.

12Sınav köşesi