-
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ı
8.3 Git’i Özelleştirmek - Git Kancaları (Hooks)
Git Kancaları (Hooks)
Diğer Birçok Versiyon Kontrol Sistemi gibi, Git’in belirli önemli eylemler gerçekleştiğinde özel komut betiklerini tetikleme yöntemi vardır. Bu kancalar iki gruba ayrılır: istemci tarafı ve sunucu tarafı. İstemci tarafı kancaları, katkılama veya birleştirme gibi işlemlerle tetiklenirken; sunucu tarafı kancaları, itilen katkıları alma gibi ağ işlemlerinde çalışır. Bu kancaları her türlü amaç için kullanabilirsiniz.
Kanca Kurma
Kancalar, Git dizininin hooks
alt dizininde saklanır.
Çoğu projede bu .git/hooks
yoludur.
git init
komutu ile yeni bir repo başlattığınızda, Git kancalar dizinini bir sürü örnek komut dosyasıyla doldurur. Bunların çoğu kendi başlarına kullanışlı olmakla birlikte, her bir komut dosyasının girdi değerlerini belgeledikleri için de yararlıdırlar.
Tüm örnekler, içine biraz Perl serpiştirilmiş shell komut dosyaları olarak yazılmıştır, ancak uygun şekilde adlandırılmış yürütülebilir haldeki tüm komut dosyaları sorunsuz şekilde çalışacaktır (onları Ruby veya Python veya aşina olduğunuz başka bir dilde yazabilirsiniz).
Birleştirilmiş kancaları kullanmak istiyorsanız, onları yeniden adlandırmanız gerekecektir (tüm dosya adları .sample
ile biter).
Bir kancayı etkinleştirmek için, .git
dizininin altındaki hooks
alt dizinine uygun şekilde (herhangi bir dosya uzantısı olmadan) adlandırılmış ve yürütülebilir bir dosya koyun.
Ve artık, çağrılabiliyor olması lazım.
Burada önemli kancaların çoğuna değineceğiz.
İstemci-Tarafı Kancaları
Çok sayıda istemci tarafı kancası bulunmaktadır. Bu bölüm, katkı iş akışı kancalarını, e-posta iş akışı betiklerini ve diğer her şeyi ayırır.
Not
|
Önemli bir not olarak, istemci tarafı kancalarının bir repoyu klonladığınızda kopyalanmadığını bilmek çok önemlidir. Eğer bu betiklerle bir politika uygulamak gibi bir amacınız varsa, muhtemelen bunu sunucu tarafında yapmak isteyeceksiniz. Bunun için Bir Örnek: Mecburi Git Politikası bölümündeki örneğe bakın. |
Katkı-İşakışı Kancaları
İlk dört kancanın hepsi katkı süreci ile ilgilidir.
pre-commit
kancası siz daha katkı mesajını bile yazmadan önce çalıştırılır.
Yapılacak olan katkıyı incelemek, bir şey unutup unutmadığınızı görmek, testlerin çalıştırılıp çalıştırılmadığını kontrol etmek veya kod içinde incelemek istediğiniz herhangi bir şeyi kontrol etmek için kullanılır.
Bu kancadan sıfırsız (non-zero) çıkış yapmak katkıyı iptal eder, ancak git commit --no-verify
ile bunu atlayabilirsiniz.
Bununla, kod stili kontrol etmek (lint veya bir benzerini çalıştırmak), sondaki boşlukları kontrol etmek (varsayılan kanca tam olarak bunu yapar) veya yeni metodlarda uygun belgelendirmenin olup olmadığını kontrol etmek gibi şeyler yapabilirsiniz.
prepare-commit-msg
kancası, katkı mesajı düzenleyici başlatılmadan önce, ancak varsayılan mesaj oluşturulduktan sonra çalıştırılır.
Katkı yazarı mesajı görmeden önce varsayılan mesajı düzenlemenize izin verir.
Bu kancanın birkaç parametresi vardır: şimdiye kadar katkı mesajını tutan dosyanın yolu, katkının türü ve eğer bu düzeltilmiş bir katkıysa katkı SHA-1’i gibi.
Bu kanca genellikle normal katkılar için kullanışlı değildir; bunun yerine, varsayılan mesajın otomatik olarak oluşturulduğu katkılarda, örneğin şablonlu katkı mesajları, birleştirme katkıları, sıkıştırılmış katkılar ve düzeltilmiş katkılarda iyidir.
Programlı olarak bilgi eklemek için bunu bir katkı şablonuyla birlikte kullanabilirsiniz.
commit-msg
kancası, yine geliştirici tarafından yazılan katkı mesajını içeren geçici bir dosyanın yolunu içeren bir parametre alır.
Bu betik sıfırsız olarak çıkarsa, Git katkı sürecini iptal eder. Bunu bir katkının gerçekleşmesine izin vermeden önce, proje durumunuzu veya katkı mesajınızı doğrulamak için kullanabilirsiniz.
Bu bölümün sonunda, bu kancayı katkı mesajınızın gerekli bir modelle uyumlu olup olmadığını kontrol etmek için nasıl kullanacağımızı göstereceğiz.
Tüm katkı süreci tamamlandıktan sonra, post-commit
kancası çalışır.
Bu, herhangi bir parametre almaz, ancak git log -1 HEAD
komutunu çalıştırarak en son katkıyı kolayca alabilirsiniz.
Genellikle, bu betik bildirim veya benzeri bir şey için kullanılır.
E-posta İş-akışı Kancası
E-posta tabanlı bir iş akışı için üç istemci tarafı kancası kurabilirsiniz.
Hepsi git am
komutu tarafından çağrılır, bu yüzden iş akışınızda bu komutu kullanmıyorsanız, güvenle bir sonraki bölüme geçebilirsiniz.
E-posta aracılığıyla hazırlanan git format-patch
ile yama alıyorsanız, bunlardan bazıları size yardımcı olabilir.
Çalıştırılan ilk kanca `applypatch-msg`dir. Tek bir argüman alır: önerilen katkı mesajını içeren geçici dosyanın adı. Bu betik sıfırsız olarak çıkarsa, Git yamayı iptal eder. Bunu, bir katkı mesajının düzgün biçimlendirilmiş olup olmadığını veya betiği yerinde düzenleyerek mesajı normalleştirmek için kullanabilirsiniz.
pre-applypatch
kancası git am
ile yamaları uygularken çalıştırılan bir sonraki kancadır.
Biraz kafa karıştırıcı bir şekilde, yama uygulandıktan sonra ancak bir katkı yapılmadan önce çalışır. Bu nedenle katkı işlemeden önce görüntüyü incelemek için kullanılabilir.
Bu betikle çalışma ağacını test edebilir veya başka şekilde inceleyebilirsiniz.
Eğer bir şey eksikse veya testler geçmezse, sıfırsız (non-zero) çıkış yaparak git am
betiğini katkı işlemeden durdurabilirsiniz.
post-applypatch
bir git am
işlemi sırasında çalıştırılan son kancadır , katkı işlendikten sonra çalışır.
Bunu, içine çektiğiniz yamayı oluşturan grubu veya yazarı bildirmek için kullanabilirsiniz.
Bu betikle yama işlemini durduramazsınız.
Diğer İstemci Kancaları
pre-rebase
kancası, herhangi bir şeyi yeniden temellemeden (rebase) önce çalışır ve sıfırsız (non-zero) çıkış yaparak işlemi durdurabilir.
Bu kancayı kullanarak zaten itilmiş olan herhangi bir katkının yeniden temellenmesini engelleyebilirsiniz.
Git’in kurduğu örnek pre-rebase
kancası bunu yapar, ancak iş akışınızla eşleşmeyebilecek bazı varsayımlarda bulunur.
post-rewrite
kancası, git commit --amend
ve git rebase
gibi katkıları değiştiren komutlar tarafından çalıştırılır (ancak git filter-branch
tarafından değil).
Tek bir argümanı, yeniden yazmayı tetikleyen komutu alır ve stdin
üzerinden yeniden yazılara bir liste alır.
Bu kancanın post-checkout
ve post-merge
kancalarıyla aynı kullanımları vardır.
post-checkout
kancası başarılı bir git checkout
işleminden sonra çalışır; projenizin ortamı için çalışma dizinini uygun şekilde ayarlamak için kullanabilirsiniz.
Kaynak kontrol edilmemesini istediğiniz büyük ikilik dosyaları taşımak, otomatik belge oluşturmak veya buna benzer şeyler için kullanılabilir.
post-merge
kancası başarılı bir merge
komutundan sonra çalışır.
Git’in izleyemediği (örneğin izin verileri gibi) çalışma dizinindeki verileri geri yüklemek için kullanabilirsiniz.
Bu kancayı, çalışma dizini değiştiğinde içeri alınmasını istediğiniz Git kontrolü dışındaki dosyaların varlığını doğrulamak için de kullanabilirsiniz.
pre-push
kancası git push
sırasında (uzak referanslar güncellendikten sonra, ancak nesneler aktarılmadan önce) çalışır.
Parametreler olarak uzak reponun adı ve konumu ile güncellenecek referansların bir listesini stdin
üzerinden alır.
Bir itme gerçekleşmeden önce bir referans kümesini doğrulamak için kullanabilirsiniz (bir çıkış kodu sıfır olmayan bir çıkış kodu itme işlemini iptal eder).
Git, normal işleminin bir parçası olarak git gc --auto
komutunu çağırarak, zaman zaman artık toplar (garbage collection).
pre-auto-gc
kancası artık toplama gerçekleşmeden hemen önce çağrılır ve çöp topladığını bildirmek veya şu anda iyi bir zaman olmadığını belirterek toplamayı iptal etmek için kullanılabilir.
Sunucu Tarafı Kancaları
İstemci tarafı kancalarına ek olarak, sistem yöneticisi olarak neredeyse her türlü politikayı uygulamak için bazı önemli sunucu tarafı kancalarını kullanabilirsiniz. Bu betikler sunucuya yapılan itmelerden önce ve sonra çalışır. Ön kancalar, itme işlemini reddetmek ve istemciye bir hata mesajı göndermek için herhangi bir zamanda sıfırsız çıkış yapabilir. Dilediğiniz ölçüde karmaşık bir itme politikası oluşturabilirsiniz.
pre-receive
pre-receive
kancası bir istemciden yapılan bir itmeyi işlerken çalıştırılacak ilk betiktir.
Bu, stdin’den gönderilen itmelerin bir listesini alır: eğer sıfırsız bir çıkış yaparsa, hiçbiri kabul edilmez.
Bu kancayı, güncellenen referansların hiçbirinin hızlı olmayan (non-fast-forward) itmeler olmadığından emin olmak veya itmeyi kullanarak değiştirdiğiniz tüm referanslar ve dosyalara erişim kontrolü yapmak gibi şeyler için kullanabilirsiniz.
update
update
betiği, pre-receive
betiğiyle çok benzerdir, ancak iten kişinin güncellemeye çalıştığı her dal için bir kez çalıştırılır.
Eğer iten kişi birden çok dala itmeye çalışıyorsa, pre-receive
yalnızca bir kez çalışırken; update
, itilen her dal için bir kez çalışır.
Stdin’den okumak yerine, bu betik üç argüman alır: referansın adı (dal), itmeye çalışmadan önce referansın işaret ettiği SHA-1 ve kullanıcının itmeye çalıştığı SHA-1.
Eğer güncelleme betiği sıfırsız çıkış yaparsa, yalnızca o referans reddedilir; diğer referanslar hala güncellenebilir.
post-receive
post-receive
betiği, işlem tamamlandıktan sonra çalışır ve diğer hizmetleri güncellemek veya kullanıcıları bilgilendirmek için kullanılabilir.
Bu betik, pre-receive
betiğiyle aynı stdin verilerini alır.
Örnekler arasında bir listeye e-posta gönderme, sürekli entegrasyon sunucusunu bildirme veya bir bilet izleme sistemi güncelleme bulunur - hatta katkı mesajlarını analiz ederek açılması, değiştirilmesi veya kapatılması gereken herhangi bir bilet olup olmadığını görebilirsiniz.
Bu betik itme işlemini durduramaz, ancak itme tamamlanana kadar istemci bağlantısını kesmez. Bu nedenle uzun sürebilecek herhangi bir işlem yapmaya çalışırken dikkatli olun.