끌어오기 요청의 대상 브랜치 구성

Azure DevOps Services

기본적으로 Azure DevOps는 기본 분기 대한 새 끌어오기 요청을 만들 것을 제안합니다. 끌어오기 요청에 여러 분기가 사용되는 리포지토리에서 리포지토리 소유자는 끌어오기 요청 대상 분기 목록을 구성하여 이러한 제안이 적절한 대상 분기를 선택할 수 있습니다.

이 기능을 사용하도록 설정하려면 리포지토리의 기본 분기 이름을 .azuredevops/pull_request_targets.yml 가진 파일을 만듭니다. 이 YAML 파일에는 후보 분기와 일치하는 분기 이름 또는 접두사가 포함된 단일 pull_request_targets목록이 포함되어야 합니다.

예를 들어 다음 내용을 고려합니다.

pull_request_targets:
  - main
  - release/*
  - feature/*

이 잠재적 대상 목록은 먼저 선택할 대상 분기로 main를 지정합니다. 그러나 release/ 또는 feature/로 시작하는 분기가 더 나은 선택일 경우, 해당 분기가 대신 선택됩니다.

끌어오기 요청 지침 및 관리 고려 사항에 대한 자세한 내용은 끌어오기 요청 정보입니다.

필수 조건

이 구성은 언제 사용되나요?

동적 대상 분기를 사용하는 진입점은 여러 가지가 있습니다.

• 끌어오기 요청 제안 사용자가 분기를 Azure DevOps로 푸시하면, 리포지토리 페이지를 다음에 방문할 때 해당 분기에서 끌어오기 요청을 만들 것을 제안받을 수 있습니다. 이 "새 끌어오기 요청 만들기" 단추는 대상 분기를 동적으로 선택합니다.

• 끌어오기 요청 URL입니다. 사용자가 sourceRef 매개 변수를 사용하고 targetRef 매개 변수를 생략하여 끌어오기 요청 생성 페이지로 직접 이동하면, Azure DevOps는 이와 같은 동적 선택에 따라 자동으로 대상 분기를 선택합니다.

클라이언트 도구에서 이 동적 선택을 사용하여 끌어오기 요청을 만들 수 있는 기능이 있지만, 이러한 클라이언트는 사용자가 대상 분기를 지정하지 않았다는 선택적 신호를 추가해야 합니다. 선택한 클라이언트 도구를 확인하여 옵션이 사용하도록 설정되어 있는지 확인합니다.

분기 대상에 적합한 후보가 있을까요?

구성된 후보 분기 목록에는 끌어오기 요청 정책으로 보호되는 분기만 포함하는 것이 좋습니다. 이러한 분기는 끌어오기 요청을 완료해야만 변경될 수 있으며, 이는 이전 분기 위치가 팁 커밋의 첫 번째 부모 기록에 있음을 보장합니다. 병합 전략을 사용하는 경우 두 번째 부모는 끌어오기 요청을 완료하여 대상 분기에 도입되는 커밋을 나타내고 첫 번째 부모는 이전 팁입니다.

Azure DevOps는 분기를 어떻게 선택하나요?

Git은 분기 만들기에 대한 메타데이터를 추적하지 않습니다. 토픽 분기를 만들 때 사용된 분기를 확인하는 정확한 방법은 없습니다. 대신 Azure DevOps는 분기의 첫 번째 부모 기록을 기반으로 추론을 사용합니다.

가능한 대상 분기 중 Azure DevOps는 첫 번째 부모 기록이 원본 분기의 첫 번째 부모 기록과 가장 교차하는 분기를 선택합니다.

예: 병합 커밋 없음

병합 커밋이 없으므로 평소보다 더 단순화된 다음 분기 구조를 고려합니다. 이 예제에서는 전체 기록이 첫 번째 부모 기록으로 표시됩니다.

  ,-E---F <-- release/2024-September
 /
A---B---C---D <--- main
     \
      `-G---H <--- feature/targets
         \
          `-I <--- topic

이 기록 및 이전에 사용된 샘플 pull_request_targets 목록을 사용하면 우선 순위에 따라 세 개의 후보 대상 분기가 있습니다.

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

그런 다음, 원본 분기 topic를 이러한 분기와 비교합니다.

• main는 topic에서 B와 교차하여 G,I를 topic에 남기고 main에는 남기지 않습니다.
• release/2024-September이 topic과(와) A에서 교차하여 B,G,I을(를) topic에 남기고 release/2024-September에는 남기지 않습니다.
• feature/targets는 topic에서 G와 교차하여 I를 topic에 남기고 feature/targets에는 남기지 않습니다.

따라서, 이 예제에서는 feature/targets가 원본 분기로, topic가 대상 분기로 선택되어 끌어오기 요청이 진행됩니다.

예: 커밋 병합

더 복잡한 예제에서는 feature/targets 분기가 main에 병합되고 main가 그 자체로 병합된 경우, 커밋 기록에 고려해야 할 사례가 더 많습니다.

  ,-E---F <-- release/2024-September
 /
A---B---C---D---J---K <--- main
     \    _/     \
      \  /        \
       `G---H---L--\--M <--- feature/targets
         \          \/
          \
           `I <--- topic

여기서 D가 main에 병합된 시점을 나타내는 커밋 feature/targets이 main입니다. 커밋 M은 main가 feature/targets에 병합된 시점을 나타냅니다. 커밋 M과 J 간의 링크는 J의 두 번째 부모가 M임을 강조하는 방식으로, L의 첫 번째 부모임을 명확히 드러내도록 그려집니다.

이 경우 전체 커밋 기록을 고려할 때, main와 feature/targets가 모두 topic에서 G의 역사를 교차합니다. 그러나 첫 번째 부모 기록은 여전히 feature/targets을/를 선호함을 보여 줍니다.

끊어지는 관계

두 브랜치의 첫 번째 부모 기록 교차점이 같으면, Azure Devops는 pull_request_targets 목록에서 더 먼저 나타나는 브랜치를 선택합니다. 접두사 일치로 인해 목록에 따라 여러 분기가 여전히 묶여 있는 경우, 사전순으로 가장 먼저 오는 분기가 우승합니다.

이러한 유형의 연결은 새 기능 브랜치를 시작하거나 릴리스 브랜치를 포크하는 등의 새 후보 브랜치를 만들 때 가장 자주 나타납니다.

          ,-E---F <-- release/2024-October
         /
A---B---C---D <--- main
     \
      \
       `G <--- topic

이 예제에서는 release/2024-October가 main에서 분기된 후, topic 분기가 main 분기로부터 생성되었습니다. 이는 사람이 읽을 때 직관적이지만, 목록의 main 및 release/* 범서의 순서는 Azure DevOps이 선호하는 순서를 나타냅니다.

Azure DevOps가 잘못된 대상 분기를 선택하면 어떻게 될까요?

끌어오기 요청 만들기 페이지에는 동적 선택이 예상과 일치하지 않는 경우 대상 분기를 조정하기 위한 선택기가 있습니다. 끌어오기 요청을 만든 후에 대상 분기를 조정할 수도 있습니다.

더 중요한 것은 추론이 "잘못된" 대상 분기를 선택하는 이유를 이해하는 것이 중요할 수 있습니다.

이 추론은 대상 분기 및 원본 분기가 만들어진 방법에 대한 몇 가지 가정에 의존합니다. 추론이 작동하지 않는 몇 가지 잠재적인 이유는 다음과 같습니다.

• 대상 분기는 끌어오기 요청 정책으로 보호되지 않습니다. 대상 분기를 임의로 푸시할 수 있는 경우 첫 번째 부모 기록은 해당 분기의 이전 위치에 대한 신뢰할 수 있는 표시기가 아닙니다.

• 소스 분기는 후보 분기의 마지막 지점에서 만들어졌습니다. 소스 브랜치가 기록에서 임의의 커밋을 선택한 경우, 따라서 그것이 의존하는 첫 번째 부모 기록에 대한 보장이 없습니다.

• 원본 분기는 git commit 및 git merge 명령을 사용하여 진행되었습니다. git reset --hard 또는 git rebase와 같은 명령은 분기의 기록을 예측할 수 없는 방식으로 변경할 수 있습니다.

이 추론에서 선택한 대상 분기에 동의하지 않는 경우 다음을 사용하여 git rebase --onto <new-target> <old-target> <source>선택을 업데이트하는 것이 좋습니다. 이 git rebase 명령은 첫 번째 부모 기록을 다시 작성하여 추론이 새 대상을 선택하도록 합니다.

사용자가 잘못된 분기를 기반으로 한다는 것을 깨달을 때 발생하는 일반적인 실수 중 하나는 올바른 분기를 기록으로 가져오는 데 사용하는 git merge 것입니다. 병합은 첫 번째 부모 기록을 변경하지 않으므로 대상 분기에 대한 선택이 변경되지 않습니다.

이 결정을 로컬에서 테스트하려면 어떻게 해야 하나요?

Azure DevOps에서 사용하는 추론은 핵심 Git 클라이언트에 기여했으며 Git 버전 2.47.0 이상에서 사용할 수 있습니다.

사용자 고유의 리포지토리에서 이 논리를 테스트하려면 먼저 실행 git fetch origin 하여 최신 버전의 대상 분기가 있는지 확인합니다. 그런 다음 후보 분기 목록과 일치하도록 조정된 다음 git for-each-ref 명령을 실행합니다.

$ 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

이 명령에서 HEAD 커밋이 원본으로 사용되며, 동일한 방식으로 대상 분기의 첫 번째 부모 기록을 비교합니다. 각 후보 분기가 출력에 나열되는 동안 문자열 (HEAD) 은 대상 분기로 사용해야 하는 분기를 나타냅니다.

다음 단계

관련된 문서

• 기본 분기 변경
• 끌어오기 요청 만들기
• 끌어오기 요청 보기
• 끌어오기 요청 검토
• 끌어오기 요청 완료
• 여러 병합 기준점