Versiyon Kontrol Sistemleri | Git Dersleri | Mobilhanem

Versiyon Kontrol Sistemleri | Git Dersleri | Mobilhanem

Merhabalar,
Mobilhanem’de başladığımız Git derslerine devam ediyoruz. Bu dersimizde Git ve Versiyon Kontrol Sistemleri’ni ve temel özelliklerini öğreneceğiz.

İlk Versiyon Kontrol Sistemleri

Versiyon kontrol sistemleri aslında çok yeni bir sistem değil. İlk olarak 1972 yılında SCCS (Source Code Control System) yayınlandı. Özgür Yazılım (Free Software Foundation) kanadından da alternatif olarak GNU SCCS yayınlandı. SCCS, Unix sistemler için defacto haline gelmişti. 1982 yıllarında da yine Özgür Yazılım Vakfı tarafından, GNU RCS (Revision Control System) yayınlandı ve oldukça popüler hale geldi.

Bu gösteriyor ki 1970’li yıllarda böyle bir sisteme ihtiyaç duyulmaya başlanmış. Tabiki bu sistemler günümüzdeki versiyon kontrol sistemleri kadar gelişmiş, küçük projeler için kullanışlı bir sistem olsalar da büyük projeler için elverişli bir sistem değillerdi.

Pesimist ve Optimist Sistemler

Bir önceki dersimizde de bahsettiğimiz gibi iki kişi aynı dosyayı değiştirdiğinde çakışma meydana gelir. Versiyon kontrol sistemlerinde conflict olarak isimlendirilir. Versiyon kontrol sistemleri ile çalışırken en büyük problemlerden biri bu çakışmalardır. Bu çakışmanın çözümü için iki farklı yöntem bulunmaktadır.

Pesimist Sistemler (Senkron)

Pesimist yöntemde bir kişi kaynak kodu içerisinde herhangi bir dosya üzerinde değişiklik yapmak istediğinde o dosyaya bir kilit (locking) koyar. Başka biri aynı dosyayı değiştirmek istediğinde VCS buna izin vermez. Dosyayı ilk alan kişi yani checkout işlemini yapan kişi değişikliği yapıp işi bitince son halini VCS’ye geri gönderir yani commit yapmış olur. Bu işlem sonrasında oluşan kilit kalkmış olur. Eğer o kişi commit yapmak istemiyorsa kilidi yine kaldırabilir. Kilit kalktıktan sonra diğer geliştiriciler aynı dosya üzerinde geliştirme yapabilirler. Bu tür sistemlere pesimist ya da senkron sistemler denir.

Bu yöntemle çakışma önlenmiş olur. Fakat aynı dosyayı değiştirmek isteyen bir kişi diğerini beklemek zorunda kalır. Bu ekip içerisinde verimsizliğe sebep olur. Hatta ekip içerisinde kavgalara sebep olabilir.

CVS (Concurrent Versions Systems) bu sistemlere örnek verilebilir. Aynı şekilde SVN (Subversion) da bu şekilde çalışabilir.

Optimist Sistemler (Asenkron)

Pesimist yönteminin verimsizliğine karşı optimist sistemler kilit mekanizmasını kullanmazlar. Bunun yerine herkesin aynı dosya üzerinde değişiklik yapmasına izin verir. Fakat değişliği VCS’ye gönderdiğinde eğer ki dosyayı aldığında yani checkout yaptığındaki versiyonu ile dosyayı sisteme gönderirken yani commit yaptığındaki versiyonu farklı ise conflict yani çakışma olur. Son gönderen kişi bu çakışmayı çözerek yeni bir versiyon commit eder. Bu tür sistemlere de optimist ya da asenkron sistemler denir.

Bu sistemin avantajı kilit sistemi ile oluşan verimsizliği ortadan kaldırmaktır. Eğer projede çalışan kişiler sürekli aynı dosya üzerinde değişiklik yaparsa sürekli conflict alırlar. Bu iyi yönetilmezse can sıkıcı bir hale gelir.

Git de dahil olmak üzere günümüzdeki modern VCS’ler optimist sistemlerdir.

Merkezi (Central) ve Dağıtık (Distributed) Sistemler

İlk dersimizde de söylediğimiz VCS’ler ekip halinde çalışmayı sağlar. Bunu sağlayabilmesi için yapılan değişikliklerin ve kaynak kodun tarihçesinin ortak bir yerde yani bir sunucuda (remote server) saklanması şarttır. Birden fazla kaynak dosyanın ve tarihçesinin bulunduğu yapı repository (depo) olarak isimlendirilir.

Yerel Sistemler

Yerel Sistemler

Bu tür sistemler herhangi bir uzak sunucu (remote server) ile çalışmaz. Kaynak kodun tarihçesi de sadece yerel sistemlerde yapılır; yerelde versiyonlama yapar. Kişisel işler için kullanılabilir fakat ekip halinde çalışma imkanı sunmazlar.

Merkezi Sistemler

Yerel SistemlerMerkezi Sistemler

Merkezi sistemler bu konuda en basit çözümlerden biridir. Kaynak kod ve tarihçesi yani repository merkezi bir sunucuda yer alır. Şekilden de anlayacağınız gibi istemcilerde kaynak kodun kopyası yer alır fakat kaynak kodun tarihçesi yer almaz. Kodların tarihçesi sadece merkezi bir sistemde bulunur.

Kaynak kod üzerinde değişiklik yapmak isteyen bir kişi öncelikle değiştirmek istediği dosyayı checkout işlemi ile kodu alır. (Pesimist sistemse aynı zamanda kilitler.) Daha sonra üzerinde geliştirme yaptıktan sonra dosyanın son halini merkezi sunucuya gönderir. Bu işleme daha önce açıkladığım gibi commit diyoruz.

Sadece bir sunucunun repository olduğu ve merkezi bir konumda yer aldığı için bu tür sistemlere merkezi (central) sistemler denir. Git’den önce en popüler VCS olan SVN, CVS ve diğer bir çok versiyon kontrol sistemi merkezi sistemlerdir.

Bu sistemlerde eğer ki merkezi sunucunun başına birşey gelirse ve yedeğiniz yoksa kodun bütün tarihçesini kaybedersiniz. Yerel bilgisayarlarda kodun sadece son hali yer alır. Bu yapıdan dolayı repository kaybeden birçok ekip bulunmaktadır. Şimdi diğer bir yaklaşıma göz atalım.

Dağıtık Sistemler

Dağıtık Sistemler

Şekilden de anlayacağınız gibi dağıtık sistemler, merkezi sistemlerin aksine kaynak kodu ve tarihçesi merkezi bir yerde toplamak yerine kod üzerinde değişiklik yapan her istemcinin sistemlerine de dağıtır. Kaynak kodu ve tarihçesi sadece bir sunucuda değil aynı zamanda geliştricilerde de yer alır. Yani her geliştiricinin kendi bilgisayarında yerel bir sunucudakinin birebir kopyası yani repository bulunur.

Bu yaklaşımda kendi bilgisayarınızda bir repository olduğu için commit işlemi uzak sunucuya değil yerelinize yapılır. Daha sonra yerelinizdeki commit‘ler uzak sunucuya gönderilir (Uzak sunucuya commit yapılmaz). Aynı projede çalıştığınız diğer kişiler de uzak sunucudan sizin yaptığınız commit‘leri alıp yerelinde projenin son haline ulaşır.

Dağıtık sistemlerin en büyük avantajı sürekli merkezi bir sunucuya ihtiyacı olmadığı için bazı işlemleri hızlı bir şekilde gerçekleştirebilir. Kendi sisteminize özgü uzak sunucudan farklı işlemler yapılmasına da imkan sağlar. Ayrıca dağıtık bir yapıda birden fazla uzak sunucu ile de çalışabilirsiniz. Kaynak kodunuzun bir versiyonunu bir repository‘de saklarken farklı bir versiyonunu farklı bir repository‘de saklayabilirsiniz. Uzak sunucudaki repository‘yi kaybetmeniz durumunda her geliştiricinin bilgisayarında aynı repository olacağı için tarihçeyi kurtarmanız oldukça kolaydır.

Git, Mercurial ve Bitkeeper bu sistemlere örnek verilebilir.

Özellikle geliştirici sayısı fazla olan büyük projelerde çok büyük avantaj sağlar. Bu projelere Linux Kernel örnek verilebilir. Zaten Git’in ortaya çıkmasının en temel sebebi Linux Kernel’in dağıtık bir yapıya ihtiyaç duymasından kaynaklanmaktadır.

Anladığınız üzere Git, optimist ve dağıtık bir versiyon kontrol sistemidir. Hem uzak bir sunucuda hem de sadece yerelde kullanılabilir. Bu dersimizde versiyon kontrol sistemlerini ve bu konudaki temel yaklaşımları görmüş olduk. Bir sonraki dersimizde Git’i biraz daha yakından tanıyacağız.

Konu hakkında görüş ve sorularınızı yorum kısmından veya Soru & Cevap sitemizden sorabilirsiniz.

Bir sonraki derste görüşmek üzere…

Git derslerinin tamamı için tıklayınız.

37

Yorum Yap
0 Yorum yapan