AWS CodeCommit 리포지토리에서 풀 요청 작업

풀 요청은 나와 리포지토리의 다른 사용자가 검토하고, 주석을 추가하며, 한 브랜치에서 다른 브랜치로 코드를 변경하기 위한 기본적인 방법입니다. 풀 요청을 사용하여 중요하지 않은 변경 내용이나 수정 사항, 중요 기능 추가 또는 릴리스된 소프트웨어의 새 버전에 대한 코드 변경 내용을 공동으로 검토할 수 있습니다. 다음은 풀 요청에 대한 한 가지 워크플로우입니다.

MyDemoRepo라는 리포지토리에서 작업 중인 개발자 Li Juan은 제품의 향후 버전에 추가될 새 기능 작업을 수행하려고 합니다. 그는 프로덕션 지원 코드와 별도로 유지하기 위해 기본 브랜치와 분리된 이 작업용 브랜치를 생성하여 feature-randomizationfeature라는 이름을 지정합니다. 그녀는 코드를 작성하여 설명을 추가하고 새 기능 코드를 이 브랜치에 푸시합니다. 변경 내용을 기본 브랜치에 병합하기 전에 다른 리포지토리 사용자가 품질 코드를 검토하게 하려 합니다. 이렇게 하기 위해 그녀는 풀 요청을 생성합니다. 풀 요청에는 작업용 브랜치와 자신이 변경 내용을 병합할 코드의 브랜치(이 경우 기본 브랜치) 간의 비교가 포함됩니다. 또한 지정된 수의 사용자가 풀 요청을 승인해야 하는 승인 규칙을 생성할 수 있습니다. 승인 사용자 풀을 지정할 수도 있습니다. 다른 사용자가 그녀의 코드와 변경 내용을 검토하고 주석과 제안을 추가합니다. 그녀는 다른 사용자의 주석을 반영하여 작업용 브랜치를 코드 변경 내용으로 여러 번 업데이트할 수 있습니다. 변경 내용은 CodeCommit에서 해당 브랜치에 푸시할 때마다 풀 요청에 통합됩니다. 또한 풀 요청이 미해결 상태인 동안 의도한 대상 브랜치에서 변경한 내용을 통합할 수 있으므로 사용자는 제안한 모든 변경 내용을 상황에 맞게 검토할 수 있습니다. 그녀와 검토자가 만족하고 승인 규칙 조건(있는 경우)이 충족되면 그녀 또는 검토자 중 한 명이 코드를 병합하고 풀 요청을 종료합니다.

풀 요청에는 검토를 요청할 코드를 포함하는 소스 브랜치와 검토한 코드를 변경할 대상 브랜치, 이렇게 두 개 브랜치가 필요합니다. 소스 브랜치에는 AFTER 커밋이 포함되며 이 커밋은 대상 브랜치에 병합하려는 변경 내용을 포함합니다. 대상 브랜치에는 BEFORE 커밋이 포함되며, 이 커밋은 풀 요청 브랜치가 대상 브랜치에 병합되기 전 코드의 상태를 나타냅니다. 병합 전략의 선택은 CodeCommit 콘솔에서 소스 브랜치와 대상 브랜치 간에 커밋이 병합되는 방법의 세부 사항에 영향을 줍니다. CodeCommit의 병합 전략에 대한 자세한 내용은 풀 요청 병합 (콘솔) 섹션을 참조하세요.

풀 요청은 소스 브랜치의 말단과 풀 요청이 생성될 당시의 대상 브랜치의 마지막 커밋 간의 차이를 표시하므로, 사용자는 변경 내용을 보고 그에 대한 설명을 추가할 수 있습니다. 주석에 따라 변경 내용을 소스 브랜치로 커밋하고 푸시함으로써 풀 요청을 업데이트할 수 있습니다.

코드가 검토되고 승인 규칙 요구 사항(있는 경우)이 충족되면 다음과 같은 여러 방법 중 하나로 풀 요청을 종료할 수 있습니다.

풀 요청을 생성하려면 먼저 다음을 수행해야 합니다.

Amazon Web Services 계정의 리포지토리 사용자에 대한 IAM 사용자를 설정하면 풀 요청을 더욱 효율적으로 할 수 있습니다. 어떤 사용자가 어떤 의견을 작성했는지 식별하기 더 쉽습니다. 다른 장점은 IAM 사용자가 리포지토리 액세스에 Git 보안 인증 정보를 사용할 수 있다는 것입니다. 자세한 내용은 1단계: CodeCommit에 대한 초기 구성 단원을 참조하십시오. 페더레이션 액세스 사용자를 비롯한 다른 종류의 사용자와 함께 풀 요청을 사용할 수 있습니다.

CodeCommit에서 리포지토리의 다른 측면으로 작업하는 방법에 대해 자세히 알아보려면 리포지토리 작업, 승인 규칙 템플릿 작업, 파일 작업하기, 커밋 작업, 브랜치 작업,사용자 기본 설정으로 작업 섹션을 참조하세요.