Gelişmiş Git Akışı Açıklaması

Git ile istemeden hasar vermek çok kolay olabilir. Yine de Git'i kullanmanın en iyi yolu her zaman tartışmalı olacaktır.

Bunun nedeni, Git'in yalnızca temel dallanma işlemlerini detaylandırmasıdır, bu da kullanım kalıplarını (yani dallanma modellerini) bir kullanıcı görüşü meselesi haline getirir. Git dallanma modelleri, yazılım geliştiriciler kod tabanlarında değişiklik yaparken kaçınılmaz olarak ortaya çıkan kaosu düzenleyerek acıyı hafifletmeyi vaat ediyor.

Pek çok geliştirici gibi siz de gerçek yazılım geliştirmeye devam edebilmek için "sadece işe yarayacak" bir şey istediniz. Böylece Git kullanıcılarına sıklıkla önerilen bir dallanma modeli olan Git akışını aldınız. Belki de pratikte bazı engellerle karşılaşana kadar ilk başta Git akışının mantığıyla aynı fikirdeydiniz. Veya Git akışı, onu benimsemeniz için yeterince uygun görünmüyor. Sonuçta, oyunda sayısız değişken var ve her durumda tek bir dallanma modeli iyi çalışmayacak.

İyi haberler! Klasik Git akış modelinin bir varyasyonu olan gelişmiş Git akışı , Git akışı iş akışının daha yaygın manevralarını basitleştirirken ana avantajları korur.

Klasik Git Akış Modelinin İhtişamı ve Sefaleti

Önemli değer artışlarıyla (başka bir deyişle, sürümler ) gelişen bir ürün geliştirirken nasıl mükemmel olduğunu keşfettiğimden beri Git akışının güçlü bir savunucusu oldum.

Önemli bir değer artışı, Scrum tabanlı geliştirmede tipik olarak kullanılan iki haftalık artı sprintler gibi, tamamlanması için önemli miktarda zaman gerektirir. Bir geliştirme ekibi üretime zaten konuşlandırdıysa, sonraki sürümün kapsamı, üretim kodunun bulunduğu yerde (örneğin, kullandıkları Git deposunun ana dalında) birikirse sorun olabilir.

Ürün hala ilk geliştirme aşamasındayken (yani, üretim yok ve ürünün gerçek kullanıcıları yok), ekibin her şeyi ana dalda tutması sorun değil. Aslında, sorun değil: Bu strateji, çok fazla tören olmadan en hızlı gelişme hızına izin verir. Ancak üretim ortamında işler değişir; sonra, gerçek insanlar ürünün istikrarlı olmasına güvenmeye başlar.

Örneğin, üretimde hemen düzeltilmesi gereken kritik bir hata varsa, geliştirme ekibinin yalnızca düzeltmeyi dağıtmak için o ana kadar ana dalda tahakkuk eden tüm çalışmaları geri alması büyük bir felaket olur. Ve kodu, ister yarım kalmış ister iyi geliştirilmiş olarak kabul edilsin, uygun testler yapılmadan dağıtmak, açıkça bir seçenek değildir.

Git akışı da dahil olmak üzere dallanma modellerinin parladığı yer burasıdır. Herhangi bir karmaşık dallanma modeli, bir sonraki sürümün insanlar tarafından halihazırda kullanılan sistem sürümünden nasıl yalıtılacağı , bu sürümün bir sonraki sürümle nasıl güncelleneceği ve mevcut sürüme herhangi bir kritik hata düzeltmelerinin nasıl ekleneceği ile ilgili soruları yanıtlamalıdır.

Git akış süreci, "ana" (üretim veya "geçerli sürüm" dalı) ve "develop" (geliştirme veya "sonraki sürüm" dalı) ayırarak ve özellik/yayın/düzeltme dallarının kullanımına ilişkin tüm kuralları sağlayarak bu temel senaryoları ele alır. . Sürüme dayalı ürünlerin geliştirme iş akışlarından kaynaklanan birçok baş ağrısını etkin bir şekilde çözer.

Ancak klasik Git akış modeline çok uygun projelerde bile, getirebileceği tipik sorunları yaşadım:

• Git akışı, iki uzun ömürlü dal, üç tür geçici dal ve dalların birbirleriyle nasıl başa çıktığına dair katı kurallar ile karmaşıktır. Böyle bir karmaşıklık, hataları daha olası hale getirir ve bunları düzeltmek için gereken çabayı artırır.
• Yayın ve düzeltme dalları, önce ana, sonra geliştirme olmak üzere "çift birleştirme" gerektirir. Bazen ikisini de yapmayı unutabilirsiniz. Git akışının dallanmasını komut dosyaları veya VCS GUI istemci eklentileriyle kolaylaştırabilirsiniz, ancak bunları önce belirli bir projede yer alan her geliştiricinin her makinesi için ayarlamanız gerekir.
• CI/CD iş akışlarında, genellikle bir sürüm için iki son derleme elde edersiniz - biri sürüm dalının en son taahhüdünden ve diğeri de main'e birleştirme taahhüdünden. Kesin konuşmak gerekirse, ana olandan birini kullanmalısınız, ancak ikisi genellikle aynıdır, bu da kafa karışıklığı potansiyeli yaratır.

“Gelişmiş Git Akışı” girin

Gelişmiş Git akışını ilk kullandığımda sıfırdan, kapalı kaynaklı bir projedeydi. Başka bir geliştiriciyle çalışıyordum ve doğrudan ana şubeye taahhüt vererek proje üzerinde çalışıyorduk.

Not: Bir ürünün ilk genel kullanıma sunulmasına kadar, geliştirme iş akışının hızı ve basitliği adına, Git akışı savunucusu olsanız bile tüm değişiklikleri doğrudan ana dalda yapmak kesinlikle mantıklıdır. Henüz üretim olmadığından, ekibin en kısa zamanda düzeltmesi gereken bir üretim hatası olasılığı yoktur. Klasik Git akışının ima ettiği tüm dallanma sihrini yapmak bu nedenle bu aşamada aşırıya kaçar.

Ardından ilk sürüme yaklaştık ve bu noktadan sonra doğrudan ana şubeye bağlanma konusunda artık rahat olmayacağımız konusunda anlaştık. Oldukça hızlı hareket etmiştik ve iş öncelikleri, kaya gibi sağlam bir geliştirme süreci oluşturmak için fazla yer bırakmadı - yani, ana şubemizi yayına hazır durumda tutan güveni bize verecek yeterli otomatik teste sahip bir süreç.

Klasik Git akış modeli için geçerli bir durum gibi görünüyordu. Ayrı ana ve geliştirme dalları ve önemli değer artışları arasında yeterli zaman olduğu için, çoğunlukla manuel KG'nin yeterince iyi sonuçlar vereceğine dair güven vardı. Git akışını savunduğumda, meslektaşım benzer bir şey önerdi, ancak bazı önemli farklılıklar vardı.

İlk başta geri çekildim. Bana klasik Git akışına önerilen bazı “yamalar” biraz fazla devrimci gibi geldi. Ana fikri bozabileceklerini ve tüm yaklaşımın yetersiz kalacağını düşündüm. Ancak biraz daha düşününce, bu ince ayarların Git akışını gerçekten bozmadığını fark ettim. Bu arada, yukarıda belirtilen tüm sorunlu noktaları çözerek onu daha iyi bir Git dallanma modeli haline getiriyorlar.

Bu projedeki değiştirilmiş yaklaşımla başarı elde ettikten sonra, onu arkasında küçük bir ekiple başka bir kapalı kaynak projesinde kullandım, burada kalıcı kod tabanı sahibiydim ve zaman zaman bir veya iki dış kaynaklı geliştiriciye yardım ettim. Bu projede, altı ay içinde üretime geçtik ve o zamandan beri, yaklaşık her ay yayınlanan sürümlerle, bir yıldan fazla bir süredir CI ve E2E testlerini kullanıyoruz.

Bu yeni dallanma yaklaşımıyla ilgili genel deneyimim o kadar olumluydu ki, klasik Git akışının dezavantajlarını aşmalarına yardımcı olmak için geliştirici arkadaşlarımla paylaşmak istedim.

Klasik Git Akışı ile Benzerlikler: Geliştirme İzolasyonu

Gelişmiş Git akışında iş yalıtımı için, ana ve geliştirme olmak üzere hala iki uzun ömürlü dal vardır. (Kullanıcıların hala düzeltme ve yayın yetenekleri vardır - bunlar artık dal olmadıklarından “yeteneklere” vurgu yapılır. Ayrıntılara farklılıklar bölümünde gireceğiz.)

Klasik Git akışı özellik dalları için resmi bir adlandırma şeması yoktur. Özellik hazır olduğunda geliştirmek için geliştirmeden ayrılır ve tekrar birleşirsiniz. Ekipler, istedikleri herhangi bir adlandırma kuralını kullanabilir veya geliştiricilerin "şubem"den daha açıklayıcı adlar kullanmasını umabilir. Aynısı gelişmiş Git akışı için de geçerlidir.

Geliştirme dalında bir kesme noktasına kadar biriken tüm özellikler yeni sürümü şekillendirecektir.

Squash Birleştirmeleri

Geçmişi çoğu zaman güzel ve doğrusal tutmak için özellik dalları için squash merge kullanılmasını şiddetle tavsiye ettim. Onsuz, grafikleri (GUI araçlarından veya git log --graph 'dan) bir takım bir avuç özellik dalı ile hokkabazlık yaparken özensiz görünmeye başlar:

Ancak bu senaryodaki görseller sizin için uygun olsa bile, ezmek için başka bir neden daha var. Ezmeden, geçmiş görünümleri işleyin - bunların arasında hem düz git log ( --graph olmadan) hem de GitHub - en basit birleştirme senaryolarında bile oldukça tutarsız hikayeler anlatın:

Squash birleştirmeyi kullanmanın uyarısı, orijinal özellik dalı geçmişinin kaybolmasıdır. Ancak bu uyarı, örneğin, özellik dalının kendisi silindikten sonra bile, birleştirilmiş çekme isteği aracılığıyla bir özellik dalının tüm orijinal geçmişini ortaya çıkaran GitHub kullanıyorsanız bile geçerli değildir.

Klasik Git Akışından Farklar: Sürümler ve Düzeltmeler

Yapacağınız asıl şey bu olduğu için (umarım) sürüm döngüsünden geçelim. Geliştirmede birikmiş olanı serbest bırakmak istediğimiz noktaya geldiğimizde, bu kesinlikle bir ana kümedir. Klasik ve gelişmiş Git akışı arasındaki en büyük farklar bundan sonra başlar.

Gelişmiş Git Akışındaki Sürümler

Gelişmiş Git akışıyla sürüm oluşturmanın her adımı, klasik Git akışı sürecinden farklıdır:

1. Sürümler, geliştirme yerine ana temele dayalıdır. Ana dalın mevcut ucunu anlamlı bir şeyle etiketleyin . ISO 8601 biçimindeki geçerli tarihe dayalı olarak "v" ön ekine sahip etiketleri kabul ettim - örneğin, v2020-09-09 .
   • Bir günde birden fazla yayın (örneğin, düzeltmeler) olması durumunda, formatın üzerine gerektiğinde sıralı bir sayı veya harf eklenebilir.
   • Etiketlerin genel olarak yayın tarihlerine karşılık gelmediğini unutmayın. Sadece Git'i, bir sonraki yayın süreci başladığında ana dalın nasıl göründüğüne dair bir referans tutmaya zorlamak içindir.
2. etiketi git push origin <the new tag name> kullanarak itin.
3. Bundan sonra biraz sürpriz: yerel ana şubenizi silin . Endişelenme, çünkü onu kısa süre içinde geri yükleyeceğiz.
   • main'e yönelik tüm taahhütler hala güvenlidir; önceki adımda main'i etiketleyerek onları çöp toplamaya karşı koruduk. Bu taahhütlerin her biri - hatta birazdan ele alacağımız gibi düzeltmeler - aynı zamanda geliştirmenin bir parçasıdır.
   • Herhangi bir sürüm için bir ekipte yalnızca bir kişinin bunu yaptığından emin olun; bu, sözde "sürüm yöneticisi" rolüdür. Bir sürüm yöneticisi genellikle en deneyimli ve/veya en kıdemli ekip üyesidir, ancak bir ekip, belirli bir ekip üyesinin bu rolü kalıcı olarak üstlenmesini önlemek akıllıca olacaktır. Kötü şöhretli otobüs faktörünü artırmak için bilgiyi ekip arasında yaymak daha mantıklı.
4. Geliştirme şubenizin uç taahhüdünde yeni bir yerel ana şube oluşturun .
5. Bu yeni yapıyı git push --force kullanarak zorlayın , çünkü uzak depo böyle bir "sert değişikliği" o kadar kolay kabul etmeyecektir. Yine, bu, bu bağlamda göründüğü kadar güvenli değildir çünkü:
   • Yalnızca ana dal işaretçisini bir taahhütten diğerine taşıyoruz.
   • Bu değişikliği aynı anda yalnızca belirli bir ekip üyesi yapıyor.
   • Geliştirme dalında günlük geliştirme çalışmaları yapılır, bu nedenle ana yolu bu şekilde hareket ettirerek kimsenin işini aksatmazsınız.
6. Yeni sürümünüz var! Hazırlama ortamına dağıtın ve test edin. (Aşağıda uygun CI/CD modellerini tartışacağız.) Herhangi bir düzeltme doğrudan ana dala gider ve bu nedenle geliştirme dalından ayrılmaya başlar.
   • Aynı zamanda, klasik Git akışında görülen avantajın aynısı olan geliştirme dalında yeni bir sürüm üzerinde çalışmaya başlayabilirsiniz.
   • Bu noktada, şu anda üretimde olan (gelecekteki sürüm değil) için bir düzeltmenin gerekli olması durumunda, aşağıdaki "Etkin bir sürüm sırasında düzeltmelerle uğraşma..." bölümünde bu senaryo hakkında daha fazla ayrıntı bulunmaktadır.
7. Yeni sürümünüz yeterince kararlı olduğu düşünüldüğünde , son sürümü üretim ortamına dağıtın ve tüm düzeltmeleri almak için ana geliştirme için tek bir squash birleştirme yapın .

Gelişmiş Git Akışındaki Düzeltmeler

Düzeltme durumları iki yönlüdür. Etkin sürüm olmadığında bir düzeltme yapıyorsanız (yani, ekip geliştirme dalında yeni bir sürüm hazırlıyorsa), bu çok kolay: Ana işlemi yapın, değişikliklerinizi dağıtın ve hazır olana kadar aşamalandırmada test edin, ardından üretime dağıtın.

Son adım olarak, bir sonraki sürümün tüm düzeltmeleri içerdiğinden emin olmak için geliştirme taahhüdünüzü main'den özenle seçin. Sonunda birkaç düzeltme işlemiyle karşılaşırsanız, özellikle IDE veya diğer Git aracınız bunu kolaylaştırabiliyorsa, birden çok kez kiraz toplamak yerine bir yama oluşturup uygulayarak çabadan tasarruf edersiniz. İlk sürümden sonra geliştirmek için ana birleştirmeyi ezmeye çalışmak, geliştirme dalında yapılan bağımsız ilerlemeyle çatışmalarla sonuçlanabilir, bu yüzden bunu önermiyorum.

Etkin bir sürüm sırasında düzeltmelerle uğraşmak (yani, yalnızca ana öğeye basmaya zorladığınızda ve hala yeni sürümü hazırlarken) gelişmiş Git akışının en zayıf kısmıdır. Sürüm döngünüzün uzunluğuna ve çözmeniz gereken sorunun ciddiyetine bağlı olarak, her zaman yeni sürümün kendisine düzeltmeler eklemeyi hedefleyin; bu en kolay yoldur ve genel iş akışını hiç bozmaz.

Bunun mümkün olmadığı durumlarda—çabuk bir düzeltme yapmanız gerekiyor ve yeni sürümün hazırlanmasını bekleyemezsiniz—sonra biraz karmaşık Git prosedürü için hazırlanın:

1. Bir dal oluşturun; buna “yeni sürüm” diyeceğiz, ancak ekibiniz burada herhangi bir adlandırma kuralını benimseyebilir - şu anki main ipucuyla aynı taahhütte. Yeni sürümü itin.
2. Geçerli etkin sürüm için daha önce oluşturduğunuz etiketin taahhüdünde yerel ana dalı silin ve yeniden oluşturun. Ana itmeye zorlayın.
3. Ana işlem, hazırlama ortamına dağıtma ve test için gerekli düzeltmeleri tanıtın. Ne zaman hazır olursa, üretime dağıtın.
4. Değişiklikleri mevcut ana sürümden yeni sürüme ya kiraz toplama ya da bir yama yoluyla yayın.
5. Bundan sonra, yayın prosedürünü yeniden yapın: Mevcut ana dizinin ucunu etiketleyin ve etiketi itin, yeni yayın dalının ucundaki yerel ana iletiyi silip yeniden oluşturun ve ana itmeye zorlayın.
   1. Muhtemelen önceki etikete ihtiyacınız olmayacak, böylece onu kaldırabilirsiniz.
   2. Yeni sürüm dalı artık gereksizdir, böylece onu da kaldırabilirsiniz.
6. Artık yeni bir sürümle her zamanki gibi gitmekte fayda var. Kiraz toplama veya bir yama yoluyla acil durum düzeltmelerini main'den geliştirmeye yayarak bitirin.

Doğru planlama, yeterince yüksek kod kalitesi ve sağlıklı bir geliştirme ve KG kültürü ile ekibinizin bu yöntemi kullanması pek olası değildir. Her ihtimale karşı, gelişmiş Git akışı için böyle bir felaket planını geliştirmek ve test etmek akıllıcaydı - ancak bunu pratikte kullanmam hiç gerekmedi.

Gelişmiş Git Akışının Üstünde CI/CD Kurulumu

Her proje özel bir geliştirme ortamı gerektirmez. Her geliştirici makinesinde karmaşık bir yerel geliştirme ortamı kurmak yeterince kolay olabilir.

Ancak özel bir geliştirme ortamı, daha sağlıklı bir geliştirme kültürüne katkıda bulunabilir. Geliştirme dalında testler yürütmek, test kapsamını ölçmek ve karmaşıklık metriklerini hesaplamak, genellikle hataların maliyetini, onları aşamaya geçmeden çok önce yakalayarak azaltır.

Gelişmiş Git akışıyla birleştirildiğinde özellikle yararlı olacak bazı CI/CD kalıpları buldum:

• Bir geliştirme ortamına ihtiyacınız varsa, geliştirme dalına yönelik her taahhütte onu oluşturmak, test etmek ve dağıtmak için CI kurun. E2E testine sahipseniz ve sizin durumunuzda mantıklıysa buraya da sığdırın.
• Ana şubeye yapılan her taahhütte hazırlama ortamını oluşturmak, test etmek ve dağıtmak için CI'yi ayarlayın. E2E testi de bu noktada oldukça faydalıdır.
  • Her iki yerde de E2E testini kullanmak gereksiz görünebilir, ancak geliştirme sırasında düzeltmelerin olmayacağını unutmayın. Taahhütlerde E2E'yi main'de tetiklemek, düzeltmeleri ve günlük değişiklikleri çıkmadan önce test edecek, ancak aynı zamanda geliştirmeleri tetiklemek hataları daha erken yakalayacaktır.
• CI'yi, ekibinizin manuel bir istek üzerine derlemeleri ana ortamdan üretim ortamına dağıtmasına olanak tanıyacak şekilde yapılandırın.

Bu tür modeller nispeten basittir, ancak günlük geliştirme operasyonlarını desteklemek için güçlü makineler sağlar.

Gelişmiş Git Akış Modeli: İyileştirmeler ve Olası Sınırlamalar

Gelişmiş Git akışı herkes için değildir. Ana dalı iten tartışmalı güç taktiğinden yararlanıyor, bu yüzden saflar buna kızabilir. Pratik bir bakış açısından, bununla birlikte yanlış bir şey yok.

Belirtildiği gibi, düzeltmeler bir sürüm sırasında daha zorlayıcıdır ancak yine de mümkündür. Çok sık olmaması gereken KG, test kapsamı vb. hususlara gereken özen gösterildiğinde, benim açımdan bu, klasik Git akışına kıyasla gelişmiş Git akışının genel faydaları için geçerli bir ödünleşimdir. Git akışının daha büyük ekiplerde ve düzeltmelerin daha sık meydana gelebileceği daha karmaşık projelerde ne kadar gelişmiş olduğunu duymak çok ilgimi çeker.

Gelişmiş Git akış modeliyle ilgili olumlu deneyimim de çoğunlukla kapalı kaynaklı ticari projeler etrafında dönüyor. Çekme isteklerinin genellikle kaynak ağacın eski bir sürüm türevine dayandığı açık kaynaklı bir proje için sorunlu olabilir. Bunu çözmek için teknik bir engel yok - sadece beklenenden daha fazla çaba gerektirebilir. Bu gibi durumlarda gelişmiş Git akışının uygulanabilirliği konusunda açık kaynak alanında çok fazla deneyime sahip okuyuculardan gelen geri bildirimleri memnuniyetle karşılıyorum.

Toptal meslektaşı Antoine Pham'a, geliştirilmiş Git akışının arkasındaki fikri geliştirmedeki kilit rolü için özel teşekkürler.

Toptal Mühendislik Blogunda Daha Fazla Okuma:

• Trunk Tabanlı Geliştirme ve Git Akışı
• Profesyoneller için Git İş Akışları: İyi Bir Git Kılavuzu

Bir Microsoft Altın İş Ortağı olarak Toptal, Microsoft uzmanlarından oluşan seçkin ağınızdır. İhtiyacınız olan uzmanlarla yüksek performanslı ekipler oluşturun - her yerde ve tam olarak ihtiyacınız olduğunda!