기본 브랜치, 병합과 승인 정책

Settings > Branches > Default branch에서 저장소의 기본 브랜치를 지정합니다. 별도로 선택하지 않은 pull request와 commit 작업의 기본 대상이 되며 일반적으로 master를 사용합니다.

병합 방식

저장소 설정에서 사용 가능한 방식을 하나 이상 선택합니다.

방식	결과
Squash and merge	PR의 변경을 하나의 commit으로 대상 브랜치에 반영합니다. 기본 브랜치의 이력이 짧아집니다.
Merge	원래 개별 commit들과 merge commit을 대상 브랜치에 추가합니다. 개별 commit의 원래 작성 시각도 보존합니다.
Merge with fast-forward	대상 브랜치에 새 변경이 없고 개발 브랜치까지 직접 이어지는 이력이 있으면 대상 포인터를 앞으로 옮깁니다.

선택한 방식들은 PR 화면에서 사용할 수 있습니다. Squash and merge를 허용하면 주 버튼으로 표시되고 나머지는 메뉴에서 선택합니다.

보호된 브랜치는 PR을 통해서만 변경하며 지정한 요구 사항을 충족해야 합니다. 기본 역할에서는 Owner만 보호 설정을 바꾸고 Owner와 Editor가 보호 브랜치로 병합할 수 있습니다. 권한이 높더라도 보호 정책은 따라야 합니다.

Require ci/foundry-publish to run successfully를 요구하면 발행 CI가 성공한 뒤에만 병합합니다. 성공 전에 병합하면 데이터의 변경 적용을 보장할 수 없으므로 운영 브랜치에 이 조건을 적용하는 것이 권장됩니다.

병합 권한을 가진 사용자는 review를 제출할 수 있습니다. 다음 조건은 별도로 설정합니다.

특정 사용자나 그룹의 승인을 요구할 수도 있습니다. 그룹 조건은 구성원 한 명의 승인으로 충족합니다. 이 조건만 있으면 한 구성원이 거부해도 다른 구성원의 승인으로 통과할 수 있으므로, 거부를 차단하려면 no rejections 조건도 함께 설정합니다.

필수 검토자로 지정해도 저장소 접근 권한이 새로 부여되지는 않습니다. 해당 사용자와 그룹이 저장소를 읽고 검토할 수 있는지 별도로 확인합니다.

보호 브랜치의 Edit > Advanced approval policy에서 파일에 따라 승인자를 달리 지정할 수 있습니다.

고급 승인 정책 편집기

Edit policy는 ALL, ANY 같은 논리 조합과 규칙 이름 및 설명을 구성합니다. Rule applies conditionally를 켜면 PR에서 바뀐 파일이 정규식에 맞을 때만 해당 규칙을 적용합니다.

예를 들어 다음 표현은 Python datasets 폴더 아래의 Python 파일을 대상으로 합니다.

["transforms-python/src/myproject/datasets/.*\\.py"]

View YAML에서는 정책의 YAML을 직접 편집하고 복사할 수 있습니다. 대량 치환 등 반복 수정에 사용할 수 있습니다.

상속 보안 표지의 전파를 중단하려면 브랜치가 보호되어 있어야 합니다. 저장소의 보안 변경을 허용하면 PR 병합 전에 필요한 보안 검사와 승인을 자동으로 요구하며 이 요구를 임의로 없앨 수 없습니다.

Owner가 보호를 해제할 수는 있지만 활성 보안 변경이 있는 브랜치는 먼저 PR로 그 변경을 되돌려야 합니다. 보안 표지 전파 중단이 없는 상태가 된 뒤 저장소 설정에서 보호를 해제합니다.

Functions 저장소에 보호 브랜치가 하나 이상 있으면 Only allow stable versions to be tagged from protected branches를 설정할 수 있습니다.

안정 버전 태그의 보호 브랜치 제한

이를 켜면 비보호 feature 브랜치에서 1.2.3 같은 안정 Semantic Version을 발행할 수 없습니다. 1.2.3-rc1 같은 prerelease는 허용합니다.

소비 애플리케이션은 >=1.2.3 <2.0.0 같은 범위를 참조할 수 있습니다. 이 경우 새 안정 버전 1.3.0이 발행되면 해당 버전을 호출하게 될 수 있으므로 안정 릴리스 전에 검토와 테스트가 필요합니다.

일반적인 안정 버전 범위는 prerelease를 자동 선택하지 않습니다. 예를 들어 1.3.0-test를 feature 브랜치에서 발행하여 명시적으로 시험할 수 있습니다. 별도로 prerelease를 지정한 소비 설정까지 막는 보안 경계로 해석하지 않습니다.

현재 브랜치에 빌드된 입력 데이터셋이 없으면 fallback 목록에서 빌드된 버전을 찾습니다. 별도 설정이 없으면 기본 브랜치를 사용하며 브랜치별로 여러 fallback과 조회 순서를 지정할 수 있습니다.

이 설정은 해당 Code Repository 안에서 실행한 빌드와 작업에만 적용합니다. 스케줄 등 저장소 밖에서 시작한 빌드나 다른 애플리케이션에는 자동 적용하지 않습니다.

Pipeline Builder에 같은 이름의 브랜치를 만들면 그 브랜치의 데이터셋 입력을 사용할 수 있습니다. Builder의 fallback은 Builder 브랜치 설정에서 별도로 구성합니다.