Profesyoneller için Git İş Akışları: İyi Bir Git Kılavuzu

Git, projenizi yalnızca sürüm kontrolü ile değil, aynı zamanda işbirliği ve sürüm yönetimi ile de destekleyebilir. Git iş akışı modellerinin bir projeye nasıl yardımcı olabileceğini veya engelleyebileceğini anlamak, projenizin Git süreçlerini etkili bir şekilde değerlendirme ve uyarlama bilgisini verecektir.

Bu kılavuz boyunca, yaygın Git iş akışlarında bulunan yazılım geliştirme süreci kalıplarını yalıtacağım. Bunların bilgisi, bir geliştirme ekibine katılırken, oluştururken veya büyütürken bir yön bulmanıza yardımcı olacaktır. Belirli türdeki projelerin veya ekiplerin artıları ve eksileri, incelediğimiz iş akışı örneklerinde vurgulanacaktır, böylece senaryonuz için neyin işe yarayabileceğini seçip seçebilirsiniz.

Bu, Git'i kullanmaya giriş değildir. Bunun için zaten harika rehberler ve belgeler var. Halihazırda bir uygulama geliştirme ekibinde deneyiminiz varsa ve iş akışı aksaklıkları, entegrasyon patlamaları veya git-tastrophes ile karşı karşıya kaldıysanız, bu Git iş akışı kılavuzundan yararlanacaksınız - bu modeller gelecekte bu durumlardan nasıl kaçınılacağı konusunda biraz ışık tutabilir.

İşbirliği

Git süreci açısından, işbirliği genellikle iş akışlarını dallara ayırmakla ilgilidir. Taahhüt ağaçlarını nasıl iç içe geçireceğinizi önceden düşünmek, entegrasyon hatalarını en aza indirmenize ve sürüm yönetimi stratejinizi desteklemenize yardımcı olacaktır.

Entegrasyon Şubesi

Katkılar koleksiyonunu tek bir varlık olarak üretime dağıtmaya çalışan yazılım geliştirme ekipleriyle bir entegrasyon şubesi kullanın. Bu, özellikleri tek tek dağıtmaya odaklanan ekiplere karşıdır. Ekipler genellikle ikincisini yapmak isteyebilir, ancak pratik sınırlamalar, çabalarını gruplayan bir süreci zorunlu kılar ve ekip ilkini yapar, bu nedenle bu tür bir işbirliğini kullanmaktan fayda sağlayıp sağlayamayacağınızı görmek için gerçek Git kullanımınızı gözden geçirdiğinizden emin olun. Desen.

Bu iş akışı modeli, birden fazla şubeyi entegre etme riskinin, birleştirilmiş katkıların bir bütün olarak test edilmesini gerektirecek kadar yüksek olduğu durumlar için faydalı bir aşamalandırma noktasıdır.

Bir entegrasyon dalı genellikle bir ana özellikten ve birlikte dağıtılacak birkaç küçük katkıdan oluşur. Geliştirme ekibinizin sürecine bir entegrasyon şubesi koyun (örneğin, Soru-Cevap ve kabul testi). Üretime hazır hale getirmek için küçük taahhütleri üzerine itin ve ardından dağıtıma hazırlamak için bir ortam dalı veya yayın dalı (aşağıda ele alınmıştır) kullanın.

Başka bir ana özelliğin entegrasyon dalında birleştirilebilmesi için entegrasyon dalındaki katkıların bir sonraki yayın aşamasıyla birleştirilmesi gerektiğini unutmayın - aksi takdirde farklı tamamlama aşamalarında özellikleri karıştırmış olursunuz. Bu, hazır olanı serbest bırakma yeteneğinizi engeller.

Konu Branşları

Takımlar, taahhüt ağaçlarını kolayca okunabilecek veya bireysel özellikleri geri döndürülebilecek bir durumda tutmak önemliyse konu dallarını kullanmak isteyeceklerdir. Konu dalları, yapılarını temizlemek ve bir özellik taahhüdüne küçültmek için taahhütlerin üzerine (bir zorlama kullanılarak) yazılabileceğini belirtir.

Konu dalları genellikle bireysel bir katılımcıya aittir, ancak bir ekibin üzerinde bir özellik geliştirmesi için belirlenmiş bir alan da olabilir. Diğer katkıda bulunanlar, bu tür bir dalın taahhüt ağacının her an yeniden yazılabileceğini ve yerel şubelerini onunla senkronize tutmaya çalışmamaları gerektiğini bilirler.

Git iş akışınızda konu dallarını kullanmadan, uzak bir şubeye gönderdiğiniz taahhütlere bağlı kalmakla sınırlandırılırsınız. Yeni bir taahhüt ağacını uzak bir şubeye zorlamak, senkronize oldukları şubenin korunan bütünlüğüne güvenen diğer katkıda bulunanları kızdırabilir.

Bu iş akışı modelini farkında olmadan kullanma ihtimaliniz yüksek, ancak arkalarındaki uygulamaları güçlendirmek için ekipler arasında paylaşılan bir tanım kümesine sahip olmaya değer. Örneğin, dal oluşturucunun baş harfleriyle dal adının önüne koyma kuralını, hangi konunun dalları olduğunu belirtmek için yardımcı olduğunu bulabilirsiniz. Her iki durumda da, dahili kurallara karar vermek ekibinize kalmış.

Genel depolarda konu dallarını KULLANMAYIN , yerel dallarını, taahhüt ağacını yeniden yazmış bir konu dalı ile senkronize eden herkes için sayısız çatışmaya neden olursunuz.

Çatal

Açık kaynak projeleri, Github kaynaklı bu özelliği kullanarak gelişir. Çatal , depo bakımcılarını doğrudan bir kaynak depo şubesine zorlama konusunda zorunlu bir ağ geçidi ile güçlendirir, ancak daha da önemlisi işbirliğini kolaylaştırır. Vay canına!

Kendinizi, özel bir depodan bir çatal oluşturmanın da ihtiyaçlarınıza uygun olduğu senaryoda bulabilirsiniz. Kaynak deposunu çatal deposuna katkıda bulunanlar için salt okunur olarak ayarlamak ve çekme istekleriyle yuvarlanmak, size açık kaynak topluluğunun sağladığı avantajların aynısını sağlar. Farklı kuruluşlardan ekipler, iletişim ve proje politikasına bağlılık için bir platform olabilecek bir çatal kullanarak etkili bir şekilde çalışabilir.

Fork iş akışı deseni, ekiplere iki depo arasında tek bir entegrasyon noktası olan bir çekme talebi ile alışkın oldukları şekilde çalışacakları kendi alanlarını verir. Çekme isteği açıklamasında aşırı iletişim zorunludur. Ekipler, bir çekme talebi gönderilmeden önce ayrı iletişim akışlarına sahipti ve halihazırda verilmiş olan kararların vurgulanması inceleme sürecini hızlandıracak.

Tabii ki çatal iş akışının bir yararı, izinler aşağı doğru basamaklandığından, yorumları Origin deposuna katkıda bulunanlara yönlendirebilmenizdir. Origin deposunun bakış açısından, artık ihtiyaç duyulmadığında çatalları silme kontrolüne sahipsiniz.

Bu kalıptan yararlanmak için çatallama ve çekme isteklerini kolaylaştıran bir araç kullandığınızdan emin olun. Bu araçlar Github ile sınırlı değildir: diğer popüler seçenekler Bitbucket ve GitlLab'dır. Ancak bu özelliklere (veya benzerlerine) sahip olacak birkaç başka Git iş akışı barındırma hizmeti var. Hangi hizmetin sizin için en uygun olduğunu seçin.

Bir ekibin her üyesi için özel bir deponun çatalını KULLANMAYIN . Çok sayıda çatallı depo, birden çok üyenin aynı özellik dalında işbirliği yapmasını zorlaştırabilir ve tüm bu depoları senkronize tutmak, hareketli parçaların çok fazla olması nedeniyle hataya açık hale gelebilir. Açık kaynak projeleri, bu ek yükü azaltan, Origin deposuna anında erişime sahip çekirdek ekip üyelerine sahiptir.

Klon

Ortak bir dış kaynak kullanımı stratejisi, birden fazla yazılım geliştiricisi tarafından doldurulabilecek bir projeye katkı “koltuklarına” sahip olmaktır. Sözleşmeli saatleri teslim etmek için kaynak boru hattını yönetmek dış kaynak kullanma şirketine bağlıdır, karşılaştıkları sorunlar, her müşterinin projeleri için bir geliştirici havuzunu nasıl hazırlayacakları, eğitecekleri ve sürdürecekleridir.

Proje havuzunun bir klonunun kullanılması, dışarıdan sağlanan ekibin katkılarını yönetmesi, politikaları uygulaması ve bilgi paylaşımından faydalanması için izole bir eğitim ve iletişim zemini sunar - hepsi de müşterinin geliştirme ekibinin gözetimi altında. Bir katkı standart olarak kabul edildiğinde ve ana veri havuzu için hazır olduğunda, kaynak veri havuzlarının uzak şubelerinden birine itilebilir ve her zamanki gibi entegre edilebilir.

Bazı projelerin, kodlama kurallarına uyma konusunda yüksek beklentileri vardır ve havuzlarına katkıda bulunmak için Git iş akışı standartlarını tanımlamıştır. İpleri öğrenene kadar bu ortamda çalışmak göz korkutucu olabilir, bu nedenle her iki tarafın zamanını optimize etmek için bir ekip olarak birlikte çalışın.

İzinleri olmadan müşterinin deposunun barındırılan bir kopyasını OLUŞTURMAYIN, sözleşmeye dayalı bir anlaşmayı bozuyor olabilirsiniz, bu uygulamanın müşteriyle projeye fayda sağlayacağını önceden doğrulayın.

Sürüm Yönetimi

İşbirliğinden yayına geçiş arasındaki adımlar, her ekip için geliştirme süreci içinde farklı noktalarda başlayacaktır. Genel olarak, birden fazla yayın yönetimi Git kalıbı kullanmak istemezsiniz. Ekibinizin etkili bir şekilde teslim etmesini sağlayacak mümkün olan en basit iş akışına sahip olmak istiyorsunuz.

Çevre Şubeleri

Yazılım geliştirme süreciniz, üretime dağıtılmadan önce kalite güvencesine yardımcı olmak için çeşitli ortamlar tarafından desteklenebilir. Çevre dalları bu sürecin aşamalarını taklit eder: her aşama bir şubeye karşılık gelir ve katkılar bir boru hattında bunlardan akar.

Bu süreçlerle çalışan ekipler, genellikle ardışık düzendeki her aşama için, örneğin “QA”, “Hazırlama” ve “Üretim” için ayarlanmış uygulama ortamlarına sahiptir. Bu durumlarda, üretime hazır olmanın ne anlama geldiğine ilişkin kendi dilimleri için bir özelliğin veya katkının imzalanmasından sorumlu personeli desteklemek için altyapı mevcuttur (örneğin keşif testi, QA, kabul testi), sonraki kişinin hizmetine geçmeden önce. sahne. Bu, onlara imza tüneli boyunca yolculuğunu kaydetmek için bir Git iş akışıyla kendi gereksinimlerine göre dağıtmak, test etmek ve değerlendirmek için kendi yerlerini verir.

Bir birim olarak bir sürüm için çalışabilen küçük ekipler için sürecin her aşaması için bir şubeye sahip olmak uygundur. Ne yazık ki, bunun gibi bir boru hattı çok kolay bir şekilde darboğaz yapabilir veya bir araya gelip boşluklar bırakabilir. Git işleminizi altyapınızla birleştirir, bu da özellik hızlandırma gerektirdiğinde ve her iki işlemin de ölçeklenmesi gerektiğinde sorunlara neden olabilir.

İlk önce diğer kalıpların uzun vadeli faydalarını düşünmeden bu kalıbı KULLANMAYIN .

Yayın Dalları

Birbirini takip eden sprintlerde bir birim olarak üretim uygulamalarına bir katkı koleksiyonunu iten bir ekip, serbest bırakma dallarını uygun bulabilir.

Neredeyse "üretime hazır" taahhütlerin bir koleksiyonuna, bir sürüm dalında küçük hata düzeltmeleri verilir. Kesinleştirme ağacını bir yayın dalına taşımadan önce özellikleri birleştirmek ve test etmek için bir tümleştirme dalı kullanın. Sürüm dalının sorumluluğunu, üretim uygulamasına dağıtımdan önce son bir kontrol olarak sınırlayın.

Serbest bırakma dalları, kısa bir ömre sahip olmaları nedeniyle çevre dallarından farklıdır. Yayın dalları yalnızca gerektiğinde oluşturulur ve taahhüt ağacı üretime dağıtıldıktan sonra yok edilir.

Serbest bırakma dallarının yazılım geliştirme yol haritanıza bağlanmasını önlemeye çalışın. Kendinizi önceden belirlenmiş bir planı takip etmekle sınırlamak, planlanan tüm özellikler üretime hazır olana kadar bir sürümün dağıtımını geciktirir. Bir sürüm dalı oluşturmadan önce yol haritasına bir sürüm numarası atamamak, üretime hazır özelliklerin bir yayın dalına yerleştirilip dağıtılmasına izin vererek bu tür gecikmeleri azaltabilir.

Deponun hangi sürümünün üretime dağıtıldığını açıkça belirtmek için sürüm dalı adı için bir sürüm numarası adlandırma kuralı kullanın.

Yayın dalını değil ana dalı dağıtın. Ana dal ile birleştirmeden önce yayın dallarında küçük düzeltmeler yapmayı teşvik etmek için, güncellenmiş taahhüt ağacını üretime otomatik olarak dağıtmak için bir birleştirme gerçekleştikten sonra tetiklemek için ana dalda bir Git kancası kullanın.

Belirli bir anda yalnızca bir yayın dalının var olmasına izin vermek, birden fazla yayın dalını birbiriyle senkronize tutmanın ek yükünü ortadan kaldırmanızı sağlar.

Aynı depoda çalışan birden fazla ekiple sürüm dallarını KULLANMAYIN . Serbest bırakma dalları kısa ömürlü olsa da, son kontrol çok uzun sürerse, diğer takımı serbest bırakmaktan alıkoyuyor. Başka bir takımın yayın dalını destekleyen bir takım domuzu, muhtemelen hatalara neden olabilir ve her iki takım için de gecikmelere neden olabilir. Daha fazla sayıda ve katkıda bulunan gruplar için daha iyi çalışan aşağıdaki zaman damgalı yayın modeline bakın.

Zaman Damgalı Sürümler

Altyapı kısıtlamalarına sahip uygulamalar, dağıtımlarını genellikle trafiğin düşük olduğu dönemlerde planlar. Projeniz, dağıtılmaya hazır düzenli özellik kuyruklarıyla karşı karşıyaysa, zaman damgalı sürümleri kullanmaktan yararlanabilirsiniz.

Zaman damgalı bir yayın, üretime dağıtılan ana daldaki son işleme otomatik olarak bir zaman damgası etiketi eklemek için dağıtım sürecine dayanır. Konu dalları, konuşlandırmayı beklemek üzere ana dalla birleştirilmeden önce bir özelliği geliştirme sürecinden geçirmek için kullanılır.

Zaman damgası etiketi, gerçek bir zaman damgası ve bir dağıtımı temsil ettiğini gösteren bir etiket içermelidir, örneğin: deployed-201402121345 .

Ana dalın taahhüt ağacındaki zaman damgası etiketi biçimindeki dağıtım meta verilerinin dahil edilmesi, üretim uygulamasında yayınlanan gerilemelerde hata ayıklamada size yardımcı olacaktır. Sorunun nedenini araştırmakla görevlendirilen kişinin, üretim uygulamasında dağıtılan her bir hat hakkında çok fazla bilgi sahibi olması olası değildir. Son iki etikette bir git diff komutu çalıştırmak, en son hangi taahhütlerin dağıtıldığının ve sorunun çözülmesine yardımcı olabilecek taahhüt yazarlarının kimler olduğunun hızlı bir şekilde anlık görüntüsünü verebilir.

Zaman damgalı dallar, yüzeyde göründüklerinden daha fazladır. Sıraya alınmış özelliklerin dağıtımını kaydetmek için basit bir mekanizma, onu yürütmek için şaşırtıcı miktarda iyi süreç gerektirir. Süreç, küçük bir katkıda bulunanlar ekibiyle de ölçeklenebilen ve iyi çalışan bir süreçtir.

Bu Git iş akışı modelinin gerçekten etkili olması için ana dalın her zaman konuşlandırılabilir olması gerekir. Bu, ekibiniz için farklı şeyler anlamına gelebilir, ancak esasen tüm taahhütler, ana dalda sona ermeden önce proje geliştirme sürecinizden geçmiş olmalıdır.

Ana şubeye inen yeni taahhütler günde birkaç kez gerçekleşecek. Bu, geliştirme sürecinden geçen ve bu süre içinde ana dal ile senkronize edilmemiş konu dalları için bir sorundur. Ne yazık ki böyle bir senaryo, birleştirme çakışmaları yanlış bir şekilde ele alındığında ana dalda gerilemelere neden olabilir.

Bir konu dalı ile ana dalı arasında birleştirme çakışmaları ortaya çıkarsa, uzak ana dalı güncellemeden önce yeni bir hatanın ortaya çıkma riski ekibinizle tartışılmalıdır. Bir gerilemenin meydana gelebileceğine dair herhangi bir şüphe varsa, o zaman konu dalı, birleştirme çakışmaları çözülerek kalite güvence sürecinden geçirilebilir.

Entegrasyon hatalarını azaltmak için, havuzun ilgili bölümlerinde çalışan geliştiriciler, konu dallarını ana dal ile en iyi ne zaman birleştirip senkronize edecekleri konusunda işbirliği yapabilir. Entegrasyon dalları, ilgili konu dallarından gelen çakışmaları çözmek için de iyi çalışır - bunlar, dağıtım bekleyen ana daldaki kuyruğa birleştirilmeden önce test sürecinden geçirilmelidir.

Birçok katılımcının olduğu yazılım geliştirme projeleri, pratik ve verimli yaklaşımlarla işbirliği ve sürüm yönetimi süreçleriyle uğraşmak zorundadır. Zaman damgalı sürümleri kullanmaktan elde ettiğimiz taahhüt ağacındaki ek meta veriler, üretim sorunlarına yanıt vermeye hazırlanan ekiplerin öngörülerine yönelik bir işarettir.

Sürüm Şube

Yalnızca üretimde çalıştırdığınız değil, diğerlerinin de kendi barındırılan uygulamaları için kullandığı bir deponuz varsa, sürüm dallarını kullanmak, ekibinize uygulamanızın geliştirmelerinin en uç noktasında kalmayan veya kalamayan kullanıcıları destekleyecek bir platform sağlayabilir. .

Sürüm dallarını kullanan bir havuzda, uygulamanın alt sürümü başına bir dal bulunur. Majör, minör ve yama sürümleri Semantik Sürüm Oluşturma belgelerinde açıklanmıştır. Sürüm dalları tipik olarak "kararlı" kelimesini eklemek ve uygulama sürümünden yama numarasını çıkarmak için bir adlandırma kuralı izler: örneğin amaçlarını ve güvenilirliğini son kullanıcılar için açık hale getirmek için 2-3-stable .

Git etiketleri, uygulamanın yama sürüm numarasına kadar uygulanabilir, ancak sürüm dalları o kadar ince taneli değildir. Bir sürüm dalı, desteklenen bir alt sürüm için her zaman en kararlı taahhüdü gösterir.

Güvenlik yamaları veya yedekleme işlevselliği ihtiyacı ortaya çıktığında, desteklediğiniz eski uygulama sürümleri için çalışmak için gerekli taahhütleri bir araya getirin ve bunları sırasıyla sürüm şubelerinize itin.

Deponuzun birden fazla sürümünü desteklemediğiniz sürece sürüm dallarını KULLANMAYIN .

Özet

Ekibiniz boyut değiştirdiğinde veya projeniz sürekli değerlendirme yoluyla süreçlerini geliştirdiğinde Git sürecinizi de değerlendirmeyi ihmal etmeyin. Git iş akışı doğruluğu yolunda sizi yönlendirmeye yardımcı olması için bu öğreticideki kalıpları bir başlangıç ​​noktası olarak kullanın.

Bu kılavuzdaki model, dağıtılmış sürüm kontrol sisteminizi sizin için çalışacak şekilde uyarlama konusunda biraz öngörü kazanmanıza yardımcı olabilir. Git iş akışları hakkında bilgi almak istiyorsanız Gitflow, Github Flow ve en önemlisi muhteşem git-scm belgelerine göz atmayı unutmayın!