Versiyon Kontrol Sistemleri - Git
Günümüzde çok yaygın kullanılan versiyon kontrol sistemleri nedir ve bir yazılımcı olarak bu sistemden nasıl faydalanırız hangi ihtiyaçlarımızı karşılar bu gibi konulara değineceğim. Keyifli okumalar 🤚
Neden İhtiyaç Duyarız?
Temel olarak aşağıdaki maddeleri verebiliriz fakat tabi ki bunlar dışında karşıladığı farklı gereksinimlerde bulunmaktadır.
- Belirli zamanlarda önceki versiyonları elde etmek ve bunlarla karşılaştırma yapmak (Bu ihtiyaç için bir çok durum vardır örneğin hata durumunda geçmişe yönelik inceleme yapılmak istendiğinde, bir geliştirme kapsamında hangi sınıflarda değişiklik olduğunu izleyebilme gibi..)
- Aynı projede birden fazla kişi çalışmak (bireysel olarak çalışsa bile bir noktadan sonra kodların ortak bir yerde toplanması gerekmektedir, bu süreci manuel olarak yürütmek meşakkatli ve tehlikelidir.)
- Bir proje üzerinde aynı anda farklı özellikler geliştirmek(Projeye yeni bir özellik eklerken aynı zamanda bir hata(defect) geldiğinde bu iki geliştirmenin paralel ve çakışmadan iletilmesini sağlamak buna örnektir.)
Nedir?
Genel bir tanım yapacak olursak; değişikliklerin geçmişini ve kimin yapıldığını düzgün bir şekilde saklar, bunlara istenilen zamanda erişilebilmesine olanak sağlar. Birbirinden farklı süreçlerde, farklı kişiler tarafından yapılan geliştirmeleri otomatik şekilde birleştirme işlemini yapar.
Herhangi bir versiyon kontrol sistemi kullanmadan bir yazılım projesi geliştirmek çok zordur, kaldı ki sadece yazılım projelerinde değil bir çok dokümanın saklanmasında ve iletilmesinde de kullanılmaktadır. Git de bu versiyon kontrol sistemlerinden biridir. Şimdi git yapısını ve komutlarını biraz daha detaylı inceleyelim.
Makinenize git kurulumu yaptığınızda aslında client kısmını oluşturmuş oluyoruz aşağıda resimde gördüğünüz Local Repo olarak adlandırılan yerde bu işlemleri yapmış olacağız. Remote Repo ise git i server tarafta konumlandırdığımız kısım oluyor. Örneğin GitHub, bitbucket, gitlab sunucu tarafında ki süreçleri yönettiğimiz ortamlardır.
git üzerinde repository oluşturmak için farklı yöntemler vardır; mevcutta var olan bir projeyi remote repository den clone işlemi yaparak localde oluşturulabilirsiniz yada sıfırdan git init ile mevcut klasörünüzü repository olarak tanımlayabilirsiniz. Bu işlemi yaptığınızda klasör altında .git adında klasör oluştuğunu gözlemleyebilirsiniz.
🎆 Bu adımdan sonra artık elimizde local repository bulunuyor. Buradaki dosyalar üzerinde yaptığımız işlemler working tree çalışma alanı olarak adlandırdığımız kısımda tutuluyor. Bu değişiklikleri staging area kısmına almak için de eğer komut kullanıyorsak add işleminden yararlanabiliriz.
Resimde komutlar ile süreçler ifade edilmiş fakat kişisel görüşüm git süreçlerini yönetebildiğimiz çok güzel uygulamalar bulunuyor. Bunların ara yüzleri hem kullanışlı hem de çok daha hızlı bir şekilde süreçleri yönetebiliyorsunuz. Bunlardan SmartGit, Sourcetree benim severek kullandıklarım. Uygulamalarda işlemler bu komut adları ile tanımlandığı için çok kısa sürede adapte olunabilir.
🎆 Bir değişikliği commit edebilmek için staging area ya aktarılmış olması gerekmektedir. commit ettiğimizde ise bu değişiklik halen sadece client tarafta görünürdür yani remote repository e henüz aktarılmamıştır. Herhangi bir nedenden ötürü makinenizde bulunan git de bir sorun yaşarsanız bu değişikliği kaybetme durumunuz bulunuyor.
🎆 commit edilmiş bir değişikliği remote repository e aktarma işlemi de push olarak tanımlanmaktadır. Bunla birlikte artık yaptığınız değişiklikler herkes tarafından görünebilir ve güvendedir.
🎆 Şuana kadar localden remote a doğru akışı inceledik peki tersi yönde nasıl bir süreç bulunuyor. Yani remote da bulunan bir değişikliği local e nasıl alırız. Bunun bir yolu fetch işlemi ile remote daki değişiklikleri remote tracking branch ine aktarılması ve oradan da merge işlemi ile working tree ye getirilmesidir.
Diğer bir yolda aslında fetch + merge işlevini tek seferde yapan pull işlemidir. Remote repodaki değişiklikleri her türlü local brach ile birleştirmek istiyorsak bu kullanılabilir fakat remote daki değişikliği ilk önce fetch ile alıp kontrol yada değişiklik sonrası merge etmek istediğimizde ise ilk yolu tercih edebiliriz.
Bir proje üzerinde çalıştığımızda genelde bunu farklı ortamlarda test etme ihtiyacı duyarız. Örneğin bir geliştirme ortamı olur ve yazılımcı burada birim testini ve diğer testlerini gerçekleştirir. Sonrasında fonksiyonel yada kullanıcı kabul testi(UAT) için farklı ortamlara aktarılır, en son canlı ortama çıkartılır. Aslında tek bir repository bulunuyor fakat bu ortamlarda kodun farklı sürümleri çalışacak şekilde planlama yapabiliyoruz. Bunu aşağıdaki gibi gitflow mekanizmasını kullanarak gerçekleştirebiliriz.
Özel isimlendirilmiş olsa da bunların hepsi temelde bir branch olarak oluşturulmaktadır. Kullanım mantığı gereği özelleştirilmiş gibi düşünülebilir.
Her git projesi başlangıçta tek bir main branch den oluşmaktadır. Yeni bir branch oluşturulduğunda aslında yeni bir pointer oluşturmuş oluruz, repository geçmişi olduğu gibi kalır.
- Main; Canlı sürüm geçmişini sağlar. Aktif çalışan uygulamanın anlık kodları bu branch üzerinde saklanır. Buraya yapılacak commit ler tag ile yapılmalıdır.
- Develop; Yapılan bütün geliştirmeleri ortak olarak bulundurur. Feature lar için entegrasyon branch olarak görev yapar.
- Feature; Develop branch den kopya alınarak oluşturulur ve tamamlandığında yine buraya merge işlemi gerçekleştirilir.
Uygulama için yeni bir özellik/talep geldi bunun için feature oluşturup orada geliştirmelerimiz bitene kadar commit yaparak çalışmaya devam edebiliriz. Talebi tamamladığımızda(Finish Feature) ise bu branch i sonlandırarak develop branch ine otomatik olarak aktarırız. Ek olarak feature da yaptığımız tüm geliştirmelerin tek commit olarak develop branchde gözükmesini de sağlayabiliyoruz.
- Hotfix; Canlıdaki hataları gidermek için oluşturulur. Main branch den kopyalanır ve sonunda ona merge işlemi gerçekleştirilir. Bu branch de yapılan geliştirmeler tamamlandığında develop branchine de otomatik merge işlemi gerçekleştirilmiş olur.
- Release; Develop branchinden oluşur. Bir sonraki sürümde çıkacak geliştirmeleri içerir. Ek olarak sadece hata çözümleri, diğer sürümlerden kaynaklı geliştirmeler eklenebilir yeni özellik eklenemez.
Eğer IDE kullanıyorsanız mutlaka aşağıdaki gibi GitFlow konfigürasyonu için menü de bir alan görürsünüz. Bu ayarlamayı yaparak yukarıda bahsettiğimiz branch leri otomatik oluşturabilir ve yapıyı kullanmaya başlayabilirsiniz.
