Git
Chapters ▾ 2nd Edition

1.1 Başlangıç - Versiyon Kontrol

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.

Versiyon Kontrol

Versiyon kontrol nedir ve neden önemsenmelidir? Versiyon kontrol, belirli versiyonların 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, versiyon kontrol için yazılım kodları kullanılacaktır fakat versiyon kontrol bilgisayardaki herhangi bir dosya türü için de kullanılabilir.

Eğer grafik ya da web 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), Versiyon Kontrol Sistemi (VKS) akıllıca bir seçim olacaktır. Versiyon Kontrol Sistemi, seçili dosyaların bir önceki versiyona (bir önceki değişiklik yapılmış duruma) döndürülmesi, projenin tamamının bir önceki versiyona 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 Versiyon Kontrol Sistemleri

Çoğu insanın versiyon kontrol metodu, 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 versiyon kontrol sistemlerini geliştirdiler.

Local version control diagram
Figure 1. Local version control.

One of the most popular VCS tools was a system called RCS, which is still distributed with many computers today. RCS works by keeping patch sets (that is, the differences between files) in a special format on disk; it can then re-create what any file looked like at any point in time by adding up all the patches.

Centralized Version Control Systems

The next major issue that people encounter is that they need to collaborate with developers on other systems. To deal with this problem, Centralized Version Control Systems (CVCSs) were developed. These systems (such as CVS, Subversion, and Perforce) have a single server that contains all the versioned files, and a number of clients that check out files from that central place. For many years, this has been the standard for version control.

Centralized version control diagram
Figure 2. Centralized version control.

This setup offers many advantages, especially over local VCSs. For example, everyone knows to a certain degree what everyone else on the project is doing. Administrators have fine-grained control over who can do what, and it’s far easier to administer a CVCS than it is to deal with local databases on every client.

However, this setup also has some serious downsides. The most obvious is the single point of failure that the centralized server represents. If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they’re working on. If the hard disk the central database is on becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything — the entire history of the project except whatever single snapshots people happen to have on their local machines. Local VCS systems suffer from this same problem — whenever you have the entire history of the project in a single place, you risk losing everything.

Distributed Version Control Systems

This is where Distributed Version Control Systems (DVCSs) step in. In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files; rather, they fully mirror the repository, including its full history. Thus, if any server dies, and these systems were collaborating via that server, any of the client repositories can be copied back up to the server to restore it. Every clone is really a full backup of all the data.

Distributed version control diagram
Figure 3. Distributed version control.

Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project. This allows you to set up several types of workflows that aren’t possible in centralized systems, such as hierarchical models.