-
1. Başlangıç
- 1.1 Sürüm Denetimi
- 1.2 Git’in Kısa Tarihçesi
- 1.3 Git Nedir?
- 1.4 Komut Satırı
- 1.5 Git’i Yüklemek
- 1.6 Git’i İlk Defa Kurmak
- 1.7 Yardım Almak
- 1.8 Özet
-
2. Git Temelleri
-
3. Git Dalları
- 3.1 Dallar
- 3.2 Kısaca Dallandırma ve Birleştirme Temelleri
- 3.3 Dal Yönetimi
- 3.4 İş Akışı Dallandırması
- 3.5 Uzak Dallar
- 3.6 Yeniden Temelleme (rebase)
- 3.7 Özet
-
4. Bir Sunucuda Git Kurma
- 4.1 İletişim Kuralları (Protocols)
- 4.2 Bir Sunucuda Git Kurma
- 4.3 SSH Ortak Anahtarınızı Oluşturma
- 4.4 Sunucu Kurma
- 4.5 Git Cini (Daemon)
- 4.6 Akıllı HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Üçüncü Taraf Barındırma (Hosting) Seçenekleri
- 4.10 Özet
-
5. Dağıtık Git
- 5.1 Dağıtık İş Akışları
- 5.2 Projenin Gelişiminde Rol Almak
- 5.3 Bir Projeyi Yürütme
- 5.4 Özet
-
6. GitHub
- 6.1 Bir Projeye Katkıda Bulunmak
- 6.2 Proje Bakımı
- 6.3 Kurumsal Yönetim
- 6.4 GitHub’ı otomatikleştirme
- 6.5 Özet
-
7. Git Araçları
- 7.1 Düzeltme Seçimi
- 7.2 Etkileşimli İzlemleme (Staging)
- 7.3 Saklama ve Silme
- 7.4 Çalışmanızı İmzalama
- 7.5 Arama
- 7.6 Geçmişi Yeniden Yazma
- 7.7 Reset Komutunun Gizemleri
- 7.8 İleri Seviye Birleştirme
- 7.9 Rerere
- 7.10 Git’le Hata Ayıklama
- 7.11 Alt Modüller
- 7.12 Demetleme (Bundling)
- 7.13 Git Nesnesini Değiştirme
- 7.14 Kimlik Bilgisi Depolama
- 7.15 Özet
-
8. Git’i Özelleştirmek
- 8.1 Git Yapılandırması
- 8.2 Git Nitelikleri
- 8.3 Git Kancaları (Hooks)
- 8.4 Bir Örnek: Mecburi Git Politikası
- 8.5 Özet
-
9. Git ve Diğer Sistemler
- 9.1 İstemci Olarak Git
- 9.2 Git’e Geçiş
- 9.3 Özet
-
10. Dahili Git Ögeleri
- 10.1 Tesisat ve Döşeme (Plumbing ve Porcelain)
- 10.2 Git Nesneleri
- 10.3 Git Referansları
- 10.4 Packfiles
- 10.5 Refspec
- 10.6 Transfer Protokolleri
- 10.7 Bakım ve Veri Kurtarma
- 10.8 Ortam Değişkenleri
- 10.9 Özet
-
A1. Ek bölüm A: Diğer Ortamlarda Git
- A1.1 Görsel Arayüzler
- A1.2 Visual Studio ile Git
- A1.3 Visual Studio Code ile Git
- A1.4 Eclipse ile Git
- A1.5 Sublime Text ile Git
- A1.6 Bash ile Git
- A1.7 Zsh ile Git
- A1.8 PowerShell ile Git
- A1.9 Özet
-
A2. Ek bölüm B: Git’i Uygulamalarınıza Gömmek
- A2.1 Git Komut Satırı
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Ek bölüm C: Git Komutları
- A3.1 Kurulum ve Yapılandırma Komutları
- A3.2 Proje Oluşturma Komutları
- A3.3 Kısaca Poz (Snapshot) Alma
- A3.4 Dallandırma ve Birleştirme Komutları
- A3.5 Projeleri Paylaşma ve Güncelleme Komutları
- A3.6 İnceleme ve Karşılaştırma Komutları
- A3.7 Hata Ayıklama (Debugging) Komutları
- A3.8 Yamalama (Patching)
- A3.9 E-Posta Komutları
- A3.10 Harici Sistemler
- A3.11 Yönetim
- A3.12 Tesisat (Plumbing) Komutları
10.3 Dahili Git Ögeleri - Git Referansları
Git Referansları
Eğer, örneğin 1a410e
katkısından ulaşılabilen reposunuzun geçmişini görmek isterseniz, bu geçmişi görüntülemek için git log 1a410e
gibi bir şey çalıştırabilirsiniz, ancak yine de 1a410e
'nin bu geçmişin başlangıç noktası olarak kullanılacak katkı olduğunu hatırlamanız gerekecektir.
Bunun yerine, bu SHA-1 karmasını basit bir isimle saklayabileceğiniz bir dosyanız olsaydı, bu adı ham SHA-1 değeri yerine kullanabilirdiniz.
Git’te, bu basit adlar "referanslar" veya "refs" olarak adlandırılır.
Bu SHA-1 değerlerini içeren dosyaları .git/refs
dizininde bulabilirsiniz.
Mevcut projede, bu dizin hiç dosya içermiyor, ancak basit bir yapıya sahip:
$ find .git/refs
.git/refs
.git/refs/heads
.git/refs/tags
$ find .git/refs -type f
En son katkınızın nerede olduğunu hatırlamanıza yardımcı olacak yeni bir referans oluşturmak için teknik olarak şunu yapabilirsiniz:
$ echo 1a410efbd13591db07496601ebc7a059dd55cfe9 > .git/refs/heads/master
Şimdi, Git komutlarınızda SHA-1 değeri yerine oluşturduğunuz baş referansını kullanabilirsiniz:
$ git log --pretty=oneline master
1a410efbd13591db07496601ebc7a059dd55cfe9 third commit
cac0cab538b970a37ea1e769cbbde608743bc96d second commit
fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit
Referans dosyalarını doğrudan düzenlemeniz önerilmez; bunun yerine, bir referansı güncellemek isterseniz, Git size bunu yapmak için daha güvenli olan git update-ref
komutunu sağlar:
$ git update-ref refs/heads/master 1a410efbd13591db07496601ebc7a059dd55cfe9
Bir Git dalı, aslında sadece bir iş hattının başını gösteren bir işaretçi veya referanstır. İkinci katkıya bir dal oluşturmak için şunu yapabilirsiniz:
$ git update-ref refs/heads/test cac0ca
Dalınız sadece o katkıdan aşağıdaki işi içerecektir:
$ git log --pretty=oneline test
cac0cab538b970a37ea1e769cbbde608743bc96d second commit
fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit
Şimdi, Git veritabanınız kavramsal olarak şuna benziyor:
git branch <dal>
gibi komutları çalıştırdığınızda, Git update-ref
komutunu çalıştırarak, üzerinde bulunduğunuz dalın son katkısının SHA-1’ini istediğiniz yeni referansa ekler.
HEAD (baş/uç)
Şimdi, git branch <dal>
komutunu çalıştırdığınızda, Git son katkının SHA-1’ini nasıl bilir?
Cevap HEAD dosyasındır.
Genellikle HEAD dosyası, üzerinde bulunduğunuz dalın sembolik bir referansıdır. Sembolik referans olarak, normal bir referansın aksine, başka bir referansa dönük bir işaretçi içerir.
Ancak bazı nadir durumlarda HEAD dosyası, bir git nesnesinin SHA-1 değerini içerebilir. Bu durum, bir etiket, katkı veya uzak dalı checkout ettiğinizde, reponuzu "bağlantısız HEAD" durumuna sokar.
Dosyaya baktığınızda, genellikle şöyle bir şey görürsünüz:
$ cat .git/HEAD
ref: refs/heads/master
git checkout test
komutunu çalıştırırsanız, Git dosyayı şuna benzer bir şekilde günceller:
$ cat .git/HEAD
ref: refs/heads/test
git commit
komutu katkı nesnesini oluştururken; HEAD’deki referansın işaret ettiği SHA-1 değerini, o katkı nesnesinin önceli olarak belirtir.
Bu dosyayı manuel olarak da düzenleyebilirsiniz, ancak yine de bunu yapmanın daha güvenli bir yolu vardır: git symbolic-ref
.
Bu komutla HEAD’in değerini okuyabilirsiniz:
$ git symbolic-ref HEAD
refs/heads/master
Aynı komutu kullanarak HEAD’in değerini de ayarlayabilirsiniz:
$ git symbolic-ref HEAD refs/heads/test
$ cat .git/HEAD
ref: refs/heads/test
Sembolik bir referansı refs stilinin dışında ayarlayamazsınız:
$ git symbolic-ref HEAD test
fatal: Refusing to point HEAD outside of refs/
Etiketler (Tag)
Git’in üç ana nesne türünü (blob, ağaç (tree) ve katkı (commit)) inceledik, ancak bir dördüncüsü vardır. Etiket (tag) nesnesi, bir katkı nesnesine çok benzeyen bir yapıya sahiptir: bir etiketleyici, bir tarih, bir ileti ve bir işaretçi içerir. Temel fark, bir etiket nesnesinin genellikle bir ağaca değil, bir katkıya işaret etmesidir. Bu bir dal referansına benzer, ancak asla hareket etmez: her zaman aynı katkıya işaret eder, ancak ona daha dostane bir ad verir.
Git Temelleri bölümünde anlatıldığı gibi, iki tür etiket vardır: anotasyonlu (annotated) ve hafif. Hafif bir etiket oluşturmak için şunu çalıştırabilirsiniz:
$ git update-ref refs/tags/v1.0 cac0cab538b970a37ea1e769cbbde608743bc96d
Bu asla hareket etmeyen bir referansa sahip hafif bir etikettir.
Ancak, anotasyonlu bir etiket daha karmaşıktır.
Eğer anotasyonlu bir etiket oluşturursanız, Git bir etiket nesnesi oluşturur; ve ardından doğrudan katkı yerine bu etikete işaret eden bir referans yazar.
Bunu (-a
seçeneğiyle) anotasyonlu bir etiket oluşturarak görebilirsiniz :
$ git tag -a v1.1 1a410efbd13591db07496601ebc7a059dd55cfe9 -m 'test tag'
İşte oluşturduğu nesnenin SHA-1 değeri:
$ cat .git/refs/tags/v1.1
9585191f37f7b0fb9444f35a9bf50de191beadc2
Şimdi, bu SHA-1 değeri üzerinde git cat-file -p
komutunu çalıştırın:
$ git cat-file -p 9585191f37f7b0fb9444f35a9bf50de191beadc2
object 1a410efbd13591db07496601ebc7a059dd55cfe9
type commit
tag v1.1
tagger Scott Chacon <schacon@gmail.com> Sat May 23 16:48:58 2009 -0700
test tag
Nesne girişinin etiketlediğiniz SHA-1 katkı değerini işaret ettiğine dikkat edin. Ayrıca bir katkıya işaret etmesi gerekmediğine de dikkat edin; herhangi bir Git nesnesini etiketleyebilirsiniz. Örneğin Git kaynak kodunda, bakımcı GPG ortak anahtarını bir blob nesnesi olarak ekledi ve ardından onu etiketledi. Bunu Git reposunun bir kopyasında çalıştırarak ortak anahtarı görüntüleyebilirsiniz:
$ git cat-file blob junio-gpg-pub
Linux çekirdeği reposunda aynı zamanda katkı dışı işaret eden bir etiket nesnesi bulunur: kaynak kodun içe aktarımının ilk ağacını işaret eden, oluşturulmuş ilk etiket.
Uzaklar
Göreceğiniz üçüncü referans türü uzak referanstır.
Origin’a bir uzak repo ekler ve bu repoya iterseniz, Git her dal için bu repoya en son neyi ittiğinizi refs/remotes
dizininde saklar.
Örneğin, origin
adında bir uzak repo ekleyebilir ve master
dalını ona itebilirsiniz:
$ git remote add origin git@github.com:schacon/simplegit-progit.git
$ git push origin master
Counting objects: 11, done.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (7/7), 716 bytes, done.
Total 7 (delta 2), reused 4 (delta 1)
To git@github.com:schacon/simplegit-progit.git
a11bef0..ca82a6d master -> master
O zaman, sunucuyla en son iletişim kurduğunuz zaman origin
uzak reposundaki master
dalının ne olduğunu kontrol etmek için refs/remotes/origin/master
dosyasına bakabilirsiniz:
$ cat .git/refs/remotes/origin/master
ca82a6dff817ec66f44342007202690a93763949
Uzak referanslar (refs/remotes
referansları), dallarla (refs/heads
referansları) karşılaştırıldığında, genellikle salt okunur olarak kabul edilir.
git checkout
komutuyla buraya geçebilirsiniz, ancak Git onu HEAD ile işaretlemeyecektir; bu yüzden commit
komutuyla asla güncellenmezler.
Git bunları, bu sunuculardaki dalların en son bilinen durumuna işaret eden yer işaretleri olarak yönetir.