Yeni bir proje geliştirmeye başladınız. Gece gündüz üzerinde çalışıyorsunuz ve sürekli yeni işlevler ekliyorsunuz. Tabi proje üzerinde endişeli olduğunuz için yaptığınız her büyük bir işlemden sonra projenin yedeğini alıyorsunuz. Aldığınız bütün yedeklere kendi düzeninizce bir ad veriyorsunuz; sayısal sıralama, alfabetik sıralama ya da tarihsel sıralama. Artık Allah ne verdiyse! Belli bir zaman sonra yedeklerinizin sayısı inanılmaz artıyor ve hangi yedeğin, ne anlama geldiğini anlamamaya başlıyorsunuz. Hadi çare olarak da aklınıza şöyle bir yöntem geldi; aldığınız her yedek hakkında kısa ve öz yazılar yazıp, bir dosyada saklamak ya da bir Excel tablosunda düzenli olarak yedek sürümleri hakkında notlar düşmek. Ya peki bu geliştirdiğiniz projeye bir ya da birden fazla geliştirici dahil etmek istediğinizde? Proje üzerinde her geliştiricinin ayrı ayrı işlemler yapıp, sonrasında da bu projeyi inşa (build) etmek istediğinizde? İşte o zaman size bir önerim var: Aşağıdaki YouTube bağlantısına tıklayıp, Yahya Kemal Beyatlı’nın içini döktüğü, Münir Nurettin Selçuk’un nakış nakış dokuyarak bestelediği mükemmel bir eser olan ‘Dönülmez Akşamın Ufkundayız’ şarkısını, geliştirici arkadaşlarınızla birlikte uzun uzun dinleyebilirisiniz.
Elbette şaka yapıyorum! Ancak siz yine de yukarıdaki şarkıyı istediğiniz zaman dinleyin. Sevdiğim bir şarkıdır.
Yukarıda anlattığım sorun, VCS’siz bir çalışma yürütmenin en temel sorunlarından birisidir. VCS, yukarıdaki soruna çok güzel bir derman olacağı gibi daha bir çok nimet sağlar:
- Tek bir proje üzerinde, birden çok kişinin, birbirinden bağımsız bir şekilde çalışabilmesi.
- istenilen her an, üzerinde çalışılan dosya ya da dosyaların önceki sürümlerine erişebilme.
- En baştan en sona kadar yapılan değişiklikleri birbirleriyle karşılaştırabilme.
- Değişiklik yapılan dosya ile ilgili; değişikliği kimin yaptığını, hangi tarihte yaptığını vs. görebilme.
- Herhangi bir olumsuz durum meydana geldiğinde, istenilen herhangi bir sürüme kolayca geri dönebilme.
- Geliştirdiğiniz projeye, yeni bir özellik eklemek istediğinizde, var olan projenin bir kopyasını alıp (branch), ona yeni özelliği ekleyip ve ekleme işlemi başarılı olduğunda da kopya proje ile asıl projeyi birleştirebilme. (merge)
Şimdilik bu kadar yararı sıralamamız yeterli sanırım. Gerçi bir geliştirici olarak daha ne isteyeceksiniz ki!
Bu yazı, elbette biz geliştiriciler için hazırlandı. Ancak VCS konusunda, bencil olmamak gerek. Zira roman yazan bir yazar bile kesinlikle VCS kullanmalı! Çünkü onun da kitabını düzenli yazabilmesi için adım adım aldığı notlara, yazdığından vazgeçip, eski haline dönme gibi hakları var. Kısacası; eğer sayısal (bilgisayar) ortamda bir çalışma yürütüyor iseniz her şekilde VCS’ye ihtiyaç duyabilirisiniz. Yazılım & oyun projelerinizde, grafik çizimlerinizde, makale ya da kitap yazmalarınızda vs.
Güzel bir giriş yaptığımızı düşünüyorum. Şimdi de VCS fikrinin tarihine kısa bir gözatalım…
VCS, günümüzde hep bilgisayar ortamında geliştirilen projeler ile birlikte anılsa da, bu fikir teorisel olarak çok öncelere dayanmaktadır. Hatta çivi yazısı ile yazılmış tabletlere kadar uzanır. Zira onlar da kopyalanıyor idi. Yakın çağda ise yazılı belgeler karbon kağıdı ile kopyalanmaktaydı. Her bir kopya üzerinde yeni bir değişiklik yapılarak, belgenin yeni bir sürümü meydana gelmekteydi ve bunlar da tabiki raflı dolaplarda saklanmaktaydı.
Hayatımıza bilgisayarlar girdikten sonra belgelerin elle tutulması mantıklı görünmüyordu. 1972 yılında, Marc Rochkind adlı şahıs Bell Labs’ta ‘Source Code Control System’ (SCCS) geliştirdi. O zamanlar, yazılımlar makine kodu (Byte-ASM) ya da düşük seviyeli diller ile geliştirilmekteydi. Tek bir byte’ın bile değişikliği, çok büyük sorunlara yol açabiliyordu. O yüzden yapılan değişiklikleri byte byte izlemek, büyük önem arz ediyordu. Yani SCCS yetersiz kalıyordu.
SCCS’den yıllar sonra Walter Tichy adlı şahıs Purdue Üniversite’sinde, ‘Revision Control System’ (RCS) geliştirdi. Böylelikle açık kaynaklı olan CVS’nin temelleri atılmış oldu. Ancak o zamanlarda bir sorun daha vardı. O da sabit disk alanı. Sabit disklerin fiyatları oldukça yüksek idi. Sürüm denetimi yapabilmek için bir dosyanın farklı farklı kopyaları zamanla inanılmaz yer kaplayabiliyordu.
VCS konusunda, şuan gerçekten de çok şanslıyız. VCS’nin ilkel ataları (RCS, SCCS gibi) sadece yerel bilgisayarda, ağ desteği olmadan veritabanı düzeni ile sürümleri tutuyordu. Aynı anda, bir dosya üzerinde sadece bir kişi çalışabiliyordu. Çok yazık…
Tabi bu durum karşısında bazı geliştiriciler ekip halinde eş-zamanlı olarak çalışmak istedikleri için isyan bayraklarını çektiler ve sonunda insanoğlu (geliştiriciler) Merkezi Sürüm Denetim Düzeni’ni geliştirdi! (CVS, SourceSafe, Subversion, Perforce, Team Foundation Server gibi) Bu teknoloji ile artık çalışmalar, ekip tarafından bir ağ üzerinden rahatlıkla takip edilip, kullanılabiliyordu. Bu düzen; sürüm denetimine alınan, bütün dosyaları tutan bir sunucu ve bu sunucudan dosyaları seçerek alan (check out) istemcilerden oluşur.
Bu düzen, RCS, SCCS gibi ilk nesil VCS’lere göre daha üstündü. Örneğin, bir projedeki herkes, diğerlerinin ne yaptığından belirli ölçüde haberdardır. Sistem yöneticileri kimin hangi yetkilere sahip olacağını oldukça ayrıntılı biçimde düzenleyebilirler; üstelik bir Merkezi Sürüm Denetim Düzeni’ni yönetmek, her istemcide ayrı ayrı kurulu olan yerel veritabanlarını yönetmeye göre çok daha kolaydır.
Yalnız Merkezi Sürüm Denetim Düzeni’nde insanı (geliştiriciyi) kanser eden bir takım durumlar meydana gelebiliyor. Örneğin projenin bulunduğu sunucu çökerse ya da geçici olarak kapanırsa, o süre zarfında geliştiriciler, üzerinde çalıştıkları işleri sunucuya aktaramayacakları gibi bir de o çalışmaları sürümleyemeyecekler. Hele de projenin bulunduğu sunucunun sabit diski bozulursa ve proje sürüm denetimi doğru bir şekilde yedeklenmemiş ise artık geçmiş olsun. Tüm yazılım ekibi, haftasonu bir mangal partisi düzenleyebilirler.
Yazının gidişatından da anlayacağınız üzere Git, Mercurial, Bazaar gibi Dağıtık Sürüm Denetim Düzeni’ne kaymaktayız. Merkezi Sürüm Denetim Düzeni taraftarları, şuan ellerine maşalarını alıyor olabilirler…
Önceki resimde de görüldüğü gibi; Dağıtık Sürüm Denetim Düzeni’nde, geliştiriciler sadece çalışacakları dosyaları değil, projenin tüm kopyasını yerel bilgisayarlarına alırlar. Bu durumda, sunucuyu sel bassa bile projenin son sürümü tekrardan rahatlıkla kurtarılabilir.
Geldik bir yazının daha sonuna! Bu yazı ile ilgili olarak herhangi bir bildirimde bulunmak için konu altına yorum yazabilir ya da [email protected] adresine e-posta gönderebilirsiniz.
Kaynaklar
- https://git-scm.com/book/tr/v2
- https://layervault.tumblr.com/post/102541175774/the-history-of-version-control
- http://ericsink.com/vcbe/html/history_of_version_control.html