Dağıtık sürüm kontrolü

Bir Git deposunun başlatılması süreci. Git, en yaygın kullanılan dağıtık sürüm kontrol yazılımlarından biridir.

Dağıtık sürüm kontrolü (veya dağıtık revizyon kontrolü), yazılım geliştirme sürecinde kullanılan bir sürüm kontrolü biçimidir. Bu yöntemde, kod tabanının tamamı ve geçmişi her geliştiricinin bilgisayarında yerel olarak bulunur. Merkezî sürüm kontrolü sistemlerine kıyasla, bu yöntem branch ve merge işlemlerinin otomatik olarak yönetilmesini sağlar, çoğu işlemi (push ve fetch hariç) hızlandırır, çevrimdışı çalışma yeteneğini artırır ve yedekleme için tek bir konuma bağımlı değildir. Git, dünyanın en yaygın kullanılan sürüm kontrol sistemlerinden biridir ve dağıtık bir sürüm kontrol sistemidir.

2010 yılında yazılım geliştirme yazarı Joel Spolsky, dağıtık sürüm kontrol sistemlerini "son on yılın yazılım geliştirme teknolojisindeki en büyük ilerlemelerinden biri olabileceği" şeklinde tanımlamıştır.

Dağıtık ve merkezî sistemler

Dağıtık sürüm kontrolü sistemleri (DVCS), sürüm kontrolü işlemleri için peer-to-peer yaklaşımını kullanır; bu, merkezî sistemlerin kullandığı istemci-sunucu yaklaşımının tersidir. Dağıtık revizyon kontrolü, depoları eşler arasında patch transferiyle senkronize eder. Kod tabanının tek bir merkezî sürümü yoktur; bunun yerine, her kullanıcının hem bir çalışma kopyası hem de tüm değişiklik geçmişini içeren tam bir kopyası bulunur.

Dağıtık sürüm kontrolü'nün (merkezi sistemlere kıyasla) avantajları şunlardır:

• Kullanıcıların ağa bağlı olmadıkları zamanlarda da verimli bir şekilde çalışmalarına olanak tanır.
• Sık kullanılan işlemler (örneğin commit yapma, geçmişi görüntüleme ve değişiklikleri geri alma), DVCS'te daha hızlıdır çünkü merkezi bir sunucu ile iletişim kurmaya gerek yoktur. DVCS sistemlerinde, iletişim yalnızca değişikliklerin diğer kullanıcılarla paylaşılması gerektiğinde gereklidir.
• Özel çalışmalara izin verir; kullanıcılar yayınlamak istemedikleri erken taslaklar üzerinde dahi değişiklik yapabilir ve bu değişiklikleri kullanabilirler.
• Çalışma kopyaları uzaktan yedekleme işlevi görür, böylece tek bir fiziksel makineye bağımlı kalınmaz ve tekil hata noktası riski azaltılmış olur.
• Farklı geliştirme modellerinin kullanılmasına olanak tanır, örneğin geliştirme dalları veya Komutan/Teğmen (Commander/Lieutenant) modeli gibi.
• Projenin "yayın sürümü" üzerinde merkezi denetim sağlanmasına izin verir.
• FOSS (özgür ve açık kaynaklı yazılım) projelerinde, liderlik çatışmaları ya da tasarım anlaşmazlıkları nedeniyle duraklayan bir projeden yeni bir çatallanma oluşturmak çok daha kolaydır.

Dağıtık sürüm kontrolü'nün (merkezi sistemlerle karşılaştırıldığında) dezavantajları şunlardır:

• Bir repository'nin ilk kez indirilmesi (checkout) daha yavaştır; çünkü varsayılan olarak tüm dallar ve sürüm geçmişi yerel makineye kopyalanır.
• Birçok merkezi sürüm kontrol sisteminde bulunan kilitleme mekanizmalarının eksikliği, özellikle birleştirilemeyen ikili dosyalar (örneğin grafik varlıklar) ya da çok karmaşık tek dosyalık ikili veya XML paketleri (örneğin ofis belgeleri, PowerBI dosyaları, SQL Server Data Tools BI paketleri vb.) söz konusu olduğunda önemli bir rol oynar.
• Her kullanıcının tüm kod tabanının geçmişini içeren eksiksiz bir kopyaya sahip olması gerektiğinden, ek depolama alanı gerektirir.
• Her katılımcının kod tabanının tam bir kopyasına sahip olması nedeniyle, kodun dış tehditlere maruziyeti artar.

Bazı başlangıçta merkezi olan sistemler artık dağıtık özellikler de sunmaktadır. Team Foundation Server ve Visual Studio Team Services, Git barındırma yoluyla hem merkezi hem de dağıtık sürüm kontrol repositorielerini desteklemektedir.

Benzer şekilde, bazı dağıtık sistemler de artık ilk indirme süresi ve depolama maliyeti gibi sorunları azaltmaya yönelik özellikler sunmaktadır. Örneğin, Microsoft tarafından çok büyük kod tabanlarıyla çalışmak üzere geliştirilen Virtual File System for Git, yalnızca ihtiyaç duyulduğunda dosyaları yerel depolamaya indirerek çalışan sanal bir dosya sistemi sunar.

Çalışma Modeli

Dağıtık model, genellikle kısmen bağımsız geliştiricilere sahip büyük projeler için daha uygundur; örneğin Linux çekirdeği gibi projeler. Bu model, geliştiricilerin bağımsız dallarda çalışmasına ve daha sonra diğerleri tarafından commit yapılabilen, denetlenebilen ve birleştirilebilen (ya da reddedilebilen) değişiklikler yapmalarına olanak tanır. Bu model, daha iyi bir esneklik sağlar ve orijinal projeden farklı amaçlar için kullanılan özel kaynak kodu dallarının (çatallanma) oluşturulmasını ve uyarlanmasını mümkün kılar. Ayrıca, geliştiricilerin mevcut bir kod havuzunu yerel ortamda klonlamasına ve bu ortamda yapılan değişikliklerin yerel havuza kaydedilmesine olanak tanır. Böylece, değişiklikler ana dal (master branch) havuzuna kaydedilmeden önce daha iyi bir şekilde izlenebilir. Bu yaklaşım, geliştiricilerin yerel ve bağlı olmayan dallarda çalışmasına olanak tanır, bu da daha büyük dağıtık ekipler için daha uygun hale gelir.

Merkezi ve Dal Depoları

Gerçekten dağıtık bir projede, örneğin Linux, her katkı sağlayıcı kendi proje sürümünü korur, farklı katkı sağlayıcılar kendi sürümlerini barındırır ve gerektiğinde diğer kullanıcıların değişikliklerini alırlar. Böylece farklı düğümlerden çıkan genel bir fikir birliği oluşur. Bu aynı zamanda fork (çatallanma) işlemini de kolaylaştırır. Çünkü gereken tek şey, bir katkı sağlayıcının diğer katkı sağlayıcılardan gelen pull request'leri kabul etmeyi durdurması ve kod tabanlarının yavaşça birbirinden ayrılmasına izin vermesidir.

Bu düzen, sürdürülmesi zor olabilir; bu nedenle birçok proje, bir katkı sağlayıcısının evrensel "upstream" (yukarı akış) olduğu, değişikliklerin neredeyse her zaman bu kaynaktan alındığı bir paradigma benimsemeyi tercih etmektedir. Bu paradigma altında, geliştirme kısmen merkezi hale gelir, çünkü her proje artık resmi olarak kabul edilen merkezi bir depo barındırmakta ve bu depo, proje yöneticileri tarafından kolektif olarak yönetilmektedir. Dağıtık sürüm kontrol sistemleri, yeni geliştiricilerin başka bir katkı sağlayıcının deposunun bir kopyasını kolayca klonlamasına olanak tanırken, merkezi bir modelde yeni geliştiriciler her zaman merkezi depoyu klonlarlar, böylece kod tabanının kimliksiz yerel kopyalarını oluştururlar. Bu sistemde, merkezi depodaki kod değişiklikleri periyodik olarak yerel depo ile senkronize edilir ve geliştirme tamamlandığında, değişikliklerin en kısa sürede merkezi depoya entegre edilmesi gerekir.

Bu merkezi modelin kullanıldığı organizasyonlar, genellikle merkezi depoyu GitHub gibi bir üçüncü parti hizmette barındırmayı tercih ederler, çünkü bu tür hizmetler yalnızca kendi barındırdıkları depolara göre daha güvenilir uptime (çalışma süresi) sunmakla kalmaz, aynı zamanda merkezi özellikler de ekler. Örneğin; sorun izleme sistemleri ve sürekli entegrasyon gibi.

Pull İstekleri

Dağıtık sürüm kontrol sistemi kullanan bir kaynak kodu havuzuna katkılar genellikle pull isteği (diğer adıyla merge isteği) yoluyla yapılır. Katkı sağlayıcı, proje yöneticisinden kaynak kodu değişikliğini çekmesini (pull) talep eder, işte bu nedenle "pull isteği" adı verilmiştir. Proje yöneticisi, katkı sağlayıcıların katkısının kaynak koduna dahil edilmesi gerektiği takdirde, pull isteğini birleştirmek zorundadır.

Geliştirici, yeni bir değişikliği yöneticilere bildirmek amacıyla bir pull isteği oluşturur; her pull isteği ile bir yorum dizisi ilişkilendirilir. Bu, kod değişikliklerinin odaklanmış şekilde tartışılmasını sağlar. Gönderilen pull istekleri, depo erişimi olan herkes tarafından görülebilir. Pull isteği, yöneticiler tarafından kabul edilebilir veya reddedilebilir.

Pull isteği gözden geçirilip onaylandıktan sonra, depo ile birleştirilir. Belirlenen iş akışına bağlı olarak, kodun resmi sürüme dahil edilmeden önce test edilmesi gerekebilir. Bu nedenle, bazı projelerde, test edilmemiş pull isteklerini birleştirmek için özel bir dal bulunur. Diğer projeler, her pull isteği üzerinde otomatik bir test takımı çalıştırır, sürekli entegrasyon aracı kullanarak, ve inceleyici yeni kodun uygun test kapsamına sahip olup olmadığını kontrol eder.

Tarihçe

İlk açık kaynak dağıtık sürüm kontrol sistemi yazılımları arasında Arch, Monotone ve Darcs bulunuyordu. Ancak açık kaynaklı sürüm kontrol sistemleri, Git ve Mercurial sürümleri yayımlanana kadar çok popüler olmamıştır.

BitKeeper yazılımı, Linux çekirdeğinin geliştirilmesinde 2002 ile 2005 yılları arasında kullanılmıştır. Git'in geliştirilmesi, şu an dünyadaki en popüler sürüm kontrol sistemi,,BitKeeper yazılımını üreten şirketin, Linus Torvalds ve bazı diğer Linux çekirdeği geliştiricilerinin daha önce faydalandığı ücretsiz lisansı iptal etme kararının ardından başlatılmıştır.

Ayrıca Bakınız

• Sürüm kontrolü
• Sürüm kontrol yazılımları listesi
• Sürüm kontrol yazılımlarının karşılaştırılması
• Dağıtık sürüm kontrolü kullanan yazılımlar
• Depo klonlama
• Git, Linux Çekirdeği geliştirilmesi için geliştirilmiş bir açık kaynak dağıtık sürüm kontrol sistemi
• Mercurial, Git ile benzer, çapraz platform bir sistem
• Fossil, bir dağıtık sürüm kontrol sistemi, hata takip sistemi ve wiki yazılımı
• BitKeeper
• GNU Bazaar
• Darcs
• Concurrent Versions System, dağıtık sürüm kontrol sistemlerinin öncüsü
• TortoiseHg, Mercurial için bir grafiksel arayüz
• Code Co-op, bir peer-to-peer (eşler arası) sürüm kontrol sistemi

Dış Bağlantılar

• Çeşitli sürüm kontrol sistemleri üzerine makale, özellikle "Centralized vs. Decentralized SCM" başlıklı bölüm
• Dağıtık sürüm kontrol sistemlerine giriş - IBM Developer Works makalesi