Git dallanma stratejisini benimseyin

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Git gibi dağıtılmış sürüm denetimi sistemleri, kodu paylaşmak ve yönetmek için sürüm denetimini kullanma konusunda size esneklik sağlar. Ekibinizin bu esneklik ile işbirliği yapma ve kodu tutarlı bir şekilde paylaşma ihtiyacı arasında bir denge bulması gerekir.

Ekip üyeleri, başkalarıyla paylaşılan Git dalları aracılığıyla kod değişikliklerini yayımlar, paylaşır, gözden geçirir ve yineler. Ekibiniz için bir dallanma stratejisi benimseyin. Daha iyi işbirliği yapabilir ve sürüm denetimini yönetmek için daha az zaman harcayabilir ve kod geliştirmeye daha fazla zaman ayırabilirsiniz.

Aşağıdaki dallanma stratejileri, Microsoft'ta Git'i kullanma şeklimizi temel alır. Daha fazla bilgi için bkz. Microsoft 'da Git'i kullanma şeklimiz.

Tavsiye

Azure DevOps görevlerine yardımcı olması için yapay zekayı kullanabilirsiniz. Başlamak için bkz. Azure DevOps MCP Sunucusu ile yapay zeka yardımlarını etkinleştirme .

Dal stratejinizi basit tutun

Dal stratejinizi basit tutun. Stratejinizi şu üç kavramdan oluşturun:

• Tüm yeni özellikler ve hata düzeltmeleri için özellik dallarını kullanın.
• Pull isteklerini kullanarak özellik dallarını ana dallara birleştirin.
• Yüksek kaliteli, up-togüncel bir ana dal tutun.

Bu kavramları genişleten ve çelişkileri önleyen bir strateji, ekibiniz için tutarlı ve takip etmek kolay bir sürüm denetimi iş akışına neden olur.

Çalışmanız için özellik dallarını kullanma

Ana dalınızı temel alarak özellik dallarında özelliklerinizi geliştirin ve hataları düzeltin. Bu dallar, konu dalları olarak da bilinir. Özellik dalları, devam eden çalışmayı ana daldaki tamamlanan çalışmadan ayırır. Git dallarını oluşturmak ve bakımını yapmak maliyeti düşüktür. Küçük düzeltmeler ve değişiklikler bile kendi özellik dallarına sahip olmalıdır.

Temel dallanma iş akışıimage of basic branching workflowgörüntüsü

Tüm değişiklikleriniz için özellik dalları oluşturmak, geçmişin gözden geçirilmesini kolaylaştırır. Dalda yapılan commitlere ve dalı birleştiren pull requeste bakın.

Özellik dallarınızı kurala göre adlandırma

Dalda yapılan işleri tanımlamak için özellik dallarınız için tutarlı bir adlandırma kuralı kullanın. Dal adına, dalı kimin oluşturduğu gibi başka bilgiler de ekleyebilirsiniz.

Özellik dallarınızı adlandırmak için bazı öneriler:

• kullanıcılar/kullanıcı adı/açıklama
• users/username/iş öğesi
• hata düzeltmesi/açıklaması
• özellik/özellik-adı
• feature/feature-area/feature-name
• hata düzeltmesi/açıklama

Uyarı

Dal adlandırma stratejisini zorunlu kılmak için ilkeleri ayarlama hakkında bilgi için, bkz. Dal klasörlerini zorunlu kılma.

Uzun süre çalışan dalları yönetmek için özellik bayraklarını kullanma

Kodunuzda özellik bayrakları kullanarak hakkında daha fazla bilgi edinin.

Çekme istekleriyle kodu gözden geçirme ve birleştirme

Pull request içerisinde gerçekleşen gözden geçirme, kod kalitesini geliştirmek için kritik öneme sahiptir. Yalnızca inceleme sürecinizi geçen pull requestlerle dalları birleştirin. Çekme isteği olmadan dalları ana dala birleştirmekten kaçının.

Çekme taleplerindeki incelemelerin tamamlanması zaman alır. Ekibiniz, çekme isteği oluşturucuları ve gözden geçirenlerden neler beklendiği konusunda anlaşmalıdır. Ekibiniz genelinde fikir paylaşmak ve kod tabanınızla ilgili bilgileri yaymak için gözden geçiren sorumluluklarını dağıtın.

Başarılı çekme istekleri için bazı öneriler:

• Araştırma 'e göre en uygun sayıiki değerlendiricidir.
• Ekibinizin zaten bir kod gözden geçirme işlemi varsa, çekme isteklerini yaptığınız işlemlere entegre edin.
• Aynı gözden geçirenleri çok sayıda çekme isteğine atamaya dikkat edin. Gözden geçirenlerin sorumlulukları ekip genelinde paylaşıldığında pull request'ler daha iyi çalışır.
• Değişikliklerinizi hızla anlamaları için inceleme yapanlara açıklamada yeterli ayrıntı sağlayın.
• Çekme isteğinizle birlikte, değişikliklerinizin aşamalı bir ortamda çalışan derlemesini veya bağlı sürümünü ekleyin. Diğerleri değişiklikleri kolayca test edebilir.

Yüksek kaliteli, güncel bir up-toana şube tutun

Ana dalınızdaki kod testleri geçmeli, temiz bir şekilde derlenmeli ve her zaman güncel olmalıdır. Ekibiniz tarafından oluşturulan özellik dallarının bilinen iyi bir kod sürümünden başlaması için ana dalınızın bu özelliklere ihtiyacı vardır.

Ana dalınız için dal politikası oluşturun:

• Kodu birleştirmek için çekme isteği gerekir. Bu yaklaşım, ana dala doğrudan göndermeyi önler ve önerilen değişikliklerin tartışılmasını sağlar.
• Pull isteği oluşturulunca gözden geçirenleri otomatik olarak ekler. Eklenen ekip üyeleri kodu inceler ve çekme isteğindeki değişiklikler hakkında yorum yapar.
• Başarılı bir derleme, bir pull isteğini tamamlamak için gereklidir. Ana dala aktarılmış kod sorunsuz derlenmelidir.

Tavsiye

Çekme isteklerinizin derleme işlem hattı hızlı bir şekilde tamamlanmalıdır, bu nedenle gözden geçirme işlemine müdahale etmez.

Yayınları yönet

Kodunuzun bir sürümündeki değişiklikleri koordine etmek ve istikrarlı hale getirmek için yayın dallarını kullanın. Bu dal uzun ömürlüdür ve, özellik dallarının aksine, bir çekme isteğinde ana dal ile birleştirilmez. İhtiyacınız olan sayıda yayın dalı oluşturun. Her etkin yayın dalının, desteklemeniz gereken kodun başka bir sürümünü temsil ettiğini unutmayın. Belirli bir sürümü desteklemeyi durdurmaya hazır olduğunuzda yayın dallarını kilitleyin.

Yayın dallarını kullan.

Yayınınıza veya sprint'in sonu gibi başka bir kilometre taşına yaklaştığınızda ana daldan bir yayın dalı oluşturun. Bu dala yayınla ilişkilendirerek net bir ad verin, örneğin release/20.

Yayın dalındaki hataları düzeltmek için dallar oluşturun ve ardından bunları bir çekme isteğiyle yayın dalına tekrar birleştirin.

yayın dalı iş akışlarının

Port ana dala geri değişir

Düzeltmelerin hem yayın dalınızda hem de ana dalınızda uygulandığından emin olun. Bir yaklaşım, sürüm dalında düzeltmeler yapmak ve ardından kodunuzda regresyonu önlemek için değişiklikleri ana dalınıza getirmektir. Diğer bir yaklaşım ise (ve Azure DevOps ekibi tarafından kullanılan), değişiklikleri her zaman ana dalda yapmak ve ardından bunları yayın dalına taşımaktır. Release Flow stratejimiz hakkında daha fazla bilgi edinebilirsiniz.

Bu konu başlığında, yayın dalında değişiklik yapmayı ve bunları ana hatta taşımayı ele alacağız. Hangi işlemlerin ana dala geri taşındığı üzerinde tam denetime sahip olmak için birleştirme yerine kiraz toplamayı kullanın. Yayın dalını ana dala birleştirmek, ana dalda istemediğiniz sürüme özgü değişiklikler getirebilir.

Ana dalı, yayın dalında yapılan bir değişiklikle şu adımlarla güncelleştirin:

1. Değişikliklerin aktarılması için ana daldan yeni bir özellik dalı oluşturun.
2. Yayın dalındaki değişiklikleri yeni özellik dalınıza tek tek seçin.
3. Özellik dalını ana dala ikinci bir çekme isteğiyle yeniden birleştirin.

Bu yayın dalı iş akışı, temel iş akışının yapı taşlarını korur: özellik dalları, çekme istekleri ve her zaman kodun en son sürümüne sahip güçlü bir ana dal.

Sürümler için etiketleri neden kullanmıyorsunuz?

Diğer dallanma iş akışları, belirli bir işlemeyi yayın olarak işaretlemek için Git etiketleri kullanır. Etiketler, geçmişinizdeki noktaları önemli olarak işaretlemek için kullanışlıdır. Etiketler, yayınlarınızı dallar kullanarak yapıyorsanız, iş akışınıza gereksiz ek adımlar ekler.

Etiketler korunur ve commit'lerinizden ayrı olarak gönderilir. Ekip üyeleri bir işlemeyi etiketlemeyi kolayca kaçırabilir ve daha sonra etiketi düzeltmek için geçmişe geri dönmeleri gerekir. Ayrıca etiketi göndermeye yönelik ek adımı unutarak bir sonraki geliştiricinin sürümü desteklerken kodun eski bir sürümünden çalışmasını sağlayabilirsiniz.

Yayın dalı stratejisi, yayınları işlemek için temel özellik dalı iş akışını genişletir. Ekibinizin, bağlantı noktası değişikliklerini tek tek seçme dışında herhangi bir yeni sürüm denetimi işlemini benimsemesi gerekmez.

Dağıtımları yönetme

Kodunuzun birden çok dağıtımını, birden çok sürümü işlediğiniz şekilde işleyebilirsiniz. dağıtma/performans testigibi net bir adlandırma kuralı oluşturun ve ortam dallarını yayın dalları gibi değerlendirin. Ekibiniz, dağıtım dallarını ana dalınızın koduyla güncelleştirme işlemini kabul etmelidir. Dağıtım dalında ana dala geri dönerek tek tek hata düzeltmeleri seçin. Sürüm dalından değişiklikleri aktarma işlemlerindeki adımları aynı şekilde kullanın.

Bu önerinin bir istisnası, sürekli dağıtım biçimi kullanıyor olmanızdır. Sürekli dağıtımla çalışırken ana dalınızdaki derlemeleri dağıtım hedeflerinize taşımak için Azure Pipelines kullanın.