Karışıklık olmadan ekip çalışması: Git'te dallanma stratejilerini anlama

giriiş

Git, yazılım geliştirmede sürüm kontrol sistemleri için fiili endüstri standardı haline geldi. Öncelikle Git'in ne olduğu ve nasıl başlanacağı ile ilgili yazımı okumalısınız . Onu okudun mu? Harika, hadi başlayalım! Beğenin ya da beğenmeyin, Linus Tovalds tarafından oluşturulan bu araç kullanımdan kalkmayacak. Bu nedenle, dağıtık ekiplerin Git ile nasıl çalıştığı ve bunun için hangi dallanma stratejisini seçmeleri gerektiği hakkında konuşmak mantıklıdır. Bu önemsiz bir soru değil. Daha önce birlikte çalışmamış yeni bir geliştirme ekibi kurarken, dallanma stratejisi genellikle karar verilmesi gereken ilk şeylerden biridir. Ve bazı insanlar bir stratejinin diğerinden daha iyi olduğunu kanıtlamak için ağızlarından köpürecekler. Bu yüzden size onlar hakkında bazı genel bilgiler aktarmak istiyorum.

Dallanma stratejileri gerekli mi?

Gerçekten gerekliler. Çok gerekli. Çünkü ekip bir konuda anlaşamazsa, o zaman her ekip üyesi istediğini yapacaktır:

• hangi şubede çalışıyor
• keyfi diğer dallara birleştirme
• bazı dalları silme
• yenilerini yaratmak
• ve böylece her ekip üyesi yönetilmeyen bir akış içinde hareket edecektir.

Bu nedenle, aşağıda dikkate almamız gereken üç stratejimiz var. Hadi gidelim!

GitHub Akışı

Bu dallanma stratejisi, garip bir şekilde, GitHub'da tercih ediliyor :) Bir dizi kuralla geliyor :

1. Master dalındaki kod kırılmamalıdır. Herhangi bir zamanda konuşlandırılmaya hazır olmalıdır. Yani, projeyi oluşturmanıza ve sunucuya dağıtmanıza engel olacak bir kod koymamalısınız.
2. Yeni işlevsellik üzerinde çalışmayı planladığınızda, ana dalı temel alan yeni bir özellik dalı oluşturmanız ve buna anlamlı bir ad vermeniz gerekir. Kodunuzu yerel olarak işleyin ve değişikliklerinizi uzak havuzdaki aynı dala düzenli olarak gönderin.
3. İşin hazır olduğunu düşündüğünüzde ve ana dalda birleştirilebileceğini düşündüğünüzde (veya emin değilseniz, ancak yapılan iş hakkında geri bildirim almak istiyorsanız) bir çekme isteği açın (çekme isteklerini buradan okuyabilirsiniz ) .
4. Çekme isteğindeki yeni özellik onaylandıktan sonra ana dalda birleştirilebilir.
5. Değişiklikler ana şubede birleştirildiğinde, sunucuya hemen dağıtılmalıdır.

GitHub Flow'a göre, ister bir düzeltme ister yeni bir özellik olsun, yeni bir şey üzerinde çalışmaya başlamadan önce, master tabanlı yeni bir dal oluşturmanız ve ona uygun bir ad vermeniz gerekir. Ardından, uygulama üzerinde çalışma başlar. Sürekli olarak uzak sunucuya aynı ada sahip taahhütler göndermelisiniz. Her şeyin hazır olduğuna karar verdiğinizde, master şubeye bir çekme isteği oluşturmanız gerekir. O zaman en az bir veya daha iyisi iki kişi "Onayla" düğmesini tıklamadan önce bu koda bakmalıdır. Genellikle projenin ekip lideri ve ikinci bir kişinin mutlaka göz atması gerekir. Ardından çekme isteğini tamamlayabilirsiniz. GitHub Flow, projelerde sürekli teslimatı (CD) desteklemesiyle de bilinir . Bunun nedeni, değişikliklerin ana şubeye gittiğinde, sunucuya hemen dağıtılmaları gerektiğidir.

GitFlow

Önceki strateji (GitHub Flow) özünde çok karmaşık değil. İki tür dal vardır: ana dal ve özellik dalları. Ancak GitFlow daha ciddidir. En azından yukarıdaki resim bunu netleştirmeli :) Peki bu strateji nasıl çalışıyor? Genel olarak GitFlow, iki kalıcı daldan ve birkaç geçici dal türünden oluşur. GitHub Flow bağlamında, ana şube kalıcıdır ve diğerleri geçicidir. kalıcı şubeler

• usta: Bu dala kimse bir şey değmesin, itmesin. Bu stratejide master, üretimde (yani gerçek bir sunucuda) kullanılan en son kararlı sürümü temsil eder.
• geliştirme: geliştirme dalı. Kararsız olabilir.

Geliştirme, üç yardımcı geçici dal kullanılarak gerçekleşir :

1. Özellik dalları — yeni işlevler geliştirmek için.
2. Sürüm dalları — projenin yeni bir sürümünün yayınlanmasına hazırlanmak için.
3. Düzeltme dalları — gerçek kullanıcılar tarafından gerçek bir sunucuda bulunan bir hatayı hızlı bir şekilde düzeltmek için.

Özellik dalları

Özellik dalları, geliştiriciler tarafından yeni işlevler için oluşturulur. Her zaman geliştirme şubesine göre oluşturulmalıdırlar. Yeni işlevsellik üzerinde çalışmayı tamamladıktan sonra, geliştirme şubesine bir çekme isteği oluşturmanız gerekir. Açıkçası, büyük ekiplerin aynı anda birden fazla özellik dalı olabilir. GitFlow stratejisi açıklamasının başındaki resme bir kez daha bakın.

Şubeleri serbest bırakın

Geliştirme dalında gerekli yeni özellikler seti hazır olduğunda, ürünün yeni sürümünün yayınlanması için hazırlanabilirsiniz. Geliştirme dalına bağlı olarak oluşturulan bir yayın şubesi bu konuda bize yardımcı olacaktır. Sürüm dalı ile çalışırken, tüm hataları bulmanız ve düzeltmeniz gerekir. Sürüm dalını dengelemek için gerekli olan tüm yeni değişiklikler de geliştirme dalına geri birleştirilmelidir. Bu, geliştirme şubesini de stabilize etmek için yapılır. Test edenler, dalın yeni bir sürüm için yeterince kararlı olduğunu söylediğinde, ana dalla birleştirilir. Daha sonra bu taahhüt için sürüm numarası atanan bir etiket oluşturulur. Bir örnek görmek için, stratejinin başındaki resme bakın. Orada Etiket 1.0'ı göreceksiniz— bu yalnızca projenin 1.0 sürümünü gösteren bir etikettir. Ve son olarak, düzeltme şubemiz var.

Düzeltme dalları

Düzeltme dalları ayrıca, ana dalda yeni bir sürüm yayınlamak içindir. Tek fark, bu sürümlerin planlanmamış olmasıdır. Hataların yayınlanan sürüme girdiği ve üretim ortamında keşfedildiği durumlar vardır. İOS'u ele alalım: yeni bir sürüm yayınlanır yayınlanmaz, sürümden sonra bulunan hatalar için düzeltmeler içeren bir dizi güncelleme alırsınız. Buna göre, bir hatayı hızlı bir şekilde düzeltmemiz ve yeni bir sürüm yayınlamamız gerekiyor. Resmimizde bu, 1.0.1 sürümüne karşılık gelir. Buradaki fikir, yeni işlevsellik üzerindeki çalışmanın, gerçek bir sunucuda (veya dediğimiz gibi, "üretimde" veya "üretimde") bir hatayı düzeltmek gerektiğinde durması gerekmemesidir. Düzeltme dalı, şu anda üretimde çalışmakta olanı temsil ettiğinden, ana daldan oluşturulmalıdır. Hata düzeltmesi hazır olur olmaz, master ile birleştirilir ve yeni bir etiket oluşturulur. Tıpkı bir sürüm dalını hazırlamak gibi, bir düzeltme dalının da düzeltmesini geliştirme dalıyla birleştirmesi gerekir.

Çatal iş akışı

Çatallama iş akışında, geliştirme iki havuz içerir:

1. Tüm değişikliklerin birleştirileceği orijinal havuz.
2. Bir çatal deposu. Bu, orijinalde değişiklik yapmak isteyen başka bir geliştiriciye ait olan orijinal deponun bir kopyasıdır.

Şimdiye kadar biraz garip geliyor, değil mi? Daha önce açık kaynak geliştirmeyle karşılaşan herkes bu yaklaşıma zaten aşinadır. Bu strateji şu avantajı sağlar: geliştirme, orijinal şubede ortak geliştirme için izinler verilmeden bir çatal deposunda gerçekleşebilir. Doğal olarak, orijinal havuzun sahibi önerilen değişiklikleri reddetme hakkına sahiptir. Veya onları kabul etmek ve birleştirmek için. Bu, hem orijinal havuzun sahibi hem de ürünü oluşturmaya yardımcı olmak isteyen geliştirici için uygundur. Örneğin, Linux çekirdeğinde değişiklikler önerebilirsiniz . Linus mantıklı olduğuna karar verirse, değişiklikler eklenecektir (!!!).

Çatallama iş akışına bir örnek

Kullanmak istediğiniz bir kitaplık olduğunda GitHub'da çatallanma iş akışı uygulanır. Tamamen kullanmanızı engelleyen bir bug var. Sorunun yeterince derinine indiğinizi ve çözümü bildiğinizi varsayalım. Çatallama iş akışını kullanarak, kitaplığın orijinal deposunda çalışma hakları olmadan sorunu çözebilirsiniz. Başlamak için, örneğin Spring Framework gibi bir havuz seçmeniz gerekir . Sağ üst köşedeki "Çatal" düğmesini bulun ve tıklayın: Bu biraz zaman alacaktır. Ardından, kişisel hesabınızda orijinal havuzun bir kopyası görünecek ve bunun bir çatal olduğunu belirtecektir:Artık bu havuzla her zamanki gibi çalışabilir, ana şubeye değişiklikler ekleyebilir ve her şey hazır olduğunda, orijinal depoya bir çekme isteği oluşturabilirsiniz. Bunu yapmak için Yeni çekme isteği düğmesine tıklayın:

Hangi stratejiyi seçmeli

Git, çok çeşitli süreçler ve stratejiler kullanarak çalışmanıza izin veren esnek ve güçlü bir araçtır. Ancak ne kadar çok seçeneğiniz varsa, hangi stratejiyi seçeceğinize karar vermek o kadar zor olur. Herkes için tek bir cevap olmadığı açıktır. Her şey duruma bağlıdır. Bununla birlikte, bu konuda yardımcı olabilecek birkaç yönerge vardır:

1. Önce en basit stratejiyi seçmek en iyisidir. Yalnızca gerektiğinde daha karmaşık stratejilere geçin.
2. Geliştiriciler için mümkün olduğunca az şube türüne sahip stratejiler düşünün.
3. Çeşitli stratejilerin artılarına ve eksilerine bakın ve ardından projeniz için ihtiyacınız olanı seçin.

Git'teki dallanma stratejileri hakkında söylemek istediklerim bu kadar. İlginiz için teşekkürler :) Çalışmalarımda kullandığım farklı teknolojiler ve araçları içeren kreasyonlarımı sık sık yayınladığım GitHub'da beni takip edin .