Kısım II · İnşaat · Bölüm 28

Git

Kodun hafızası (Version control with Git)

1. Kat 10Bizim uygulamamızBizim uygulamamızın kodu: Git bu katın geçmişini ve ekip çalışmasını yönetir.
2. Kat 9Web ve tarayıcı: HTML, CSS, JavaScriptTarayıcı denen programın anladığı diller: iskelet, görünüm, davranış. Bölüm 20, 23–26.
3. Kat 8Ağ ve internetBilgisayarların birbirine bit göndermesi; IP, TCP, DNS, HTTP. Bölüm 19–20.
4. Kat 7İşletim sistemi (macOS, Windows, Linux)Git, işletim sisteminin dosya ve klasörleri üzerinde çalışan bir araçtır; terminalden kullanılır. Bölüm 16, 18.
5. Kat 6Gömülü yazılım (firmware) ve açılışDüğmeye basınca ilk çalışan program. Bölüm 12.
6. Kat 5Programlama dilleri ve derleyiciİnsanın okuduğu kodu makine diline çeviren araçlar. Bölüm 9–11, 21.
7. Kat 4Makine dili ve assemblyİşlemcinin doğrudan anladığı komutlar. Bölüm 7.
8. Kat 3İşlemci ve bellek (CPU, RAM)Komutları çalıştıran makine ve verinin durduğu yer. Bölüm 6, 8.
9. Kat 2Devreler: hesap ve hafızaToplayıcılar ve hatırlayan devreler. Bölüm 4–5.
10. Kat 1Transistör ve mantık kapılarıElektrikle açılıp kapanan anahtarlar. Bölüm 3.
11. Kat 0Elektrik ve bit (zemin)Var ya da yok, 1 ya da 0. Bölüm 2.

Bu bölümün sonunda şunları bileceksin: Git'in neden icat edildiğini ve diğer sürüm kontrol sistemlerinden farkını; bir dosyanın Git'te üç durumdan (değiştirildi, hazırlandı, kaydedildi) hangisinde olduğunu nasıl okuyacağını; commit'in bir anlık görüntü olduğunu ve neden küçük, tek amaçlı commit'lerin iyi alışkanlık olduğunu; dalın aslında bir işaretçi olduğunu; iki dalı nasıl birleştireceğini ve çakışma çıkınca ekranda ne göreceğini; uzak depo ve GitHub'ın rolünü; çekme isteğinin ne olduğunu; ve bölümün ağırlık merkezi olarak, çalışma ağacı (git worktree) ile aynı depoda birden çok dalın aynı anda nasıl yaşayabildiğini. Kitabın ilerisinde agent'larla çalışırken en çok işine yarayacak bölümlerden biri budur.

28.1 Sürüm kontrolü neden var; depo, çalışma dizini, hazırlık alanı

Kopya klasörler çağı

Pro Git kitabı, sürüm kontrolünü anlatmaya o tanıdık alışkanlıkla başlar: birçok kişi sürüm kontrolünü dosyaları başka bir klasöre kopyalayarak yapar, zeki olanlar klasöre tarih de koyar. Kitabın tespiti: bu yöntem çok yaygındır çünkü çok basittir, ama aynı zamanda hataya çok açıktır; hangi klasörde olduğunu unutup yanlış dosyanın üstüne yazmak kolaydır.¹ Kendi bilgisayarında proje, proje-son, proje-son-gercek, proje-son-gercek-2 klasörleri gördüysen aynı sorunu yaşamışsındır.

Bunun çözümü sürüm kontrol sistemi (version control system, VCS)dir: dosyalardaki değişikliklerin hepsini tutan bir veritabanı. Aynı kitaba göre bu sistemler üç kuşakta gelişti:¹

1. Yerel sistemler (ör. RCS): değişiklik kayıtlarını diskte basit bir veritabanında tutar. Sorun: yalnızca senin bilgisayarında; başkalarıyla çalışamazsın.
2. Merkezî sistemler (CVS, Subversion, Perforce): tüm dosyalar tek bir sunucuda, herkes oradan dosya çeker. İşbirliğini mümkün kıldı; ama bedeli tek hata noktasıdır: sunucu bir saat çökerse o saat kimse çalışamaz ve kaydedemez; sunucunun diski bozulursa ve yedek yoksa projenin bütün geçmişi gider.¹
3. Dağıtık sistemler (Git, Mercurial, Darcs): istemciler yalnızca son dosya anlık görüntüsünü çekmez, depoyu bütün geçmişiyle birlikte yansılar. Sunucu ölürse herhangi bir istemcinin kopyası sunucuyu geri yükler; her kopya aslında tam bir yedektir.¹

Git'in bir sonucu da şu: Pro Git'e göre Git'teki neredeyse her işlem yalnızca yerel dosyalara ihtiyaç duyar; bütün geçmiş diskinde olduğu için geçmişe bakmak neredeyse anlıktır ve uçakta ya da internetsiz yerde bile kaydedebilirsin.²

Git'in üç alanı

Pro Git'in "Git hakkında hatırlaman gereken ana şey" dediği kısım, dosyaların üç durumundan oluşur ve üç yere karşılık gelir.² İlk önce dosyaların bulunabileceği üç durum:

• Değiştirilmiş (modified): dosyayı değiştirdin ama henüz veritabanına kaydetmedin.
• Hazırlanmış (staged): değiştirilmiş bir dosyanın şu anki halini bir sonraki kaydın içine gireceği diye işaretledin.
• Kaydedilmiş (committed): veri yerel veritabanında güvenle saklandı.

Bu üç duruma üç yer karşılık gelir:²

Temel iş akışı Pro Git'te şöyle özetlenir: çalışma dizininde dosyaları değiştirirsin; yalnızca bir sonraki kayda girmesini istediğin değişiklikleri seçerek hazırlarsın (böylece hazırlık alanına yalnızca onlar eklenir); sonra kaydedersin: hazırlık alanındaki dosyalar olduğu gibi kalıcı bir anlık görüntü olarak depoya yazılır.² Neden araya "hazırlık alanı" konmuş? Çünkü bir saat boyunca beş farklı şey yaptın; hepsini tek bir kayıt yapmak zorunda değilsin. Hazırlık alanı, yaptıklarından hangisinin hangi kayda gireceğini seçebileceğin bir tezgâhtır. Bunun neden önemli olduğunu 28.2'de göreceğiz.

İlk komutlar: depo kurmak ve durumu okumak

Bir klasörü depoya çeviren komut git init. Durumu okuyan komut git status; Pro Git bunu dosyaların hangi durumda olduğunu belirlemenin ana aracı olarak sunar.³ Bir deneme klasöründe yaptım (Bölüm 18'deki terminalde, $ işareti yazdığımız komut, altındaki çıktı):

$ git init -q -b main uygulama     # boş bir depo; ilk dal adı: main
$ cd uygulama
$ echo 'const TEMEL_PUAN = 10;' > puan.js
$ printf 'node_modules/\n.env\n' > .gitignore
$ echo 'SECRET=1' > .env
$ git status --short
?? .gitignore
?? puan.js

Satır satır: init gizli bir .git klasörü açar; işte depo budur. Sonra üç dosya yarattım. status --short kısa bir özet verir; ?? "izlenmeyen" (untracked) demektir: Git bu dosyaları görüyor ama onları henüz takip etmiyor. .env'in listede olmadığına dikkat et: onu 28.7'de açıklayacağız. İlk dosyaları hazırlayalım:

$ git add puan.js .gitignore
$ git status --short
A  .gitignore
A  puan.js

git add dosyaları hazırlık alanına alır: baştaki A (added) harfi "bir sonraki kayda eklenecek" anlamına gelir. Pro Git'in uyarısı önemlidir: kaydettiğin an, git add yaptığın andaki dosya hali kayda girer; ondan sonra dosyayı değiştirirsen o değişikliği yeniden hazırlamalısın.³

28.2 Commit: anlık görüntü, mesaj, geçmiş; küçük ve tek amaçlı commit'ler

Commit bir fark değil, fotoğraftır

Commit (commit), hazırlık alanındakileri depoya kalıcı olarak yazan işlemdir; ve yazılan şeye de commit denir. Burada Git'in ayırt edici fikri var. Pro Git'e göre çoğu sistem bilgiyi dosya değişiklikleri listesi (delta) olarak saklar: her dosya için zaman içinde yapılan değişikliklerin dizisi. Git öyle yapmaz; verisini küçük bir dosya sisteminin bir dizi anlık görüntüsü (snapshot) gibi görür: her commit'te Git o anda bütün dosyaların nasıl göründüğünün bir resmini çeker ve o resme bir referans saklar. Verimli olmak için, değişmeyen dosyayı yeniden saklamaz; daha önce sakladığı özdeş dosyaya bir bağlantı koyar.²

commit 1          commit 2          commit 3
┌─────────┐       ┌─────────┐       ┌─────────┐
│ puan.js │       │ puan.js'│ ◄─┐   │ puan.js'│
│ seri.js │ ◄─┐   │ seri.js │ ──┘   │ seri.js'│
└─────────┘   └── └─────────┘       └─────────┘
(değişmeyen dosya: yeniden saklanmaz, öncekine bağlanır)

Bunu Bölüm 16'daki dosya sistemine bağla: bir commit, projenin klasör ağacının tam bir kopyasını gösteren bir kayıttır; zaman içindeki kayıtlar zincirdir. Pro Git, Git'in bu yüzden basit bir sürüm kontrol aracından çok, üzerine güçlü araçlar eklenmiş küçük bir dosya sistemine benzediğini söyler.²

Her commit'in bir adı var: özet değer (hash)

Her commit, içeriğinden hesaplanan bir özet değerle (hash) adlandırılır. Pro Git'e göre Git'teki her şey saklanmadan önce sağlama toplamından geçirilir ve o sağlama toplamıyla anılır; bu da Git'in bilmediği bir yerde herhangi bir dosyanın içeriğini değiştirmenin imkânsız olması demektir. Kullanılan yöntem 40 karakterlik, onaltılık rakamlardan (0–9, a–f) oluşan bir SHA-1 özetidir: 24b9da6552252987aa493b52f8696cd6d3b00373 gibi.² Onaltılık yazımı Bölüm 2.4'te gördün: iki rakam bir byte, yani 40 rakam 20 byte (160 bit). Pratikte ilk birkaç karakter yeter: benim deneme commit'imi 3247184 diye kısa gördüm. Bu "adın içerikten üretilmesi" fikri hem bütünlük (içerik değişirse ad değişir) hem de kimlik sağlar.

Pro Git'in bir başka güven verici gözlemi: Git'teki işlemlerin hemen hepsi veritabanına yalnızca ekleme yapar; bir şeyi geri alınamaz hale getirmek ya da silmek zordur; commit'ini yaptığın bir anlık görüntüyü kaybetmek çok zordur, özellikle de depoyu düzenli olarak başka bir yere gönderiyorsan.² Bu, deneme yapmayı güvenli kılar: kaydettin mi, geri dönebilirsin.

Kaydetmek: git commit ve mesaj

Aşağıdaki, yukarıdaki deneme deposunda yaptığım ilk kayıt:

$ git commit -q -m "Puan hesabı için TEMEL_PUAN sabitini ekle"
$ git log --oneline
3247184 Puan hesabı için TEMEL_PUAN sabitini ekle

-m mesajı doğrudan komuta yazar (yazmazsan Git bir metin düzenleyici açar ve boş mesajla kaydı iptal eder³). git log --oneline geçmişi bir satır bir commit olarak gösterir: kısa özet değer ve mesaj. Her commit ayrıca yazarını, tarihini ve kendisinden önceki commit'i (ebeveynini) tutar; geçmiş, bu ebeveyn bağlantılarıyla geriye doğru bir zincirdir.

Küçük ve tek amaçlı commit'ler: iyi alışkanlık

Emre'nin "çok küçük, tek amaçlı commit" sevdiğini biliyorum; şimdi nedenini kitaptan dinle. Pro Git'in "Commit Guidelines" bölümü şunu söyler: her commit'i mantıksal olarak ayrı bir değişiklik kümesi yapmaya çalış. Bütün hafta sonu beş ayrı konuda kod yazıp pazartesi hepsini tek bir devasa commit olarak gönderme; hafta sonu kaydetmediysen bile pazartesi hazırlık alanını kullanıp işi en az konu başına bir commit'e böl, her birine anlamlı bir mesaj yaz. Aynı dosyada birden çok konunun değişikliği varsa git add --patch ile dosyayı kısmen hazırlayabilirsin. Üstelik bir commit de olsa beş commit de olsa dalın ucundaki son anlık görüntü aynıdır; yani küçük commit'ler son sonucu değiştirmez, ama başkalarının (ve senin) işini kolaylaştırır; ve gerekirse bir değişiklik kümesini ayıklamak ya da geri almak da kolaylaşır.⁸

Neden bu kadar önemli, ayrıntıyla:

• İnceleme kolaylığı: 10 satırlık tek amaçlı bir değişikliği okumak dakikalar sürer; 800 satırlık karışık bir değişikliği okumak kimsenin yapamayacağı bir iştir (Ousterhout'un bilişsel yük fikri, 27.3).
• Geri alma: "Seri hesabı bozuldu" dediğinde yalnızca seri değişikliğini geri alabilirsin; ilgisiz üç düzeltmeyi de götürmezsin.
• Hata arama: Bir hatanın hangi değişiklikle girdiğini bulmak istediğinde küçük commit'ler seni tek bir satıra götürür.
• Agent'larla çalışmak: Bir agent'a "şunu yap" dediğinde ve o da tek amaçlı commit'ler bırakırsa, yaptığını commit commit okuyabilirsin. Agent'ın çıktısını denetleyebilmek, "anlamadığım şeyin beni sürüklemesi" riskinin ilacıdır (Bölüm 46).

İyi bir commit mesajı

Pro Git'in önerdiği biçim: bir ilk satır (yaklaşık 50 karakteri aşmayan, değişikliği kısaca anlatan özet), sonra boş bir satır, sonra gerekirse ayrıntılı açıklama. Mesajı emir kipinde yaz: "Fix bug" yaz, "Fixed bug" ya da "Fixes bug" yazma; çünkü bu biçim git merge ve git revert'in ürettiği mesajlarla uyumludur. Boş satır önemlidir: araçlar özetle gövdeyi ayırmak için ona bakar.⁸ Türkçede karşılığı: "Seri sıfırlama hatasını düzelt", "Puan hesabına bonus ekle" (emir kipi); "Düzeltildi" ya da "Bonus eklendi" değil. Benim deneme mesajım da bu kalıpta: "Puan hesabı için TEMEL_PUAN sabitini ekle".

28.3 Dal, birleştirme, çakışma, yeniden temellendirme

Dal bir işaretçidir

Şu sorunu düşün: uygulamada seri özelliğini geliştiriyorsun (yarım, bozuk), ama bu sırada acil bir puan hatasını düzeltip yayına vermen gerekiyor. Yarım işi nereye koyacaksın? Cevap dal (branch): ana çizgiden ayrılan bir yan çizgi. Pro Git'in tanımı çok sadedir: Git'te dal, bir commit'e işaret eden hafif, taşınabilir bir işaretçidir. Commit yaptıkça dal işaretçisi kendiliğinden ileri kayar.⁴ Bir dal "dosyaların bir kopyası" değildir; bir etikettir. Bu yüzden dal oluşturmak neredeyse bedavadır.

Yeni dal oluşturmak yalnızca yeni bir işaretçi yaratır: git branch testing, şu anda bulunduğun commit'e yeni bir işaretçi koyar. Git hangi dalda olduğunu HEAD denen özel bir işaretçiyle bilir: HEAD, şu anda üzerinde çalıştığın yerel dalı gösterir.⁴ Dal değiştirmek (git checkout testing ya da yeni komut git switch testing) HEAD'i taşır; ve çalışma dizinindeki dosyaları o dalın gösterdiği anlık görüntüye geri çevirir.⁴ Kendi denememde iki dalın bir commit'i nasıl paylaştığı --decorate ile görülüyor (bu bölümdeki worktree denememden):

$ git log --oneline --all --decorate --graph
* f5e08b8 (seri-ozelligi) Seri takibi için seriGuncelle fonksiyonunu ekle
* 3247184 (HEAD -> main, leaderboard) Puan hesabı için TEMEL_PUAN sabitini ekle

İki dal (main ve leaderboard) aynı commit'i gösteriyor; seri-ozelligi bir commit ilerde. HEAD -> main, şu anda main'de olduğumuzu söyler.

Birleştirme

Seri özelliği bitince onu ana dala birleştiririz (merge). Birleştirmek istediğin dalın içine geçersin ve git merge yazarsın: git checkout main sonra git merge seri-ozelligi. İki durum var. Birincisi, ana dalın ucu zaten seri dalının atası ise (ana dalda bu arada yeni commit yok), Git yalnızca işaretçiyi ileri kaydırır ("fast-forward"). İkincisi, iki dal ortak bir atadan ayrıldıktan sonra ikisinde de commit varsa Git biraz iş yapmak zorundadır: Pro Git'in anlattığı üç yollu birleştirme (three-way merge): iki dalın uçlarındaki iki anlık görüntü ve ortak ata kullanılarak yeni bir anlık görüntü üretilir ve ona işaret eden yeni bir commit kendiliğinden oluşur. Buna birleştirme commit'i (merge commit) denir; özelliği birden fazla ebeveyni olmasıdır.⁵ İşi biten dalı git branch -d seri-ozelligi ile silebilirsin; silinen yalnızca işaretçidir, commit'ler zaten birleşik geçmişin içindedir.⁵

Çakışma

Aynı dosyanın aynı yerini iki dalda farklı değiştirdiysen Git hangisinin doğru olduğunu bilemez; bu durumda birleştirme duraklar ve buna çakışma (merge conflict) denir.⁵ Bunu deneyimle göstereyim. puan.js'te TEMEL_PUAN'ı bir dalda 12, ana dalda 15 yaptım ve birleştirdim:

$ git merge a1
Auto-merging puan.js
CONFLICT (content): Merge conflict in puan.js
Automatic merge failed; fix conflicts and then commit the result.

$ cat puan.js
<<<<<<< HEAD
const TEMEL_PUAN = 15;
=======
const TEMEL_PUAN = 12;
>>>>>>> a1

$ git status --short
UU puan.js

Dosyada Git üç işaret bıraktı: <<<<<<< HEAD ile ======= arası, bulunduğun dalın (main) versiyonu; ======= ile >>>>>>> a1 arası, getirdiğin dalın versiyonu. Pro Git'e göre çözmek için ya bir tarafı seçersin ya da içeriği kendin birleştirirsin; işaret satırlarının hepsini silersin, dosyayı git add ile "çözüldü" diye işaretlersin, sonra kaydedersin.⁵ UU, "iki taraf da değiştirdi, birleştirilmemiş" anlamına gelir. Çakışma bir hata değil, Git'in seni çağırmasıdır: iki insanın (ya da agent'ın) aynı satıra dokunduğunu söylüyor; hangisinin doğru olduğuna yalnızca ürünü bilen biri karar verebilir.

Çakışma ihtimalini azaltan şeyler 27. bölümdeki ilkelerle aynı: iyi ayrılmış, gevşek bağlı modüller ve küçük commit'ler. İki kişi farklı dosyalara dokunuyorsa Git çakışma bulmaz.

Yeniden temellendirme

Aynı ayrılmış iki geçmişi birleştirmenin ikinci yolu yeniden temellendirme (rebase)dir: bir dalda yapılan commit'lerin değişikliklerini alıp başka bir dalın ucuna yeniden oynatırsın. Pro Git'e göre git bunu şöyle yapar: iki dalın ortak atasına gider, senin dalındaki her commit'in getirdiği farkı çıkarır ve geçici dosyalara kaydeder, mevcut dalı hedef dalın ucuna sıfırlar ve farkları sırayla uygular.⁶ Sonuç: sanki işi baştan, hedef dalın en güncel halinin üzerinde yapmışsın gibi. Birleştirmeyle son anlık görüntü aynıdır; fark, geçmişin şeklinde: rebase doğrusal, temiz bir geçmiş verir, her şey arka arkaya olmuş gibi görünür.⁶

merge:                       rebase:
main:   A──B──────M          main:   A──B──C
         \      /                              \
feature:  C──D──                feature:  C'──D'   (yeniden oynatıldı)

28.4 Uzak depo: GitHub, push / pull / clone; çatal

Uzak depo ve GitHub

Şimdiye kadar her şey senin bilgisayarında. İşbirliği için depoyu başka bir yere de koymak gerekir. Uzak depo (remote), internette ya da ağda bir yerde duran, aynı projenin başka bir kopyasıdır. GitHub (GitHub), bu uzak depoları barındıran bir hizmettir; ama GitHub Git'in kendisi değildir: Git, yerelde çalışan sürüm kontrol aracıdır; GitHub onun üzerine ekip özellikleri (çekme isteği, inceleme, sorun takibi) ekleyen bir site. (GitHub'ın bir tek seçenek olmadığını, Pro Git'in sunucu bölümünün GitLab gibi alternatifleri de anlattığını not edelim.) Uzak depoyla konuşma Bölüm 19–20'deki ağ katmanında olur; Git bunu sana soyutlar.

clone, fetch, pull, push

• git clone (klonlamak): uzak bir depoyu bütün geçmişiyle yerel bilgisayara kopyalar. Pro Git'e göre klonladığında Git uzak depoyu otomatik olarak origin adıyla ekler.⁷ (28.1'deki "her klon tam bir yedektir" cümlesi budur.)
• git fetch origin: uzak depoda sende olmayan her şeyi indirir; ama kendiliğinden birleştirmez ve çalıştığın şeyi değiştirmez; hazır olduğunda elle birleştirirsin.⁷
• git pull: dalın bir uzak dalı izliyorsa, fetch yapıp ardından o uzak dalı bulunduğun dala birleştirir.⁷ Yani pull = fetch + merge. (Pro Git, Git 2.27'den itibaren pull.rebase ayarı yoksa uyarı çıktığını da not eder: ayarla, birleştirme mi yeniden temellendirme mi yapılacağını belirlersin.⁷)
• git push (göndermek): yerel commit'lerini uzak depoya gönderir: git push origin main. Bu komut yalnızca yazma iznin olan bir sunucuya ve bu arada kimse göndermemişse çalışır.⁷ Kimse bu arada göndermişse önce pull ile onların işini alırsın, birleştirirsin, sonra gönderirsin.

Akış şöyle: clone bir kez, sonra döngü: dal aç, küçük commit'ler yap, pull ile uzaktaki yeniliği al, push ile işini gönder.

Çatal

Yazma iznin olmayan bir projeye katkıda bulunmak istersen çatal (fork) kullanırsın. Pro Git'e göre bir projeyi çatalladığında GitHub, tamamen sana ait, senin ad alanında yaşayan ve gönderebildiğin bir kopya yapar.⁹ GitHub Docs'a göre çatal, başka bir depo olan "upstream" deponun kopyası olarak başlayan bir depodur; kendi ayarları ve izinleri vardır ama upstream'e bağlı kalır. Dal, bir deponun parçasıdır; çatal ise ayrı bir depodur ve kendi dalları, sorunları, çekme istekleri vardır.¹² Kendi projemizde (iki kişi, ikisi de yazar) çatala çoğunlukla gerek olmaz: ikimiz aynı depoya dal göndeririz. Çatal, açık kaynak projelere katkı verirken karşına çıkar.

28.5 Çekme isteği ve kod incelemesi

Çekme isteği (pull request, PR), GitHub'ın anlatımıyla, kod değişikliklerini bir projeye birleştirme önerisidir; birleştirmeden önce değişiklikleri tartışmayı ve incelemeyi mümkün kılar, böylece ekipler sorunları erken yakalar ve kod kalitesini korur.¹⁰ Adı "çekme" isteğidir çünkü şu anlama gelir: "şu dalımdaki değişiklikleri senin ana dalına çek". Git'in kendi bir özelliği değil, GitHub'ın (ve benzer sitelerin) ekleme özelliği; Git'te iki dalı birleştiren şey hâlâ merge.

Çekme isteğinin parçaları

GitHub Docs'a göre bir çekme isteği, incelemecinin değişikliği anlaması için gereken bağlamı sekmeler halinde toplar:¹⁰

• Conversation: açıklama, zaman çizelgesi, yorumlar ve incelemeler;
• Commits: dalın zaman içinde nasıl değiştiği (küçük, tek amaçlı commit'lerin değeri burada görünür);
• Checks: otomatik testler, derlemeler ve diğer doğrulamalar (testleri Bölüm 42'de göreceğiz);
• Files changed: incelemecilerin değişikliği anlamak için baktığı fark (diff).

Bir çekme isteğini taslak (draft) olarak açabilirsin: taslaklar birleştirilemez ve henüz birilerinden resmî inceleme istemeden yarım işi paylaşmak için kullanılır; hazır olunca "incelemeye hazır" diye işaretlenir.¹⁰

Kod incelemesi

Kod incelemesi (code review), değişiklik birleşmeden önce başka birinin onu okuyup yorumlamasıdır. GitHub Docs'a göre inceleyen kişi üç karardan birini verir: Comment (onay ya da değişiklik talebi olmadan genel geri bildirim), Approve (değişiklikler birleştirmeye hazır), Request changes (birleştirmeden önce yazarın ele alması gereken geri bildirim). İncelemeci belirli satırlara da yorum yazabilir, tam bir değişiklik önerebilir.¹¹ İnceleme, hataları yakalamanın yanında bilgi paylaşımıdır: kod tabanını bilen herkes neyin değiştiğini öğrenir.

28.6 Çalışma ağacı (git worktree): aynı depoda birden çok dalda aynı anda çalışmak

Bu, bölümün en önemli kısmı ve Bölüm 46'daki agent'larla çalışmanın temeli; yavaş ilerleyelim.

Sorun: bir klasör, bir dal

Hatırla: çalışma dizini, projenin tek bir sürümünün diskte açılmış halidir (28.1). Bir dalda çalışırken git checkout başka-dal dersen, Git klasördeki dosyaları o dalın anlık görüntüsüne çevirir (28.3). Yani bir klasör aynı anda yalnızca bir dalı gösterebilir. Şimdi senaryo: seri-ozelligi dalında yarım işin var, dosyalar karışık. Acil bir hata için puan-hatasi dalına geçmek istiyorsun. Üç seçenek var: yarım işi kaydet (kötü, yarım iş kaydedilmemeli), yarım işi geçici bir rafa kaldır (git stash; Pro Git'in ayrı bir konusu) ya da projeyi başka bir klasöre baştan klonla (disk ve zaman israfı, ayrıca iki ayrı depo).

Şimdi iki agent'ın aynı anda çalıştığını düşün: biri seriyi, öteki leaderboard'u yazıyor. Aynı klasörde çalışırlarsa birinin dosyaları ötekinin ayaklarının altında kayar; biri checkout yaptığında diğerinin dosyaları aniden değişir. Her biri kendi klasöründe çalışmalı. Ama iki ayrı klon yerine tek bir depo ve iki ayrı çalışma klasörü olabilir mi? Evet: git worktree.

Çalışma ağacı nedir

Resmî belgeye göre bir Git deposu birden çok çalışma ağacı (working tree, git worktree) destekleyebilir ve böylece birden fazla dalı aynı anda çıkarabilirsin. git worktree add ile depoya yeni bir çalışma ağacı bağlanır; bu ağaç, ve onu diğerlerinden ayıran üstveri birlikte "worktree" diye anılır.¹³ Depoda bir ana çalışma ağacı (git init ya da git clone'un hazırladığı) ve sıfır ya da daha fazla bağlı (linked) çalışma ağacı olur. Yeni bağlı ağaç, HEAD ve hazırlık alanı (index) gibi çalışma ağacına özgü dosyalar dışında her şeyi depoyla paylaşır.¹³

Bunu yeniden söyleyelim, çünkü kritik: commit geçmişi, dallar, etiketler, uzak depo ayarları: hepsi ortak, tek kopya. Ayrı olan: o klasörün dosyaları, HEAD'i ve hazırlık alanı. Yani her ağaç kendi "ben şu dalda, şu dosyalar açık, şu değişiklikleri hazırladım" durumunu taşır. Bir benzetme: bir kütüphanenin tek kataloğu (depo: geçmiş) ve birkaç okuma masası (çalışma ağaçları); herkes aynı kataloğa bakar, ama her masada farklı kitap açıktır.

Denemem: iki bağlı çalışma ağacı

$ git worktree add -b seri-ozelligi ../uygulama-seri
Preparing worktree (new branch 'seri-ozelligi')
HEAD is now at 3247184 Puan hesabı için TEMEL_PUAN sabitini ekle
$ git worktree add -b leaderboard ../uygulama-lb
Preparing worktree (new branch 'leaderboard')
HEAD is now at 3247184 Puan hesabı için TEMEL_PUAN sabitini ekle

$ git worktree list
.../gdemo/uygulama       3247184 [main]
.../gdemo/uygulama-lb    3247184 [leaderboard]
.../gdemo/uygulama-seri  3247184 [seri-ozelligi]

Satır satır: git worktree add -b seri-ozelligi ../uygulama-seri şunu söyler: "../uygulama-seri yolunda yeni bir klasör aç, seri-ozelligi adıyla yeni bir dal oluştur ve onu o klasörde çıkar." (-b yeni dal oluşturur; belgeye göre -b verilmezse, yeni ağaç yolun son bileşeni adlı yeni bir dalla ilişkilendirilir.¹³) list ise her ağacı, hangi commit'te olduğunu ve hangi dalı çıkardığını gösterir; ana ağaç ilk sırada. Klasörlerin yan yana durduğuna dikkat et: uygulama, uygulama-lb, uygulama-seri.

Şimdi seri klasöründe bir commit yaptım ve ana klasörden geçmişe baktım:

$ cd ../uygulama-seri
$ git add seri.js && git commit -m "Seri takibi için seriGuncelle fonksiyonunu ekle"
$ cd ../uygulama
$ git log --oneline --all --decorate --graph
* f5e08b8 (seri-ozelligi) Seri takibi için seriGuncelle fonksiyonunu ekle
* 3247184 (HEAD -> main, leaderboard) Puan hesabı için TEMEL_PUAN sabitini ekle
$ ls
puan.js

Seri klasöründe yapılan commit, ana klasörden de görünüyor, çünkü geçmiş ortak. Ama ls ana klasörde hâlâ yalnızca puan.js gösteriyor: seri.js yalnızca seri ağacının dosyası, ana ağacın dosyaları değişmedi. İşte ayrışma: tek geçmiş, ayrı çalışma klasörleri.

Bir de güvenlik kuralı: seri dalı başka bir ağaçta çıkarılmışken ana klasörden git checkout seri-ozelligi denedim ve Git reddetti:

$ git checkout seri-ozelligi
fatal: 'seri-ozelligi' is already used by worktree at '.../gdemo/uygulama-seri'

Belgeye göre de dal başka bir yerde çıkarılmışsa komut ağaç oluşturmayı reddeder (--force kullanılmadıkça).¹³ Bu, iki agent'ın yanlışlıkla aynı dala yazmasını önleyen bir emniyet: bir dal aynı anda yalnızca bir çalışma ağacında çıkarılabilir.

İş bitince ağacı temizlemek için:

$ git worktree remove ../uygulama-lb
$ git worktree list
.../gdemo/uygulama       3247184 [main]
.../gdemo/uygulama-seri  3247184 [seri-ozelligi]
$ git branch -a
  leaderboard
* main
+ seri-ozelligi

remove klasörü ve ağaç kaydını siler, ama dal (leaderboard) hâlâ duruyor: çünkü dal geçmişe aittir, klasöre değil. (branch -a çıktısındaki +, o dalın başka bir çalışma ağacında çıkarılı olduğunu gösterir.) Belgeye göre bir ağacı git worktree remove kullanmadan elle silersen, ilişkili yönetim dosyaları sonunda otomatik temizlenir ya da git worktree prune ile temizlersin.¹³ Bir ağaç kalıcı bir cihazda ya da her zaman bağlı olmayan bir yerdeyse git worktree lock onu silinmekten korur.¹³

Neden agent'larla çalışmanın temeli

1. Yalıtım. Her agent kendi klasöründe ve kendi dalında çalışır; birinin yarım kalmış, bozuk dosyaları ötekini etkilemez. 27. bölümdeki "kendi kapsamı olan modül" fikrinin klasör-dal düzeyindeki karşılığı.
2. Paralellik. Üç iş, üç klasör, aynı anda. Her biri bağımsız commit'ler üretir.
3. Ortak geçmiş. Her klonda ayrı ayrı bütün geçmişi tutmaya gerek yok; hepsi bir depoyu paylaşır. İş bitince dalları (28.3'teki gibi) birleştirirsin ya da çekme isteği olarak gönderirsin (28.5).
4. Tek dal kuralı. Aynı dalın iki ağaçta çıkarılamaması çakışmaları kaynağında keser.
5. Atılabilirlik. Bir agent yanlış yola saptıysa ağacı silersin (remove), dalı atarsın; ana klasörün hiçbir şeyden etkilenmez.

Belgenin kendi örneği de bu mantıkta: bir yeniden düzenleme oturumunun ortasındayken acil bir düzeltme gerekiyor; git stash ile işi rafa kaldırmak yerine, dağınık çalışma dizinine dokunmadan geçici bir bağlı ağaç açıp düzeltmeyi orada yaparsın, bitince ağacı silersin.¹³

28.7 .gitignore, sırlar (secrets) neden depoya girmez

İzlememek istediklerimiz

Her dosya geçmişe girmemeli. Pro Git'e göre sıklıkla Git'in otomatik olarak eklemesini ve hatta izlenmeyen dosya olarak göstermesini istemediğin bir dosya sınıfı olur: genellikle otomatik üretilen dosyalar, günlük (log) dosyaları ya da derleme sisteminin ürettiği dosyalar.³ Bunlar için, adı .gitignore olan ve eşleşme desenlerini listeleyen bir dosya yazılır. Bizim denemedeki dosya:

node_modules/
.env

Satır satır: node_modules/ (sondaki / bu desenin yalnızca klasörle eşleşeceğini söyler¹⁴) npm'in kuracağı paketlerin klasörüdür (Bölüm 29); bunları sen yazmadın, yeniden kurulabilir ve çok büyüktür; geçmişe girmemeli. .env ise ayarların ve sırların tutulduğu dosyadır; aşağıda anlatıyorum. Desen kuralları resmî belgedeki gibi: # ile başlayan satır yorumdur, * eğik çizgi dışında her şeyle eşleşir, başa / koyarsan desen .gitignore dosyasının bulunduğu klasöre göre yorumlanır, ! bir deseni tersine çevirir (önceden dışlanmış bir dosyayı yeniden dahil eder).¹⁴ Denememde .env dosyasını yarattığım halde git status onu listelemedi, çünkü .gitignore onu görünmez kıldı.

Önemli bir nüans, belgede yazıyor: Git'in zaten izlediği dosyalar .gitignore'dan etkilenmez; izlemeyi bırakmak için git rm --cached kullanılır.¹⁴ Yani .gitignore, "bunu hiç ekleme" demektir; "bunu geçmişten sil" demek değildir.

Sırlar neden depoya girmez

Sır (secret), bilinirse başkasının senin adına işlem yapmasına olanak veren gizli değerdir: parola, API anahtarı, veritabanı bağlantı şifresi, bir hizmete erişim jetonu. Bunları kodun içine ya da depoya koymamak güvenlik kuralı olmanın ötesinde, Git'in doğasından gelen bir zorunluluktur. Nedeni üç parçalı bir akıl yürütme:

1. Git neredeyse yalnızca veri ekler ve kaydedilmiş bir anlık görüntüyü kaybetmek zordur (28.2).²
2. Dağıtık sistemde depo klonlandığında bütün geçmiş kopyalanır (28.1). Her klon tam bir kopyadır.¹
3. Bu iki gerçeğin sonucu (benim çıkarımım, Pro Git'in cümlesi değil): bir sırrı bir kez commit edip sonra dosyadan silmek yetmez; sır eski commit'te durur ve her klonda, her dalda, geçmişe bakan herkesin erişiminde kalır. Çıkarılması ayrıca geçmişi yeniden yazmayı gerektirir ve yayınlanmış geçmişi yeniden yazmak ise 28.3'teki rebase uyarısının kapsamına girer.

Bu yüzden kural basit: sırlar daha ilk gün .gitignore'a yazılan bir dosyada ya da ortamda tutulur, depoya girmez; hangi ayarların gerektiğini göstermek için sır içermeyen bir örnek dosya (.env.example) girebilir. Sırların güvenliğini, .env dosyaları ve ortam değişkenleri gibi ayrıntılarıyla Bölüm 41'de ve yayına alırken sırların nasıl verildiğini Bölüm 43'te işleyeceğiz. Burada yalnızca refleksi kur: depoya girecek her şey, depoyu görecek herkesin görebileceği şeydir.

Bu bölümde neler kuruldu

Bir sürüm kontrol sistemi, dosyaların geçmişini tutar; Git dağıtıktır: her klon bütün geçmişi taşır. Dosyalar değiştirilmiş, hazırlanmış ve kaydedilmiş olmak üzere üç durumda bulunur; bunlara çalışma dizini, hazırlık alanı ve depo karşılık gelir. Commit bir fark değil, anlık görüntüdür; özet değerle adlanır; küçük ve tek amaçlı commit'ler incelemeyi, geri almayı ve agent denetimini kolaylaştırır; mesaj kısa ve emir kipindedir. Dal, bir commit'e işaret eden bir işaretçidir; HEAD hangi dalda olduğunu gösterir. İki dal birleştirilir (merge commit, çakışma işaretleri) ya da yeniden temellendirilir (paylaşılmış commit'lerde asla). Uzak depo (origin) ile clone, fetch, pull (= fetch + merge), push konuşulur; çatal ayrı bir depodur. Çekme isteği değişikliği inceleme ve tartışmayla birleştirme önerisidir; kod incelemesi üç karardan (comment, approve, request changes) birini verir. Çalışma ağacı tek depoda birden çok klasör ve dalı aynı anda yaşatır; geçmiş ortak, dosyalar, HEAD ve hazırlık alanı ayrıdır; bir dal aynı anda tek ağaçta çıkarılır. .gitignore izlenmeyecek dosyaları ve özellikle sırları dışarıda tutar. Terimler sözlükte, Bölüm 28 başlığı altında.

Kaynaklar

1. Scott Chacon ve Ben Straub, Pro Git, 1.1 About Version Control: kopya klasörler, yerel/merkezî/dağıtık sistemler, tek hata noktası, klonun tam yedek olması.
2. Pro Git, 1.3 What is Git?: anlık görüntüler ve farklar, yerel işlemler, bütünlük ve SHA-1, yalnızca veri ekleme, üç durum ve üç alan, temel iş akışı.
3. Pro Git, 2.2 Recording Changes to the Repository: git status, git add, git commit, .gitignore, master/main notu.
4. Pro Git, 3.1 Branches in a Nutshell: dal = işaretçi, HEAD, checkout, --decorate.
5. Pro Git, 3.2 Basic Branching and Merging: üç yollu birleştirme, birleştirme commit'i, çakışma işaretleri, çözüm.
6. Pro Git, 3.6 Rebasing: yeniden temellendirmenin işleyişi, doğrusal geçmiş, "paylaşılmış commit'leri yeniden temellendirme" kuralı.
7. Pro Git, 2.5 Working with Remotes: origin, fetch, pull, push.
8. Pro Git, 5.2 Contributing to a Project, "Commit Guidelines": mantıksal olarak ayrı değişiklik kümeleri, mesaj biçimi ve emir kipi.
9. Pro Git, 6.2 GitHub: Contributing to a Project: çatal (fork) tanımı.
10. GitHub Docs, About pull requests: öneri olarak çekme isteği, sekmeler, taslak.
11. GitHub Docs, About pull request reviews: Comment, Approve, Request changes.
12. GitHub Docs, About forks: çatal ve dal farkı, upstream.
13. Git belgeleri, git-worktree: ana ve bağlı çalışma ağacı, add, list, remove, prune, lock, paylaşılan ve ağaca özgü dosyalar, örnek, deneysellik notu.
14. Git belgeleri, gitignore: desen biçimi, izlenen dosyaların etkilenmemesi, git rm --cached.
15. Yazarın doğrudan denemesi: git 2.53.0 ile boş bir deneme deposunda init, add, commit, worktree add/list/remove ve çakışma. Bölümdeki komut çıktıları bu denemedendir (yalnızca dosya yolları kısaltıldı).