Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Azure DevOps Hizmetleri
Varsayılan olarak, Azure DevOps varsayılan dal için yeni çekme isteklerinin oluşturulmasını önerir. Çekme istekleri için kullanılan birden çok dalı olan bir depoda, depo sahipleri çekme isteği hedef dallarının listesini yapılandırarak bu önerilerin uygun hedef dalı seçmesini sağlar.
Bu özelliği etkinleştirmek için deponun varsayılan dalında ada .azuredevops/pull_request_targets.yml sahip bir dosya oluşturun.
Bu YAML dosyası, aday dallarla eşleşen dal adlarını veya ön eklerini içeren , adlı pull_request_targetstek bir liste içermelidir.
Örneğin, şu içerikleri göz önünde bulundurun:
pull_request_targets:
- main
- release/*
- feature/*
Bu potansiyel hedefler listesi, önce main hedef dalını seçilmesi gereken dal olarak belirtir, ancak release/ veya feature/ ile başlayan bir dal daha iyi bir seçenekse, bunun yerine o dal seçilir.
Çekme isteği yönergeleri ve yönetim konuları hakkında daha fazla bilgi için Çekme istekleri hakkında kısmına bakın.
Önkoşullar
| Kategori | Gereksinimler |
|---|---|
| Proje erişimi | projesiüyesi. |
| İzinler | - Özel projelerde kodu görüntüleme: En az Temel erişimi. - Özel projelerde kodu klonlama veya katkıda bulunma: Projede Katkıda Bulunanlar güvenlik grubuna üyelik veya ilgili izinler. - Dal veya depo izinlerini ayarlayın: izinleri yönetin dal veya depo için. - Varsayılan dalı değiştir: Depo için politika izinlerini düzenleyin. - Depoyu içeri aktarma: Proje Yöneticileri güvenlik grubunun üyesi veya Git proje düzeyi Depo oluşturma izni İzin verolarak ayarlanmıştır. Daha fazla bilgi için bkz . Git deposu izinlerini ayarlama. |
| Hizmetler | Repo'lar etkinleştirildi. |
| Araçlar | Opsiyonel. az repos komutlarını kullanın: Azure DevOps CLI. |
Uyarı
Genel projelerde, Paydaş erişimi olan kullanıcılar, kod görüntüleme, kopyalama ve koda katkıda bulunma dahil olmak üzere Azure Depolarına tam erişime sahiptir.
| Kategori | Gereksinimler |
|---|---|
| Proje erişimi | projesiüyesi. |
| İzinler | - Kodu görüntüle: En az Temel erişim. - Kodun bir kopyasını oluşturma veya koda katkıda bulunma: Katkıda Bulunanlar güvenlik grubunun üyesi veya projedeki ilgili izinlere sahip olma. |
| Hizmetler | Repo'lar etkinleştirildi. |
Bu yapılandırma ne zaman kullanılır?
Dinamik hedef dal kullanmak için birden çok giriş noktası vardır.
Çekme İsteği Önerileri. Kullanıcı Azure DevOps'a bir branch gönderdiğinde, Depolar sayfasına bir sonraki ziyaretinde, bu branch'ten bir pull isteği oluşturmayı önerebilir. Bu "Yeni Çekme İsteği Oluştur" düğmesi hedef dalı dinamik olarak seçer.
Pull Request URL'si Kullanıcı bir
sourceRefparametresi kullanarak çekme isteği oluşturma sayfasına doğrudan gidip parametretargetRefhariç bırakıldığında, Azure DevOps bu dinamik seçim temelinde bir hedef dal seçer.Şube Açılır Menüsü. Kullanıcı Azure DevOps'ta dal açılan listesini açtığında, çekme isteği hedeflerinde belirtilen dallar "Mayın" ve "Tümü" bölümleri arasında "Hedefler" adlı bölümde görünür.
İstemci araçlarının bu dinamik seçenek aracılığıyla pull request'leri oluşturma özelliği vardır, ancak bu istemcilerin, kullanıcının hedef dal belirtmemesi durumunda isteğe bağlı bir sinyal eklemesi gerekir. Seçeneğin etkinleştirilip etkinleştirilmediğini görmek için seçtiğiniz istemci aracını denetleyin.
Dal hedefleri için iyi adaylar nelerdir?
Yapılandırılmış aday dal listesinin yalnızca çekme isteği ilkeleriyle korunan dalları içermesini öneririz. Bu tür dallar büyük olasılıkla yalnızca çekme istekleri tamamlanarak değiştirilir ve bu da önceki dal konumunun ipucu işlemesinin ilk üst geçmişinde olduğunu garanti eder. Birleştirme stratejisi kullanılırsa, ikinci üst öğe bir çekme isteğini tamamlayarak hedef dala tanıtılan işlemeleri temsil eder ve ilk üst öğe önceki ipucudur.
Azure DevOps bir dalı nasıl seçer?
Git, dal oluşturmayla ilgili meta verileri izlemez. Konu dalı oluşturulurken hangi dalı kullanıldığını belirlemenin tam bir yolu yoktur. Bunun yerine Azure DevOps, dalların ilk üst dal geçmişini temel alan bir buluşsal yöntem kullanır.
Olası hedef dallar arasında Azure DevOps, ilk üst geçmişi kaynak dalın ilk üst geçmişiyle en çok kesişen dalı seçer.
Örnek: Birleştirme komiti yok
Birleştirme işlemeleri olmadığından normalden daha basitleştirilmiş olan aşağıdaki dal yapısını göz önünde bulundurun. Bu örnekte, bütün geçmiş ilk ana geçmişle temsil edilir.
,-E---F <-- release/2024-September
/
A---B---C---D <--- main
\
`-G---H <--- feature/targets
\
`-I <--- topic
Bu geçmiş ve daha önce kullanılan örnek pull_request_targets listeyle, öncelik sırasına göre üç aday hedef dalımız vardır:
mainrelease/2024-Septemberfeature/targets
Ardından kaynak dalı, topicbu dallarla karşılaştırılır.
-
maintopic'deBile kesişir,G,Itopiciçinde vemainiçinde değil bırakarak. -
release/2024-Septemberiletopickesişir veA'üB,G,Iiçinde bırakır,topiciçinde değil. -
feature/targetstopic'deGile kesişir,Itopiciçinde vefeature/targetsiçinde değil bırakarak.
Bu nedenle, bu örnekte, feature/targets dalı, kaynak dal olarak topic dalıyla bir çekme isteği için hedef dal olarak seçilir.
Örnek: Commit'leri birleştirme
Daha karmaşık bir örnekte, feature/targets dalı main ile ve main kendi içine birleştirildiğinde, işleme geçmişinde dikkate alınması gereken daha fazla durum vardır.
,-E---F <-- release/2024-September
/
A---B---C---D---J---K <--- main
\ _/ \
\ / \
`G---H---L--\--M <--- feature/targets
\ \/
\
`I <--- topic
Burada, D içindeki işlem, main'nin feature/targets ile birleştirildiği zamanı temsil eder. Commit M, main'in feature/targets ile birleştirildiği zamanı temsil eder. İşlemeler M ve J arasındaki bağlantı, J birinci üst öğe iken M öğesinin ikinci üst öğesi L olduğunu vurgulayan şekilde çizilir.
Bu durumda, tam taahhüt geçmişini düşündüğünüzde, main ve feature/targets, her ikisi de topic noktasında G geçmişiyle kesişiyor. Ancak, ilk üst geçmiş hâlâ feature/targets için bir tercih gösterir.
Kopan Bağlar
İki dalın aynı ilk üst geçmiş kesişimine sahip olması durumunda, Azure DevOps, pull_request_targets listesindeki daha önce görünen dalı seçer. Önek eşleşmesi nedeniyle birden fazla dal, pull_request_targets listesine bağlı olarak hala eşitse, alfabetik olarak en önce gelen kazanır.
Bu tür bağlar genellikle yeni bir özellik dalının başlangıcı veya yayın dalının çatalı gibi yeni aday dalları oluşturulduğunda ortaya çıkar.
,-E---F <-- release/2024-October
/
A---B---C---D <--- main
\
\
`G <--- topic
Bu örnekte, release/2024-October dalı, main dalından topic dalı oluşturulduktan sonra main dalından oluşturulmuştur. Bu, bir insan okuyucu için sezgisel olsa da, main listesindeki release/* ve pull_request_targets kategorilerinin sırası Azure DevOps için tercih edilen sırayı gösterir.
Azure DevOps yanlış hedef dalı seçerse ne olur?
Çekme isteği oluşturma sayfasında, dinamik seçenek beklentileri karşılamıyorsa hedef dalı ayarlamak için bir seçenek bulunur. Çekme isteği oluşturulduktan sonra hedef dal da ayarlanabilir.
Daha da önemlisi, sezgiselin neden "yanlış" hedef dalı seçebileceğini anlamak değerli olabilir.
Bu buluşsal yaklaşım, hedef dalların ve kaynak dalın nasıl oluşturulduğuna ilişkin bazı varsayımlara dayanır. Buluşsal özelliğin çalışmaması için bazı olası nedenler şunlardır:
Hedef dallar, pull request politikaları ile korunmamaktadır. Hedef dallar serbestçe gönderilebiliyorsa, ilk ebeveyn geçmişi bu dalın önceki konumunun güvenilir bir göstergesi değildir.
Kaynak dal, bir aday dalın önceki ipucundan oluşturulmuştur. Kaynak dal geçmişte rastgele bir işleme seçtiyse, bağımlı olduğu ilk üst geçmiş hakkında bir garanti yoktur.
Kaynak dalı,
git commitvegit mergekomutları kullanılarak ilerletildi.git reset --hardveyagit rebasegibi komutlar, dalın geçmişini öngörülemeyen şekillerde değiştirebilir.
Bu sezgisel kural tarafından seçilen hedef dala katılmıyorsanız, git rebase --onto <new-target> <old-target> <source> kullanarak tercihi güncellemeyi göz önünde bulundurun.
git rebase komutu, buluşsal yöntemin yeni hedefi seçmesini sağlamak için ilk ebeveyn geçmişini yeniden yazar.
Kullanıcıların yanlış dal üzerinde olduklarını fark ettiklerinde yaptıkları yaygın hatalardan biri, doğru dalı geçmişlerine eklemek için git merge kullanmaktır.
Birleştirme, ilk ebeveyn geçmişini değiştirmez ve bu nedenle hedef dal seçiminde değişiklik yapmaz.
Bu kararı yerel olarak nasıl test ederim?
Azure DevOps tarafından kullanılan buluşsal özellik, temel Git istemcisine katkıda bulunuldu ve Git 2.47.0 ve sonraki sürümlerde kullanılabilir.
Bu mantığı kendi deponuzda test etmek için, önce hedef dalların en son sürümüne sahip olduğunuzdan emin olmak için komutunu çalıştırın git fetch origin . Ardından, aşağıdaki git for-each-ref komutunu, aday dallar listenizle eşleşecek şekilde ayarlayarak çalıştırın.
$ git for-each-ref --format="%(is-base:HEAD) %(refname)" \
refs/remotes/origin/main \
"refs/remotes/origin/release/*" \
"refs/remotes/origin/feature/*"
refs/remotes/origin/main
refs/remotes/origin/release/2024-September
(HEAD) refs/remotes/origin/feature/targets
Bu komutta HEAD işleme kaynak olarak kullanılır ve hedef dalların ilk ebeveyn geçmişini aynı şekilde karşılaştırır. Her aday dal çıktıda listelenmiş olsa da, dize (HEAD) hangi dalların hedef dal olarak kullanılması gerektiğini belirtir.