-
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ı
7.1 Git Araçları - Düzeltme Seçimi
Şimdiye kadar, kaynak kod kontrolü için bir Git reposunu yönetmek veya sürdürmek için ihtiyacınız olan günlük komutları ve iş akışlarının çoğunu öğrendiniz. Dosyaları izleme ve katkılama gibi temel görevleri başardınız ve ayrıca konu dalları oluşturma ve birleştirme gücünü de kullandınız.
Şimdi, günlük olarak kullanmasanız da, bir noktada ihtiyacınız olabilecek çok güçlü şeyleri keşfedeceksiniz.
Düzeltme Seçimi
Git, bir veya birkaç katkı veya katkı aralığına birkaç şekilde atıfta bulunmanızı sağlar. Bunlar her zaman açık olmayabilir, ancak bilmeniz faydalı olabilir.
Tekli Düzeltmeler
Herhangi tek bir katkıyı 40 karakterlik tam bir SHA-1 karmasıyla (hash) gösterebilirsiniz, ancak katkıları daha insan dostu yollarla da belirtebilirsiniz. Bu bölüm, herhangi bir katkıyı belirtmek için kullanabileceğiniz çeşitli yolları açıklar.
Kısa SHA-1
Bir katkıyı belirtmek için SHA-1 karmasının ilk birkaç karakterini yazarsanız, yazdığınız karma en az dört karakter uzunluğunda ve belirsiz olmadığı sürece, Git hangi katkıya atıfta bulunduğunuzu anlayacak kadar akıllıdır. Başka bir deyişle, nesne veritabanında aynı önek ile başlayan başka bir nesne olmadığı müddetçe sorun yaşamazsınız.
Örneğin, belirli bir işlev eklediğinizi bildiğiniz bir katkıyı incelemek için, ilk önce git log
komutunu çalıştırarak o katkıyı bulabilirsiniz:
$ git log
commit 734713bc047d87bf7eac9674765ae793478c50d3
Author: Scott Chacon <schacon@gmail.com>
Date: Fri Jan 2 18:32:33 2009 -0800
fixed refs handling, added gc auto, updated tests
commit d921970aadf03b3cf0e71becdaab3147ba71cdef
Merge: 1c002dd... 35cfb2b...
Author: Scott Chacon <schacon@gmail.com>
Date: Thu Dec 11 15:08:43 2008 -0800
Merge commit 'phedders/rdocs'
commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b
Author: Scott Chacon <schacon@gmail.com>
Date: Thu Dec 11 14:58:32 2008 -0800
added some blame and merge stuff
Diyelim ki, SHA-1 özetinin 1c002dd...
ile başladığı bir katkıyla ilgileniyorsunuz.
Bu katkıyı incelemek için aşağıdaki git show
çeşitlemelerinden herhangi birini kullanabilirsiniz (kısa versiyonların belirsiz olmadığı varsayılmaktadır):
$ git show 1c002dd4b536e7479fe34593e72e6c6c1819e53b
$ git show 1c002dd4b536e7479f
$ git show 1c002d
Git, SHA-1 değerleriniz için kısa, benzersiz bir kısaltma bulabilir.
git log
komutuna --abbrev-commit
seçeneğini eklerseniz, çıktı daha kısa değerler kullanacak ancak bunları benzersiz tutacaktır; SHA-1’in belirsiz olmaması (benzersiz olması) için, varsayılan olarak yedi karakter kullanır ancak bu onu daha uzun hale getirir:
$ git log --abbrev-commit --pretty=oneline
ca82a6d changed the version number
085bb3b removed unnecessary test code
a11bef0 first commit
Genellikle, bir projenin içinde benzersiz olması için sekiz ila on karakter yeterlidir. Örneğin, - Şubat 2019 itibarıyla 875.000’den fazla katkı ve neredeyse yedi milyon nesne içeren - oldukça büyük bir proje olan Linux çekirdeğinde, SHA-1’leri ilk 12 karakteri aynı olan hiçbir nesne bulunmuyor.
Not
|
SHA-1 HAKKINDA KISA BİR NOT
Birçok insan, rastgele bir olay sonucu, repolarında birbirinden farklı iki nesnenin aynı SHA-1 değerine sahip olabileceğinden endişelenir. Peki sonra ne olur? Eğer repoya daha önceden işlenmiş farklı bir nesnenin SHA-1 değerine sahip yeni bir nesne eklerseniz, Git önceki nesneyi zaten Git veritabanınızda görecek, bu nesnenin zaten yazıldığını varsayacak ve onu yeniden kullanacaktır. Bir noktada o nesneye geçmeye çalışırsanız, her zaman ilk nesnenin verisini alacaksınız. Ancak, bu senaryonun gerçekleşme ihtimalinin, imkansıza yakın derecede olanaksız olduğunun farkında olmalısınız.
SHA-1 özeti 20 bayt veya 160 bit’tir.
Bu eşleşme olasılığının %50 olması için gerekli rastgele özetlenmiş nesne sayısı yaklaşık 2^80 (2 üzeri 80) civarındadır
(çarpışma olasılığını belirleme formülü İşte bir SHA-1 çarpışmasını elde etmek için gerekenleri anlamanıza yardımcı olacak bir başka örnek: Dünyadaki 6,5 milyar insanın hepsi programlama yapıyor olsaydı ve bunların her biri, Linux çekirdeğine saniyede bir katkı işleyip (saniyede 6,5 milyon Git nesnesi) bunları devasa bir Git reposuna itseydi; bu repoda bir tek SHA-1 nesnesinin çarpışma olasılığının %50 olması, yaklaşık 2 yıl sürerdi. Bu nedenle, bir SHA-1 çarpışmasının gerçekleşme ihtimali, programlama ekibinizin tüm üyelerinin, aynı gece, farklı yerlerde, farklı şeylerle ilgilenirken, aniden kurtlar tarafından saldırıya uğraması ve öldürülmesinden daha düşüktür. |
Dal Referansları
Belirli bir katkıya başvurmanın basit bir yolu, o dalın uç noktasındaki bir katkı olduğunda; bu durumda, bir katkı başvurusunu bekleyen herhangi bir Git komutunda sadece dal adını kullanabilirsiniz.
Örneğin, bir daldaki son katkı nesnesini incelemek istiyorsanız, topic1
dalının ca82a6d...
katkısına işaret ettiğini varsayarsak, aşağıdaki komutlar eşdeğerdir:
$ git show ca82a6dff817ec66f44342007202690a93763949
$ git show topic1
Bir dalın hangi SHA-1’e işaret ettiğini görmek istiyorsanız veya bu örneklerden herhangi birinin SHA-1’ler açısından neye denk geldiğini görmek istiyorsanız, rev-parse
adlı bir Git aracını kullanabilirsiniz.
Daha fazla bilgi için Dahili Git Ögeleri adresine bakabilirsiniz; temelde, rev-parse
daha düşük düzeyli işlemler için var ve günlük işlemlerde kullanılmak üzere tasarlanmamıştır.
Ancak, bazen gerçekte ne olduğunu görmek gerektiğinde yardımcı olabilir.
Burada dalınız üzerinde rev-parse
çalıştırabilirsiniz.
$ git rev-parse topic1
ca82a6dff817ec66f44342007202690a93763949
Referans Günlüğü (Reflog) Kısa Adları
Git’in arka planda çalışırken yaptığı şeylerden biri, "reflog" olarak adlandırılan, HEAD ve dal referanslarınızın son birkaç ay boyunca nerede olduğunu kaydettiği bir günlük tutmaktır.
Referans günlügünüzü git reflog
komutunu kullanarak görebilirsiniz:
$ git reflog
734713b HEAD@{0}: commit: fixed refs handling, added gc auto, updated
d921970 HEAD@{1}: merge phedders/rdocs: Merge made by the 'recursive' strategy.
1c002dd HEAD@{2}: commit: added some blame and merge stuff
1c36188 HEAD@{3}: rebase -i (squash): updating HEAD
95df984 HEAD@{4}: commit: # This is a combination of two commits.
1c36188 HEAD@{5}: rebase -i (squash): updating HEAD
7e05da5 HEAD@{6}: rebase -i (pick): updating HEAD
Herhangi bir nedenle dal ucu güncellendiğinde, Git bu bilgiyi geçici bir geçmişte sizin için saklar.
Reflog verilerinizi eski katkılara başvurmak için de kullanabilirsiniz.
Örneğin, repo ucunuzun beş önceki değerini görmek istiyorsanız, reflog çıktısında gördüğünüz @{5}
referansını kullanabilirsiniz:
$ git show HEAD@{5}
Bu sözdizimini ayrıca bir dalın belirli bir süre önce nerede olduğunu görmek için de kullanabilirsiniz.
Örneğin, master
dalınızın dün nerede olduğunu görmek için şunu yazabilirsiniz:
$ git show master@{yesterday}
Bu, master
dalınızın ucunun dün nerede olduğunu gösterir.
Bu teknik, hala referans günlüğünüzde olan veriler için çalışır, bu nedenle birkaç aydan daha eski katkıları aramak için kullanamazsınız.
git log
çıktısı gibi biçimlendirilmiş referans günlüğü bilgilerini görmek için git log -g
komutunu çalıştırabilirsiniz:
$ git log -g master
commit 734713bc047d87bf7eac9674765ae793478c50d3
Reflog: master@{0} (Scott Chacon <schacon@gmail.com>)
Reflog message: commit: fixed refs handling, added gc auto, updated
Author: Scott Chacon <schacon@gmail.com>
Date: Fri Jan 2 18:32:33 2009 -0800
fixed refs handling, added gc auto, updated tests
commit d921970aadf03b3cf0e71becdaab3147ba71cdef
Reflog: master@{1} (Scott Chacon <schacon@gmail.com>)
Reflog message: merge phedders/rdocs: Merge made by recursive.
Author: Scott Chacon <schacon@gmail.com>
Date: Thu Dec 11 15:08:43 2008 -0800
Merge commit 'phedders/rdocs'
Reflog bilgilerinin kesinlikle yerel olduğunu bilmelisinizi - yalnızca sizin kendi reponuzda yaptığınız işlemlerin günlüğüdür.
Referanslar, başkasının repo kopyasında aynı olmayacaktır; ayrıca bir repoyu başlangıçta klonladıktan hemen sonra, henüz repoda herhangi bir etkinlik olmadığından boş bir referans günlüğünüz olacaktır.
git show HEAD@{2.months.ago}
komutunu çalıştırmak; eğer projeyi en az iki ay önce kopyaladıysanız, yalnızca eşleşen katkıyı gösterecektir; eğer bundan daha yeni bir tarihte kopyaladıysanız, yalnızca ilk yerel katkınızı göreceksiniz.
İpucu
|
Reflog’u Git’in kabuk (shell) geçmişi versiyonu olarak düşünebilirsiniz.
UNIX veya Linux geçmişiniz varsa, reflog’u Git’in kabuk geçmişinin versiyonu olarak düşünebilirsiniz. Bu, oradaki şeylerin sadece "sizle" ve "oturumunuzla" için açıkça ilgili olduğunu vurgular ve aynı makinede çalışan başka birinin bununla ilgisi olmadığını belirtir. |
Soy Referansları
Başka bir katkıyı belirtmenin ana yolu, onun kökenidir.
Bir referansın sonuna bir ^
(caret) işareti koyarsanız, bunun Git’te temsil ettiği şey, o katkının öncelidir.
Projenizin geçmişine bir göz atarsanız:
$ git log --pretty=format:'%h %s' --graph
* 734713b fixed refs handling, added gc auto, updated tests
* d921970 Merge commit 'phedders/rdocs'
|\
| * 35cfb2b Some rdoc changes
* | 1c002dd added some blame and merge stuff
|/
* 1c36188 ignore *.gem
* 9b29157 add open3_detach to gemspec file list
Ardından, HEAD^
belirterek önceki katkıyı görebilirsiniz, bu da "HEAD’in önceli" anlamına gelir:
$ git show HEAD^
commit d921970aadf03b3cf0e71becdaab3147ba71cdef
Merge: 1c002dd... 35cfb2b...
Author: Scott Chacon <schacon@gmail.com>
Date: Thu Dec 11 15:08:43 2008 -0800
Merge commit 'phedders/rdocs'
Not
|
Windows’ta caret işaretinden kaçınmak
Windows’ta
|
Kaçıncı önceli istediğinizi belirtmek için ^
karakterinin hemen ardından bir sayı belirtebilirsiniz: örneğin, d921970^2
, "d921970’nin ikinci önceli" anlamına gelir.
Bu sözdizimi, birden fazla önceli olan birleştirme katkıları için yararlıdır: bir birleştirme katkısının ilk önceli, birleştirdiğinizde üzerinde bulunduğunuz dalın (genellikle master
) olduğu dal, bir birleştirme katkısının ikinci önceli ise birleştirilen dalın (örneğin, topic
) olduğu daldır:
$ git show d921970^
commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b
Author: Scott Chacon <schacon@gmail.com>
Date: Thu Dec 11 14:58:32 2008 -0800
added some blame and merge stuff
$ git show d921970^2
commit 35cfb2b795a55793d7cc56a6cc2060b4bb732548
Author: Paul Hedderly <paul+git@mjr.org>
Date: Wed Dec 10 22:22:03 2008 +0000
Some rdoc changes
Diğer ana soy belirteci de ~
(tilde) karakteridir.
Bu da ilk öncele atıfta bulunur, bu yüzden HEAD~
ve HEAD^
eşdeğerdir.
Fark, bir sayı belirttiğinizde ortaya çıkar.
HEAD~2
, "ilk öncelin önceli" veya "ikinci öncel" anlamına gelir - belirttiğiniz sayı kadar birinci önceli geçer.
Örneğin, önceki listede, HEAD~3
şöyle olurdu:
$ git show HEAD~3
commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d
Author: Tom Preston-Werner <tom@mojombo.com>
Date: Fri Nov 7 13:47:59 2008 -0500
ignore *.gem
Bu, HEAD~~~
olarak da yazılabilir, yani yine ilk öncelin ilk öncelidir.
$ git show HEAD~~~
commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d
Author: Tom Preston-Werner <tom@mojombo.com>
Date: Fri Nov 7 13:47:59 2008 -0500
ignore *.gem
Bu sözdizimlerini birleştirebilirsiniz: (bir birleştirme katkısı olduğunu varsayarsak) önceki referansın ikinci önceline HEAD~3^2
kullanarak ulaşabilirsiniz, vs.
Katkı Aralığı
Şimdi tek tek katkıları belirtebildiğimize göre, katkı aralıklarını nasıl belirleyeceğimizi görelim. Özellikle dallarınızı yönetmek için oldukça kullanışlı bir yöntemdir: eğer birçok dalınız varsa, aralık belirlemelerini kullanarak "Bu dalda, henüz ana dalıma birleştirmediğim hangi işler var?" gibi soruları yanıtlayabilirsiniz.
İki Nokta (..)
Aralık belirtmekte kullanılan en yaygın sözdizimi "çift nokta"dır. Temel olarak Git’ten, bir katkıdan erişilebilen ancak diğerinden erişilemeyen bir katkı aralığını çözmesini istemektir. Örneğin, Aralık seçimi için örnek bir geçmiş. gibi bir katkı geçmiğiniz olsun:
Diyelim ki experiment
dalınızdan master
dalınıza henüz birleştirilmemiş olan değişiklikleri görmek istiyorsunuz.
Git’ten, master
'dan erişilemeyen ancak experiment
'ten erişilebilen tüm katkıların bir günlüğünü göstermesini isteyebilirsiniz; yani "experiment dalından erişilebilen ancak master dalından erişilemeyen tüm katkılar".
Bu örneklerde kısaltma ve açıklık için, diyagramdaki katkı nesnelerinin harfleri gerçek günlük çıktısı yerine kullanılmıştır ve gösterilecek sırayla kullanılmıştır:
$ git log master..experiment
D
C
Öte yandan, tam tersini görmek istiyorsanız; yani experiment
'te olmayan tüm katkıları master
'da görmek istiyorsanız, dal isimlerini ters çevirebilirsiniz.
experiment..master
, experiment
'ten erişilemeyen her şeyi master
'da size gösterir:
$ git log experiment..master
F
E
Bu, experiment
dalını güncel tutmak ve birleştirmek üzere olduğunuz şeyi önizlemek istiyorsanız kullanışlıdır.
Bu sözdiziminin sık kullanılan bir başka kullanımı da, uzak bir repoya neyi iteceğinizi görmektir:
$ git log origin/master..HEAD
Bu komut size, mevcut dalınızda olup, origin
uzak reposu master
dalında olmayan tüm katkıları gösterir.
Bir git push
çalıştırırsanız ve mevcut dalınız origin/master
'ı takip ediyorsa, git log origin/master..HEAD
tarafından listelenen katkılar, sunucuya aktarılacak olan katkılardır.
Ayrıca, sözdiziminin bir tarafını bırakarak Git’in HEAD
'i varsaymasını sağlayabilirsiniz.
Örneğin, git log origin/master..
yazarak önceki örnekteki aynı sonuçları alabilirsiniz; bir taraf eksikse, Git HEAD
'i otomatik olarak eksik kısmın yerine koyar.
Çoklu Noktalar
İki dalı belirtmek için "çift nokta" sözdizimi kullanışlı olabilir, ancak belki de mevcut daldan farklı olan birkaç dalı belirtmek istersiniz: örneğin, şu anda bulunduğunuz dalda olmayan birkaç dalda hangi katkıların olduğunu görmek gibi.
Git, erişilebilir katkıları görmek istemediğiniz herhangi bir referansın önüne ^
karakterini veya --not
kullanarak bunu yapmanıza izin verir.
Bu nedenle, aşağıdaki üç komut eşdeğerdir:
$ git log refA..refB
$ git log ^refA refB
$ git log refB --not refA
Bunun güzelliği, bu sözdizimi ile sorgunuzda iki referanstan fazlasını belirtebilmenizdedir - bu çift nokta sözdizimi ile yapamadığınız bir şeydir.
Örneğin, refA
veya refB
'den erişilebilen ancak refC
'den erişilemeyen tüm katkıları görmek istiyorsanız, aşağıdaki komutlardan herhangi birini kullanabilirsiniz:
$ git log refA refB ^refC
$ git log refA refB --not refC
Bu, dallarınızdaki içeriği belirlemenize yardımcı olacak oldukça güçlü bir revizyon sorgu sistemi oluşturur.
Üçlü Nokta (…)
Son büyük aralık seçimi sözdizimi üç noktalı yazımdır (…), bu da iki referansın herhangi biri tarafından erişilebilen ancak her ikisinden erişilemeyen tüm katkıları belirtir.
Aralık seçimi için örnek bir geçmiş. örneği katkı geçmişine geri dönün.
master
veya experiment
'te bulunan ancak ortak referanslardan herhangi birinde bulunmayan katkıları görmek istiyorsanız şunu çalıştırabilirsiniz:
$ git log master...experiment
F
E
D
C
Bu size yine normal log
çıktısı verir, ancak sadece bu dört katkı için, geleneksel katkı tarihi sıralamasında görünür.
Bu durumda log
komutu ile kullanılan yaygın bir anahtar değişimi --left-right
'dır: bu size her katkının, aralığın hangi tarafında olduğunu gösterir.
Bu da, çıktıyı daha kullanışlı hale getirir:
$ git log --left-right master...experiment
< F
< E
> D
> C
Bu araçlarla, Git’e incelemek istediğiniz katkı veya katkıları belirtmeniz çok daha kolay olur.