Aracılığıyla paylaş


Çekme istekleri için hedef dalları yapılandırma

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 sourceRef parametresi kullanarak çekme isteği oluşturma sayfasına doğrudan gidip parametre targetRef hariç 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.

    Hedefler bölümüne sahip açılır dal menüsünün ekran görüntüsü.

İ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:

  • main
  • release/2024-September
  • feature/targets

Ardından kaynak dalı, topicbu dallarla karşılaştırılır.

  • main topic'de B ile kesişir, G,Itopic içinde ve main içinde değil bırakarak.
  • release/2024-September ile topic kesişir ve AB,G,I içinde bırakır, topic içinde değil.
  • feature/targets topic'de G ile kesişir, Itopic içinde ve feature/targets iç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 commit ve git merge komutları kullanılarak ilerletildi. git reset --hard veya git rebase gibi 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.

Sonraki adımlar