-
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ı
1.1 Başlangıç - Sürüm Denetimi
Bu bölümde Git kullanımı hakkında temel bilgileri bulacaksınız. İşe, sürüm kontrol sistemleri hakkında açıklamalarla başlayacağız; daha sonra Git kurulumunun nasıl yapılacağını, en son olarak da aracın yapılandırma ve kullanımını açıklayacağız. Bu bölümün sonunda Git’in neden var olduğunu ve neden onu kullanmanız gerektiğini anlayacak, Git’i kullanmaya başlamak için kurulumu tamamlamış olacaksınız.
Sürüm Denetimi
Sürüm Denetimi nedir ve neden önemsenmelidir? Sürüm denetimi, belirli sürümlerin daha sonra çağrılabilmesi için zaman içerisinde bir dosya veya dosya grubundaki değişiklikleri kaydeden bir sistemdir. Örneğin bu kitapta, sürüm denetimi için yazılım kodları kullanılacaktır fakat sürüm denetimi bilgisayardaki herhangi bir dosya türü için de kullanılabilir.
Eğer grafik ya da ağ tasarımcı iseniz ve çalıştığınız görüntü ya da tasarımların her bir değişikliklerini tutmak istiyorsanız (ki bu gerçekten istebilecek bir şeydir), Sürüm Denetim Sistemi (VCS: Version Control System) akıllıca bir seçim olacaktır. Sürüm Denetim Sistemi, seçili dosyaların bir önceki sürüme (bir önceki duruma) döndürülmesi, projenin tamamının bir önceki sürüme döndürülmesi, zaman içerisinde yapılan değişikliklerin karşılaştırılması, probleme neden olabilecek değişikliklerin en son kimin tarafından yapıldığı, kim bir problemden ne zaman bahsetti gibi bir çok işlemin gerçekleştirilebilmesini sağlar. Genel olarak VKS kullanmak, değişiklik yaptığınız dosyalar üzerinde bir şeyleri berbat ettiğinizde ya da bir şeyleri kaybettiğinizde kolayca geri getirebilmeniz anlamına gelmektedir. Ayrıca VKS’nin tüm bu özelliklerini çok az bir iş yüküyle elde edersiniz.
Yerel Sürüm Denetim Sistemleri
Çoğu insanın sürüm denetim yöntemi, ilgili dosyaları başka bir yere kopyalamaktır (Muhtemelen daha zeki olanları, klasör isimlendirmesinde zaman damgası kullanıyordur). Bu yaklaşım basit olduğundan çok yaygındır fakat aynı zamanda inanılmaz derecede hataya açık bir yaklaşımdır. Hangi dizinde bulunduğunuzu unutmak, yanlışlıkla yanlış dosya üzerine yazmak veya istemediğiniz dosyaların üzerine yazmak gibi ihtimallerin gerçekleşmesi çok olasıdır.
Tüm bu sorunlardan ötürü, uzun zaman önce geliştiriciler, yapılan tüm değişiklikleri gözden geçirilebilir parçalar halinde basit veritabanı üzerinde tutan yerel sürüm denetim sistemlerini geliştirdiler.
En popüler VCS araçları RCS adında bir sistemdi, ki kendisi bugün bile hâlâ pek çok bilgisayarda kullanılır. RCS yama setlerini (dosyalar arasındaki farklılıklar) disk üzerinde özel bir formatta tutarak çalışır; daha sonra tüm yamaları bir araya getirerek herhangi bir zamanda herhangi bir dosyanın nasıl göründüğüne bakarak onu yeniden oluşturabilir.
Merkezî Sürüm Denetim Sistemleri
İnsanların karşılaştığı bir diğer büyük problemse diğer sistemlerdeki geliştiricilerle iş birliği yapmak zorunda kalmalarıydı. Bu problemin çözümü olarak Merkezî Sürüm Denetim Sistemleri (CVCS: Central VCS) geliştirildi. Bu sistemler (CVS, Subversion ve Perforce gibi) bütün sürümlendirilmiş dosyaları barındıran tek bir sunucuya ve o sunucudaki dosyaları tek merkezden sürekli denetleyen istemcilere sahipti. Uzun yıllar boyunca bu sistem, sürüm denetim sistemleri için standart oldu.
Bu kurulum yerel VCS’lere kıyasla pek çok avantaj sunar. Örneğin, projedeki herkes diğer herkesin projede ne yaptığını belli bir ölçüye kadar bilebilir. Yöneticiler, kimin ne yapabileceği konusunda hassas bir kontrole sahiptir ve bir CVCS’yi yönetmek her istemcideki yerel veritabanlarıyla uğraşmaktan çok daha kolaydır.
Bununla birlikte bu kurulumun ciddi dezavantajları da vardır. En bariz olanı merkezi sunucuların tek bir noktaya bağlı olmasıdır. Eğer o sunucu bir saatliğine çökerse, çöktüğü andan itibaren hiç kimse hiç iş birliği yapamaz veya üzerinde çalışmakta oldukları herhangi bir şeye sürüm değişikliklerini kaydedemezler. Eğer sunucu veritabanındaki harici disk bozulursa ve düzgün yedekleme yapılmamışsa, kullanıcıların kendi yerel makinelerinde tuttukları anlık durum dışında projenin tüm tarihini ve dosyalarını, yani her şeyi kaybedersiniz. Yerel VKS’ler de aynı sorundan muzdariptir, projenin tüm tarihini ve dosyalarını tek bir yerde tuttuğunuz sürece, her şeyi kaybetme riskiniz vardır.
Dağıtık Sürüm Denetim Sistemleri
İşte tam da burada devreye Dağıtık Sürüm Denetim Sistemleri (DVCS: Distributed VCS) giriyor. Bir DVCS’de (Git, Mercurial, Bazaar ya da Darcs gibi) istemciler sadece dosyaların son anlık görünümünü denetlemezler, daha çok repoyu reponun tam tarihiyle birlikte yansıtırlar. Dolayısıyla eğer herhangi bir sunucu devre dışı kalırsa, birbiriyle o sunucu aracılığıyla iş birliği yapan sistemlerdeki herhangi bir istemci reposu sunucuyu yenilemek için geri yüklenebilir. Her klon, en nihayetinde tüm verilerin tam bir yedeğidir aslında.
Ayrıca bu sistemlerin çoğu birden çok uzak repoyla çalışmayı rahatlıkla kaldırabilir, o yüzden farklı gruplardan insanlarla farklı yollarla eş zamanlı bir şekilde rahatlıkla iş birliği yapabilirsiniz. Bu da size hiyerarşik model gibi merkezi sistemlerde yapması mümkün olmayan birden çok iş akışı şekli tanımlama ve kullanma olanağı sağlar.