Sürüm Kontrolü ve Git'e Giriş

Google Dokümanlar'a aşina mısınız? Eğer öyleyseniz, yazarların ve ilgili kişilerin belgede yapılan tüm değişiklikleri kontrol etmelerini ve takip etmelerini sağlayan küçük 'Sürüm Geçmişi' sekmesiyle haberdar olduğunuzu varsaymak güvenlidir. zaman içinde herhangi bir noktada. Kullanışlı bir araç, değil mi?

Şimdi bir sayfa dolusu paragraf yerine, yüzlerce satır kodla dolu dosyalar olduğunu hayal edin. Ve tek bir dokümanın aksine, sürekli güncellenen tonlarca farklı dosya var.

Böyle bir senaryoda, binlerce kod satırının oynandığı ve nihai sonucun, yani Mobil uygulamanın bir işletmenin geleceğine bağlı olduğu bir senaryoda, tüm değişikliklerin bir sekmesini tutacak bir yazılıma sahip olmak daha da önemli hale gelir. kod dosyalarında yapılmıştır.

Bu, bir Sürüm Kontrol Yazılımının resme girdiği yerdir.

Yazılım Geliştirmede Sürüm Kontrolü Neden Önemlidir?

Adından da anlaşılacağı gibi, bir Sürüm Kontrol Yazılımı, mobil uygulama geliştiricilerinin yazılım geliştirme döngüsünün farklı sürümlerini izlemesine ve bunlarda değişiklik yapmasına olanak tanır. Bu, kodda meydana gelen tüm değişiklikleri izleme yeteneği ve ardından değişiklikleri geri alma seçeneği, Sürüm Kontrolünü bir mobil uygulama geliştirme şirketinin birden çok geliştiriciyi içeren sürecinin önemli bir parçası yapan şeydir.

Şimdi, Sürüm Kontrolü söz konusu olduğunda, şu anda piyasada bulunan bir dizi yazılım var. Bunlardan bazılarına bakalım -

Sürüm Kontrolü için Kullanılabilir Yazılım

Dağıtılmış yazılımın lideri GitLab Anketinde, kullanıcıların %98'inin Git açık kaynak araçlarını kullandığını ve geliştiricilerin %92'sinden fazlasının uygulama geliştirme sürecinde Git'i sürüm kontrol dili olarak kullandığını tespit etmesine rağmen, bir dizi geliştiricilerin Git alternatifine bakmalarının nedenleri. Bu nedenlerden bazıları, GitHub fiyatlandırma yapısından ve Github'ın hem iOS hem de Android'de piyasaya sürülmesinden, Octocat'a karşı bir isteksizlikten veya Git olmayan sürüm kontrol diliyle basit bir rahatlık seviyesinden farklılık gösterebilir.

Nedeniniz ne olursa olsun, sürüm kontrolü için Git'in alternatifi burada:

Şimdi, Sürüm Kontrolü ve Appinventiv'de bir dizi alternatif mevcut olduğunda bile, bunların çoğu üzerinde ilk elden çalışma deneyimimiz var, değişen müşteri gereksinimleri nedeniyle, gerçekten Git'e karşı kısmiyiz. Sana nedenini söyleyeyim.

Appinventiv Sürüm Kontrolü için Neden Git'i Kullanıyor?

1. Yıldırım Hızı İçin

Piyasadaki tüm sürüm kontrol yazılımlarının dışında, Git günlüğü ve Commit öğelerinin çalışma hızı diğerleriyle kıyaslanamaz. Ve geliştirici ekibiniz bir platform üzerinde çalışırken, yazılımın hızlı olması kesinlikle gerekli hale gelir.

2. Çevrimdışı Çalışma Yeteneği İçin

İnternete dayalı bir yazılım üzerinde çalıştığınızda, hareket halindeyken riskli olabilir ve merkezi depoyla bağlantınızı kaybedersiniz. Ancak Git'te durum böyle değil. Git ile yerel makinenizdeki hemen hemen tüm görevleri yapabilirsiniz - taahhütte bulunun, proje geçmişine göz atın, dal oluşturun veya birleştirin.

3. Geri Alma Yardımı İçin

Git, tüm taahhüdü düzeltmenize ve geri almanıza izin veren bir 'geri al' komutuyla birlikte gelir. Aslında, Reflog seçeneği aracılığıyla 'silinmiş' taahhüdü geri yükleme seçeneği bile sunar.

4. Yedekleme İçin

Ekip Git üzerinde çalışırken, ekibin makinesinde bulunan her bir klon, kullanılabilir bir yedekle birlikte gelir. Buna ek olarak, hemen hemen her Git eylemi yalnızca verileri ekler ve silmez.

5. Yararlı Taahhütlerde Bulunmak İçin

Geliştirici ekibimiz bir dizi ilgisiz değişiklik yaptığında (bazı özellikleri A'dan alarak, diğerinde bazı hata düzeltmeleri yaparak) diğer ekip üyelerinin ne olduğunu anlaması çok zor olabilir ve geri almaları zor olabilir. Sorunlara neden oluyorsa A'nın özellikleri.

Git, bu karışıklığı ayrıntılı taahhüt oluşturarak çözer. 'Aşama alanı' konsepti sayesinde, tek satırlara bakmak zorunda kalsanız bile, bir sonraki işleme hangi değişikliklerin dahil edileceğini kolayca bulabilirsiniz.

İşte Appinventiv'de Git'i kullanmamızın beş ana nedeni bunlardı. Şimdi nedenine baktık, Nasıl'a bakmanın zamanı geldi. Git'i Sürüm Kontrol Sürecimize nasıl dahil ediyoruz.

Şimdi buna gelelim.

Git Kullanırken Sürüm Kontrol Süreci

Depo Oluşturma

Git'in amacı, bir dizi dosyayı, yani Project'i yönetmektir. Bunu yapmak için Git, tüm bilgileri Repository olarak bilinen veri yapısında saklar. Bir depo, uygulamanın kaynak kodlarından, kaynaklardan ve veri kümelerinden oluşur. Temel olarak, uygulama projesini tanımlayan her şeye sahiptir.

Şimdi Git'te bir havuz almanın iki yolu var. Yerel bir dizin kullanabilir ve komut satırını kullanarak onu Git deposuna dönüştürebilir veya önceden yüklenmiş bir Git deposunu kendinize kopyalayabilirsiniz.

Bir depo oluşturduğunuzda, genellikle iki seçeneğiniz olur - Genel ve Özel. Genel depo, Git kullanan diğer geliştiriciler tarafından görüntülenebilen, Özel depo ise yalnızca birkaç kişi tarafından görüntülenebilen depodur.

Dallanma

Depo Oluşturma'nın yanında Dallanma var. Appinventiv gibi bir şirkette, herhangi bir zamanda 15-20'den fazla geliştiricinin bir proje üzerinde çalıştığı bir şirkette, geliştiricilerin aynı kaynak kodunu paylaşması ve üzerinde çalışması nadir değildir. Olan şu ki, bazı geliştiriciler sorunları çözmekle meşgulken, diğerleri bazı özellikleri uyguluyor olabilir.

Böyle bir durumda, aynı kod tabanında farklı kod sürümlerini yönetmeyi kolaylaştıran bir sisteme ihtiyacımız var.

Gitflow'un resme girdiği yer burasıdır. Gitflow , sistematik ve verimli bir şekilde dallanma için kullanılan bir çerçevedir.

Gitflow'ta Dallanma işleminin nasıl çalıştığına geçmeden önce, kavramı bir örnekle açıklamama izin verin.

Diyelim ki ekibinizde 5 geliştirici var ve bir Instagram benzeri uygulama geliştirmek için çalışıyorlar. Artık, Feed ve Bildirimler gibi bireysel uygulama özellikleri Modül 1, Modül 2 ve benzeri olarak gösterilir. Şimdi bu farklı modüller, üzerinde çalıştıktan sonra ana dal veya Master ile birleştirilen geliştirme dallarıdır.

Bir geliştirici bir dal eklediğinde, çalışmalarını ekip üyelerinden ayıran bağımsız bir geliştirme hattı oluşturur. Farklı dallar daha sonra ana dalda birleştirilir.

Dallanma, ekip üyelerinin hangi değişiklikleri beklemeleri gerektiğini belirlemelerini sağlayan ve geriye dönük izlemeyi kolaylaştıran yöntemdir.

Projelerimizde genellikle bu dalları tutuyoruz –

• Ana Şube
• Geliştirme Şubesi
• Özellik Dal
• Yayın Şubesi
• Yeni Düzeltmeler ve Hata Düzeltmeleri

İşlemek

Bir geliştiricinin bireysel dosyada yaptığı değişiklikler, Taahhüt olarak bilinir. Değişiklikler veya taahhüt, sunucuya değil yerel depoya eklenir. Ardından, geliştiricilerimiz, taahhüdün (dosyada yapılan değişikliklerin) açıklamasının yayınlandığı bir taahhüt mesajı yazma alışkanlığını takip eder, böylece diğer geliştiriciler de dosyada yapılan değişikliklerin ayrıntılarını bilir.

İtmek

Yerel Git deposunda taahhütte bulunduğunuzda, daha sonra olan şey, değişikliklerin daha sonra Push olarak bilinen sunucuya gönderilmesidir .

Bir dosya üzerinde çalışan tek kişi olduğunuzda, taahhüt geçmişini sunucuya göndermek oldukça kolaydır, ancak sürece dahil olan başka geliştiriciler de olması durumunda, setinizi zorlamadan önce değişiklikleri çekmeniz gerekecektir. Git'e taahhüt et.

Ardından, Pull Change adımında neler yapıldığına bakacağız.

Çekme İsteği

Aynı dosya üzerinde birden fazla geliştirici çalıştığında, siz onları göndermeden önce bazı taahhütler diğer geliştirici tarafından sunucuya aktarılabilir. Ve bu olduğunda, çatışma olur (bununla ilgili daha fazla bilgi daha sonra).

Aynı kod tabanını sunucuya iki kez yüklemekten kaçınmak için geliştiriciler önce değişiklikleri depodan alır ve kodların farklı olduğundan emin olur. Şimdi, genellikle, iki veya daha fazla geliştirici aynı dosya üzerinde çalıştığında ve sunucudaki taahhütlerini zorladığında, 'Birleştirme' seçeneği geliyor.

Şimdi Merge hakkında konuşalım.

Birleştirmek

Birleştirme, geliştiricilerin tüm dalları önce birbirleriyle ve sonra ana veya ana dal ile birleştirdiği adımdır.

Bir teslimat bir Push komutuna her girdiğinde, bir Merge seçeneği alırlar ve bu da onlara taahhüdü birleştirmek istedikleri dalı sorar.

Şimdi Birleştirme aşamasında, Çatışma oluşumu çok yaygındır. Çakışma genellikle birleştirmeyi planladığınız iki dalın aynı dosyada aynı bölümde değişmesi durumunda ortaya çıkar. Burada olan, Git'in hangi sürümün kullanılması gerektiğini çözememesidir.

Bu Çakışma sorunu geldiğinde Git iki çözüm sunar - Otomatik ve Manuel.

Adından da anlaşılacağı gibi, biri Git'in sorunun kendisini bulduğu yerdir ve ikincisinde geliştiricilerin bunu manuel olarak yapması gerekir. Appinventiv'de, hata oluşma olasılığını bile ortadan kaldırdığı için, Çatışmanın Manüel olarak çözülmesine odaklanıyoruz.

Uygulama geliştirme sürecimizin sürüm kontrolünü yapmak için Git'i kullanırken, aynı anda olan şey Sorun İzlemedir.

Agile'ın büyük bir takipçisi olduğumuz ve mobil uygulama geliştirme sürecimiz için Agile'a güvendiğimiz için , aynı anda birden fazla geliştirme sürecini ele almanın önemini anlıyoruz. Sorun izleme özelliği sayesinde, test kullanıcılarının Git sunucusuna yazılan ve gönderilen kodu gerçek zamanlı olarak incelemeleri çok daha kolay hale geliyor.

Her depodaki iş akışını izlemek için ZenHub panosunu kullanıyoruz. Pano, önerilen değişikliğin önceliğini takip etmemize ve geliştiricilerin panodaki yorumlarını gerçek zamanlı olarak güncellemelerine yardımcı olur.