Git Nedir ve Geliştirici Olsanız Neden Sürüm Kontrolünü Kullanmalısınız?

Web geliştiricileri olarak, çoğu zaman yerel geliştirme sitelerinde çalışma eğilimindeyiz, daha sonra işimiz bittiğinde her şeyi yükleyin. Bu sadece sizin ve değişikliklerin küçük olması durumunda iyidir, ancak bir şey üzerinde çalışan birden fazla kişiyle veya karmaşık bileşenlerin bulunduğu büyük bir projede çalışırken, bu mümkün değildir. O zaman sürüm kontrolü denilen bir şeye döndüğümüzde.

Bugün Git adında açık kaynaklı bir sürüm kontrol yazılımı hakkında konuşacağım. Bu, birden fazla kişinin aynı projede birbirleriyle etkileşime girmeden güvenli bir şekilde çalışmasına izin verir, ancak bundan çok daha fazlası.

Neden Versiyon Kontrol Yazılımını Kullanmalı??

Her şeyden önce, isim onu ​​vermelidir. Sürüm kontrol yazılımı sahip olmanızı sağlar “versiyonları” Zaman içinde kodda yapılan değişiklikleri gösteren ve gerektiğinde geri izlemenizi ve bu değişiklikleri geri almanızı sağlayan bir projenin. Bu yetenek tek başına - iki versiyonu karşılaştırabilmek veya değişiklikleri tersine çevirebilmek, daha büyük projeler üzerinde çalışırken bunu oldukça paha biçilmez kılıyor.

Muhtemelen bunu bir noktada kendin de yaptın, bir projenin kopyalarını farklı noktalardan kurtardın, böylece bir yedeğin olacak. Bir sürüm kontrol sisteminde, sadece değişiklikler kaydedilecekti - bir sonraki sürüme aynı yapmak için bir sürüme uygulanabilecek bir yama dosyası. Bir geliştiriciyle, bu yeterli.

Peki ya bir proje üzerinde çalışan birden fazla geliştiriciniz varsa? İşte o zaman merkezi bir sürüm kontrol sunucusu fikri devreye giriyor. Bunlar uzun süredir standarttı, bu sayede tüm sürümler merkezi bir sunucuda saklanıyor ve bireysel geliştiriciler satın alma ve yükleme işlemlerini bu sunucuya geri yüklüyor. Bir Wikipedia sayfasının düzenleme geçmişine baktıysanız, bunun gerçek dünya senaryosunda nasıl çalıştığı hakkında iyi bir fikriniz olacak:

Bunun gibi bir sistemin faydaları, birden fazla geliştiricinin değişiklik yapabilmesi ve her değişikliğin belirli bir geliştiriciye atfedilebilmesidir. Olumsuz tarafı, her şeyin uzak bir veritabanında depolanması, sunucu kapandığında hiçbir değişiklik yapılamayacağı anlamına gelir; ve eğer merkezi veritabanı kaybedilirse, her müşteri üzerinde çalıştıkları şeyin sadece güncel bir versiyonuna sahiptir..

Bu bizi Git'e götürür ve diğer sözde dağıtılmış versiyon kontrol sistemleri. Bu sistemlerde, istemciler sadece dosyaların geçerli sürümlerini kontrol etmez ve onlardan çalışırlar - tüm sürüm geçmişini yansıtırlar. Her geliştiricinin her zaman her şeyin tam bir kopyası vardır. Merkezi bir sunucu hala kullanılıyor, ancak en kötüsü olması durumunda, her şey en son sürümlere sahip istemcilerden geri yüklenebilir.

Git özellikle alarak çalışır “anlık” dosyaların; Dosyalar belirli bir sürümde değişmeden kalırsa, önceki dosyalara bağlanır - bu her şeyi hızlı ve yalın tutar.

Git'in tüm linux dağıtımlarının yapıldığı temel yapı bloğu olan çekirdek linux çekirdeğini yönetmek ve geliştirmek için kullanıldığını öğrenmek ilginizi çekebilir.

Github Nedir??

Kendi Git sunucunuzu yerel olarak çalıştırabilmenize rağmen, Github hem uzak bir sunucudur, hem de bir geliştiriciler topluluğu ve Git projenizi yönetmek için grafiksel bir web arayüzüdür. Özel projeler için düşük maliyetli planlarla, herhangi biri kodunuzu görüntüleyebildiği veya kodlayabildiği zaman, 5 adede kadar genel depo için ücretsizdir. Kendi hesabınızla oynamaya başlayabilmeniz veya başkasını çatallayabilmeniz için ücretsiz bir hesap açmanızı şiddetle tavsiye ederim..

Çatallanma ve dallanma

Bunlar Git deneyiminin temel kavramları, bu yüzden farkı açıklayalım..

Muhtemelen işi duydun “çatal” linux dağıtımlarıyla uğraşırken. Medya merkezi uygulaması Plex'e aşina iseniz, orijinal olarak benzer bir açık kaynak çatal olduğunu anlayacaksınız. Xbox Media Center Aeon Nox 3.5: XBMC İçin Güzel ve Özelleştirilebilir Tema Aeon Nox 3.5: XBMC İçin Güzel ve Özelleştirilebilir Tema medya merkezinizi tam istediğiniz gibi açın. Aeon Nox 3.5, XBMC için belki de en iyi tema olanın en son sürümüdür ve nadir görülen bir kombinasyondur: güzel…. Bu basitçe, geçmişte bir noktada, bazı geliştiricilerin XBMC kodunu aldıkları ve onunla kendi yollarına gitmeye karar verdikleri anlamına gelir; bu Plex oldu.

Elbette, proje açık kaynak olduğunda buna tamamen izin verilir - kodu alabilir, ne istersen yapabilirsin. Git ile yaptığınız değişikliklerin geri alınacak kadar iyi olduğunu düşünüyorsanız, “ana” proje yapabilir “çekme isteği” yazara, değişikliklerinizi orijinal projelerine geri almalarını isteyin. Bu, herhangi bir noktada bir projede çalışan yüz binlerce geliştiriciye sahip olmanızı sağlar; bunların hiçbiri kod erişimi için gerekli olmayan bir şekilde onaylanması gerekir - bunlar yalnızca kodu kopyalar, değişiklikler yapar ve master'a geri alınmalarını ister. Tabii ki, değişikliklerinizi kabul edip etmemeye karar vermeleri orijinal projenin sahibine kalmış..

Dallanma, yetkili geliştiriciler tarafından bir projede dahili olarak yapılır. Belirli sorunları veya özellikleri kolayca ayırmanıza ve ana dosyaları bozmadan üzerinde çalışmanıza olanak tanır. Şubenizin sorunu çözdüğünden emin olduktan sonra, yeniden master'a birleştirirsiniz. Herhangi bir noktada, istediğiniz kadar dal olabilir; birbirlerine karışmazlar. Ayrıca, dokümanlar arasındaki değişiklikleri master'a dokunmadan da birleştirebilirsiniz..

İşte Vincent Driessen'den örnek bir iş akışının harika bir şeması:

Bir dahaki sefere, çalışan bir Git örneği kurmayı ve dallarda kod değişikliği yapmayı inceleyeceğiz. Sürüm kontrolü çok büyük bir konudur. Burada sadece en kısa özeti verdim, ancak işe yaramazlarsa sadece değişiklik yapmak ve geri almak için kullanılan bir geliştirici olarak, tüm konsept aklımı başımdan alıyor - umarım sizinkini de yapar.

Git'te tecrübeli, tecrübeli bir geliştirici misiniz? Daha yeni başlıyor musun ve gitmek istediğini mi düşünüyorsun? Yorumlarda ses kapalı!