-
1. Başlangıç
- 1.1 Versiyon Kontrol
- 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 Basics
- 2.1 Getting a Git Repository
- 2.2 Recording Changes to the Repository
- 2.3 Viewing the Commit History
- 2.4 Undoing Things
- 2.5 Working with Remotes
- 2.6 Tagging
- 2.7 Git Aliases
- 2.8 Summary
-
3. Git Branching
- 3.1 Branches in a Nutshell
- 3.2 Basic Branching and Merging
- 3.3 Branch Management
- 3.4 Branching Workflows
- 3.5 Remote Branches
- 3.6 Rebasing
- 3.7 Summary
-
4. Git on the Server
- 4.1 The Protocols
- 4.2 Getting Git on a Server
- 4.3 Generating Your SSH Public Key
- 4.4 Setting Up the Server
- 4.5 Git Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Third Party Hosted Options
- 4.10 Summary
-
5. Distributed Git
- 5.1 Distributed Workflows
- 5.2 Contributing to a Project
- 5.3 Maintaining a Project
- 5.4 Summary
-
6. GitHub
-
7. Git Tools
- 7.1 Revision Selection
- 7.2 Interactive Staging
- 7.3 Stashing and Cleaning
- 7.4 Signing Your Work
- 7.5 Searching
- 7.6 Rewriting History
- 7.7 Reset Demystified
- 7.8 Advanced Merging
- 7.9 Rerere
- 7.10 Debugging with Git
- 7.11 Submodules
- 7.12 Bundling
- 7.13 Replace
- 7.14 Credential Storage
- 7.15 Summary
-
8. Customizing Git
- 8.1 Git Configuration
- 8.2 Git Attributes
- 8.3 Git Hooks
- 8.4 An Example Git-Enforced Policy
- 8.5 Summary
-
9. Git and Other Systems
- 9.1 Git as a Client
- 9.2 Migrating to Git
- 9.3 Summary
-
10. Git Internals
- 10.1 Plumbing and Porcelain
- 10.2 Git Objects
- 10.3 Git References
- 10.4 Packfiles
- 10.5 The Refspec
- 10.6 Transfer Protocols
- 10.7 Maintenance and Data Recovery
- 10.8 Environment Variables
- 10.9 Summary
-
A1. Ek bölüm A: Git in Other Environments
- A1.1 Graphical Interfaces
- A1.2 Git in Visual Studio
- A1.3 Git in Visual Studio Code
- A1.4 Git in Eclipse
- A1.5 Git in Sublime Text
- A1.6 Git in Bash
- A1.7 Git in Zsh
- A1.8 Git in PowerShell
- A1.9 Summary
-
A2. Ek bölüm B: Embedding Git in your Applications
- A2.1 Command-line Git
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Ek bölüm C: Git Commands
- A3.1 Setup and Config
- A3.2 Getting and Creating Projects
- A3.3 Basic Snapshotting
- A3.4 Branching and Merging
- A3.5 Sharing and Updating Projects
- A3.6 Inspection and Comparison
- A3.7 Debugging
- A3.8 Patching
- A3.9 Email
- A3.10 External Systems
- A3.11 Administration
- A3.12 Plumbing Commands
1.3 Başlangıç - Git Nedir?
Git Nedir?
Özetle Git nedir? Bu, özümsemesi gerekli ve önemli olan bir bölümdür. Çünkü eğer Git’in ne olduğunu, temellerini ve nasıl çalıştığını iyi anlarsanız, Git’i etkili bir şekilde kullanmak da muhtemelen sizin için çok daha kolay olacaktır. Git’i öğrenirken, mümkün olduğunca diğer Versiyon Kontrol Sistemleri’nden (CVS, Subversion veya Perforce gibi) bildiklerinizi aklınızdan çıkarmaya gayret edin ki Git’i daha berrak ve doğru şekilde öğrenip kullanabilesiniz. Git’in kullanıcı arayüzü diğer Versiyon Kontrol Sistemleri’ne epey benzese de Git bilgileri diğerlerinden çok daha farklı bir şekilde depolar ve bu bilgiler hakkında daha farklı düşünür. Bu yüzden bunun gibi farklılıkları anlamak Git’i kullanırken kafanızın karışmasını engeller.SubversionPerforce
Farklılıklar Değil, Anlık Görünümler
Git’in diğer herhangi bir VKS’den (Subversion ve benzerleri dahil olmak üzere) en büyük farkı, Git’in veriler hakkında düşünme şeklidir. Diğer çoğu sistem bilgileri dosya-bazlı değişim listesi şeklinde saklar. Bu diğer sistemler (CVS, Subversion, Perforce, Bazaar vd.) bilgileri dosya setleri ve o dosyalara zaman içinde yapılan değişiklikler şeklinde saklar (Bu genellikle delta-bazlı versiyon kontrol şeklinde tanımlanır).
![Verileri her dosyanın baz versiyonunu referans alarak](png/deltas.png)
Git, verileri hakkında bu şekilde düşünmez ve onları bu şekilde saklamaz. Bunun yerine Git, verilerini daha çok minyatür dosya sistemlerinin anlık görünümler serisi şeklinde düşünür ve o şekilde saklar. Git’le her commit yaptığınızda ya da projenizin durumunu kaydettiğinizde, Git kısaca tüm dosyalarınızın o an nasıl göründüğünün fotoğrafını çeker ve o anlık görünümün referansını saklar. Verimli olmak adına, eğer dosyalar değişmemişse Git o dosyaları tekrar saklamaz, onun yerine o dosyaların halihazırda saklandığı referansa bağlantı verir. Yani Git, verilerini daha çok anlık görünüm akışı olarak görür.
![Git zaman geçtikçe veriyi projenin anlık görünümleri olarak saklar.](png/snapshots.png)
Bu Git ve neredeyse diğer tüm VKS’lerinin arasındaki en büyük ayrımdır. Bu da Git’i, diğer sistemlerin kendilerinden önceki jenerasyondan kopyaladıkları versiyon kontrolünün her yönünü yeniden değerlendirmesini sağlar. Böylelikle Git, basit bir VKS’dense, inanılmaz güçlü araçlarla donatılmış minyatür bir dosya sistemi olmuştur. Git’deki dallanmayı anlatırken verileriniz hakkında bu şekilde düşünmenin getirilerini keşfedeceğiz. Git Branching
Neredeyse Her İşlem Yereldir
Git’deki çoğu işlem çalışmak için yalnızca yerel dosyalara ve kaynaklara ihtiyaç duyar. Genel olarak başka bir bilgisayardan sizin ağınıza bilgi gelmesine ihtiyacınız yoktur. Eğer çoğu işlemin ağ gecikme yüküne sahip olduğu bir MVKS’ye (Merkezî Versiyon Kontrol Sistemi) alışkınsanız, Git’in bu yönü size, Hız Tanrıları’nın Git’i, ilahi ve tanrısal güçlerle kutsadığını düşündürecektir. Çünkü projenizin tüm tarihçesi tam olarak yerel diskinizdedir, ve çoğu işlem de neredeyse anında gerçekleşir.
Örneğin, projenin tarihçesine göz atmak için Git’in sunucuya girip, tarihçeye erişip size göstermesine gerek yoktur, onun yerine hızlıca sizin yerel veritabanınızdan okur. Bu da proje tarihçesini neredeyse anında görebildiğiniz anlamına gelir. Eğer bir dosyanın mevcut sürümü ve bir ay önceki sürümü arasındaki değişiklikleri görmek isterseniz, Git, uzaktaki bir sunucuya bu işlemi yapması için başvurmak ya da dosyanın eski versiyonunu uzaktaki sunucudan çekip yerel diskte hesaplamak yerine, dosyanın bir ay önceki haline hızlıca göz atıp yerel bir farklılık hesaplaması yapar.
Bu da çevrim dışı ya da VPN’sizseniz bile yapamayacağınız sadece çok az şey olduğunu belirtir. Eğer uçakla ya da trenle seyahet ediyorken biraz çalışmak isterseniz, yerel ortamınızda çalışıp commitleyebilir (yerel kopyanıza) ve internet bağlantısı edindiğinizde de onu internete yükleyebilirsiniz. Eğer eve giderseniz ve VPN istemciniz düzgün bir şekilde çalışmazsa bile hâlâ yerel ortamınızda çalışabilirsiniz. Diğer çoğu sistemde ise bunları yapmak ya imkânsız ya da çok sancılıdır. Örneğin Perforce’de, eğer sunucuya bağlı değilseniz pek bir şey yapamazsınız. Subversion ve CVS’de ise dosyaları düzenleyebilir ama sunucuya commitleyemezsiniz (Çünkü sunucunuz çevrim dışı). Bu size şu an çok da önemli bir özellikmiş gibi gelmeyebilir ama Git’i öğrendikçe ve kullandıkça bunun ne kadar büyük bir fayda sağladığını bizzat göreceksiniz.
Git’in Entegrasyonu Vardır
Git’deki her şey saklanmadan önce sağlaması yapılır ve ondan sonra da o sağlamayla referans gösterilir. Bu da dosyaların ya da klasörlerin içeriğini Git’in haberi olmadan değiştirmenin imkânsız olduğu anlamına gelir. Bu işlev Git’in temelinde gömülü halde gelir ve Git’in felsefesinin ayrılmaz bir parçasıdır. Aktarım yaparken bilgi kaybetmezsiniz. Aynı şekilde Git farkına varmadan bir dosya da bozulmaz.
Git’in sağlama yapmak için kullandığı bu mekanizmanın adı SHA-1 özetidir. Bu, on altılık karakterlerden (0-9 ve a–f) oluşan ve Git’deki bir dosya veya dizin yapısının içeriğine göre hesaplanan 40 karakterlik bir karakter dizisidir. Bir SHA-1 özeti şuna benzer:
24b9da6552252987aa493b52f8696cd6d3b00373
Bu özet değerlerini Git’in çoğu yerinde göreceksiniz çünkü Git onu sık sık kullanır. Hatta Git, sunucusundaki her şeyi dosya isimleriyle değil, içeriklerinin özet değeriyle saklar.
Git Genel Olarak Sadece Veri Ekler
Git’de bir şeyler yaptığınızda neredeyse hepsi sadece Git’in veritabanına veri ekler. Sistemin geri alınamayan bir şey yapmasını veya verileri herhangi bir şekilde silmesini sağlamak zordur. Tüm VCS’lerde olduğu gibi, henüz commitlemediğiniz değişiklikleri kaybedebilir veya karman çorman yapabilirsiniz, ancak Git’e bir anlık görünüm verdikten sonra, özellikle veritabanınızı düzenli olarak başka bir repository’e yollarsanız, kaybetmek çok zordur.
Bu da Git’i kullanmayı keyifli kılar çünkü ortalığı batırma tehlikesi olmadan istediğimiz gibi denemeler yapabileceğimizi biliriz. Git’in verilerini nasıl sakladığını ve kaybolmuş gibi görünen dosyaları nasıl geri alabileceğinizi daha detaylı bir şekilde öğrenmek için: Undoing Things
Üç Durum
Eğer Git’i öğrenme sürecinizin sorunsuz olmasını istiyorsanız, şimdi dikkatinizi verin. Git hakkında akılda tutulacak ana şey şudur, Git’in dosyalarınızın içinde bulunabileceği üç ana durum vardır: modified, staged, and committed:
-
Modified, dosyayı değiştirdiğinizi ama henüz veritabanına commitlemediğinizi gösterir.
-
Staged, değiştirilmiş bir dosyayı bir sonraki commit anlık görünümünde işlenecek şekilde işaretlediğinizi gösterir.
-
Committed, dosyanın güvenli bir şekilde yerel veritabanınızda saklandığını gösterir.
Bu da bizi bir Git projesinin üç ana bölümüne getirir: the working tree, the staging area, ve Git klasörü.
![Working tree, staging area ve Git klasörü](png/areas.png)
Working tree, checkout komutunun projenin bir versiyonunda çalıştırılmasıdır. Bu dosyalar Git directory’deki sıkıştırılmış veritabanından çıkarılır ve sizin modifiye edebilmeniz veya kullanabilmeniz için diskinize yerleştirilir.
The staging area bir dosyadır, genel olarak Git klasörünüzün içindedir ve bir sonraki commite hangi bilgilerin gideceğini depolar. Git jargonundaki teknik adı ``index``dir, ama ``staging area`` ifadesi de iş görür.
Git klasörü ise Git’in projenize ait tüm üstverileri ve obje veritabanını sakladığı yerdir. Bu Git’in en önemli bölümüdür, aynı zamanda da başka bir repository’den klonu kopyaladığınızda kopyalanan şeyin ta kendisidir.
Git’in iş akışı basitçe şöyledir:
-
Working tree’de dosyaları düzenlersiniz.
-
Bir sonraki committe işlenecek olan değişiklikleri seçersiniz.
-
Bir commit yaparsınız, staging area’daki dosyaların anlık görünümünü çeker ve Git klasörünüzde kalıcı olarak saklarsınız.
Eğer bir dosyanın belli bir versiyonu Git klasöründeyse, o dosya commitlenmiş sayılır. Eğer düzenlenmiş ve staging area’ya eklenmişse, stage edilmiştir. Eğer son denetlenmesinden sonra değiştirilmişse ama işlenmemişse, o halde modifiye edilmiştir. Şu kısımda bu durumlar hakkında daha fazla şey öğrenecek ve bu durumların avantajını kullanmayı ya da stage kısmını tamamen es geçmeyi öğreneceksiniz: Git Basics