` 태그 간에 콘텐츠를 편집하여 웹 페이지에 표시되는 텍스트를 변경합니다. 변경 사항을 커밋하고 푸시한 다음 CodeCatalyst 탭으로 돌아갑니다. ## AWS Cloud9 개발 환경에서 변경하고 푸시하려면 1. 에서 측면 탐색 메뉴를 AWS Cloud9확장하여 파일을 찾습니다. `src`를 확장하고 `App.tsx`를 엽니다. 1. `
` 태그 내부의 텍스트를 변경합니다. 1. 파일을 저장한 다음 Git 메뉴를 사용하여 변경 사항을 커밋하고 푸시합니다. 또는 터미널 창에서 **git commit** 및 **git push** 명령을 사용하여 변경 사항을 커밋하고 푸시합니다. ``` git commit -am "Making an example change" git push ``` **작은 정보** Git 명령을 성공적으로 실행하기 전에 터미널의 디렉터리를 Git 리포지토리 디렉터리로 변경해야 할 수 있습니다. ## 풀 요청 생성 풀 요청을 사용하여 중요하지 않은 변경 내용이나 수정 사항, 중요 기능 추가 또는 릴리스된 소프트웨어의 새 버전에 대한 코드 변경 내용을 공동으로 검토할 수 있습니다. 이 자습서에서는 풀 요청을 생성하여 *test* 브랜치에 대한 변경 사항을 **main** 브랜치와 비교 검토합니다. 템플릿으로 생성된 프로젝트에서 풀 요청을 생성하면 해당 관련 워크플로의 실행도 시작됩니다. **풀 요청을 생성하려면** 1. 프로젝트로 이동합니다. 1. 다음 중 하나를 수행하세요. + 탐색 창에서 **코드**를 선택하고 **풀 요청**을 선택한 다음 **풀 요청 생성**을 선택합니다. + 리포지토리 홈 페이지에서 **추가**를 선택한 다음 **풀 요청 생성**을 선택합니다. + 프로젝트 페이지에서 **풀 요청 생성**을 선택합니다. 1. **소스 리포지토리**에서 지정된 소스 리포지토리가 커밋된 코드가 포함된 리포지토리인지 확인합니다. 이 옵션은 리포지토리의 메인 페이지에서 풀 요청을 생성하지 않은 경우에만 나타납니다. 1. **대상 브랜치**에서 코드를 검토한 후 병합할 브랜치를 선택합니다. 1. **소스 브랜치**에서 커밋된 코드가 포함된 브랜치를 선택합니다. 1. **풀 요청 제목**에 다른 사용자가 검토해야 할 사항과 이유를 이해하는 데 도움이 되는 제목을 입력합니다. 1. (선택 사항) **풀 요청 설명**에서 문제에 대한 연결 또는 변경 사항에 대한 설명과 같은 정보를 제공합니다. **작은 정보** CodeCatalyst가 풀 요청에 포함된 변경 사항에 대한 설명을 자동으로 생성하도록 **설명 쓰기**를 선택할 수 있습니다. 자동으로 생성된 설명은 풀 요청에 추가한 후에 변경할 수 있습니다. 이 기능을 사용하려면 스페이스에 생성형 AI 기능을 활성화해야 하며 연결된 리포지토리의 풀 요청에 사용할 수 없습니다. 자세한 내용은 [생성형 AI 기능 관리](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-generative-ai-features.html)를 참조하세요. 1. (선택 사항) **문제**에서 **문제 연결**을 선택한 다음 목록에서 문제를 선택하거나 해당 ID를 입력합니다. 문제를 연결 해제하려면 연결 해제 아이콘을 선택합니다. 1. (선택 사항) **필수 검토자**에서 **필수 검토자 추가**를 선택합니다. 프로젝트 멤버 목록에서 추가할 멤버를 선택합니다. 필수 검토자는 풀 요청을 대상 브랜치에 병합하기 전에 변경 사항을 승인해야 합니다. **참고** 검토자를 추가할 때 필수 검토자이면서 동시에 선택적 검토자로 추가할 수 없습니다. 자신을 검토자로 추가할 수 없습니다. 1. (선택 사항) **선택적 검토자**에서 **선택적 검토자 추가**를 선택합니다. 프로젝트 멤버 목록에서 추가할 멤버를 선택합니다. 선택적 검토자는 풀 요청을 대상 브랜치에 병합하기 전에 변경 사항을 요구 사항으로 승인할 필요가 없습니다. 1. 브랜치 간의 차이점을 검토합니다. 풀 요청에 표시되는 차이점은 소스 브랜치의 수정본과 풀 요청이 생성된 시점의 대상 브랜치의 헤드 커밋인 병합 기반 간의 변경 사항입니다. 변경 사항이 표시되지 않으면 브랜치가 동일하거나 소스와 대상 모두에 대해 동일한 브랜치를 선택했을 수 있습니다. 1. 풀 요청에 검토하려는 코드와 변경 사항이 포함되어 있다고 판단되면 **생성**을 선택합니다. **참고** 풀 요청을 생성한 후 설명을 추가할 수 있습니다. 풀 요청 또는 파일의 개별 줄 및 풀 요청 전반에 설명을 추가할 수 있습니다. @ 기호와 파일 이름을 사용하여 파일과 같은 리소스에 대한 연결을 추가할 수 있습니다. **개요**를 선택한 다음 **워크플로 실행** 아래의 **풀 요청 세부 정보** 영역에서 정보를 검토하여 이 풀 요청을 생성하여 시작된 관련 워크플로에 대한 정보를 볼 수 있습니다. 워크플로 실행을 보려면 실행을 선택합니다. **작은 정보** 브랜치에 **develop**이 아닌 다른 이름을 지정하면 워크플로가 자동으로 실행되지 않아 변경 사항이 빌드 및 테스트되지 않습니다. 이를 구성하려면 **onPullRequestBuildAndTest** 워크플로에 대한 YAML 파일을 편집합니다. 자세한 내용은 [워크플로 생성](workflows-create-workflow.md) 섹션을 참조하세요. 이 풀 요청에 주석을 달고 다른 프로젝트 멤버에게 주석을 달라고 요청할 수 있습니다. 선택적 또는 필수 검토자를 추가하거나 변경하도록 선택할 수도 있습니다. 리포지토리의 소스 브랜치를 더 많이 변경하도록 선택하고, 이러한 커밋된 변경으로 인해 풀 요청에 대한 개정이 어떻게 생성되는지 확인할 수 있습니다. 자세한 내용은 [풀 요청 검토](pull-requests-review.md), [풀 요청 업데이트](pull-requests-update.md), [Amazon CodeCatalyst에서 풀 요청을 사용하여 코드 검토](source-pull-requests.md) 및 [워크플로 실행 상태 및 세부 정보 보기](workflows-view-run.md) 부분을 참조하세요. ## 풀 요청 병합 풀 요청이 검토되고 필수 검토자로부터 승인을 받은 후에는 해당 소스 브랜치를 CodeCatalyst 콘솔의 대상 브랜치에 병합할 수 있습니다. 풀 요청을 병합하면 대상 브랜치와 연결된 워크플로를 통해 변경 사항 실행도 시작됩니다. 이 자습서에서는 테스트 브랜치를 기본 로 병합하여 **onPushToMainDeployPipeline** 워크플로의 실행을 시작합니다. **풀 요청 병합(콘솔)** 1. **풀 요청**에서 이전 단계에서 생성한 풀 요청을 선택합니다. 풀 요청에서 **병합**을 선택합니다. 1. 풀 요청에서 사용 가능한 병합 전략 중에서 선택합니다. 선택적으로 풀 요청을 병합한 후 소스 브랜치를 삭제하는 옵션을 선택하거나 선택 취소한 다음 **병합**을 선택합니다. 병합이 완료되면 풀 요청 상태가 **병합됨**으로 변경되고 풀 요청의 기본 보기에 더 이상 표시되지 않습니다. 기본 보기에는 상태가 **미결**인 풀 요청이 표시됩니다. 병합된 풀 요청은 계속 볼 수 있지만 승인하거나 상태를 변경할 수는 없습니다. **참고** **병합** 버튼이 활성화되지 않았거나 **병합할 수 없음** 레이블이 표시되면 필수 검토자가 아직 풀 요청을 승인하지 않았거나 CodeCatalyst 콘솔에서 풀 요청을 병합할 수 없습니다. 풀 요청을 승인하지 않은 검토자는 **풀 요청 세부 정보** 영역의 **개요**에 시계 아이콘으로 표시됩니다. 필요한 모든 검토자가 풀 요청을 승인했지만 **병합** 버튼이 여전히 활성화되어 있지 않은 경우 병합 충돌이 발생하거나 스페이스의 스토리지 할당량을 초과했을 수 있습니다. 개발 환경에서 대상 브랜치의 병합 충돌을 해결하고, 변경 사항을 푸시한 다음 풀 요청을 병합하거나, 충돌을 해결하고 로컬에서 병합한 다음 병합이 포함된 커밋을 CodeCatalyst에 푸시할 수 있습니다. 자세한 내용은 [풀 요청 병합(Git)](pull-requests-merge.md#pull-requests-merge-git) 섹션 및 Git 설명서를 참조하세요. ## 배포된 코드 보기 이제 기본 브랜치에 있던 원래 배포된 코드와 병합된 변경 사항이 자동으로 빌드, 테스트 및 배포되면 이를 볼 시간입니다. 이렇게 하려면 리포지토리의 개요 페이지로 돌아가서 관련 워크플로 아이콘 옆의 번호를 선택하거나 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다. **배포된 코드 보기** 1. **워크플로**의 `onPushToMainDeployPipeline`에서 **최근 실행**을 확장합니다. **참고** 이 이름은 **단일 페이지 애플리케이션** 블루프린트로 생성된 프로젝트에 대한 워크플로의 기본 이름입니다. 1. 가장 최근의 실행은 병합된 풀 요청이 `main` 브랜치에 커밋된 것으로 시작되며, **진행 중** 상태가 표시될 가능성이 높습니다. 목록에서 성공적으로 완료된 실행을 선택하여 해당 실행의 세부 정보를 엽니다. 1. **변수**를 선택합니다. **AppURL** 값을 복사합니다. 배포된 단일 페이지 웹 애플리케이션의 URL입니다. 새 브라우저 탭을 열고 값을 붙여넣으면 빌드 및 배포된 코드를 볼 수 있습니다. 탭을 열어 둡니다. 1. 워크플로 실행 목록으로 돌아가서 가장 최근의 실행이 완료될 때까지 기다립니다. 이 경우 열었던 탭으로 돌아가 웹 애플리케이션을 보고 브라우저를 새로 고칩니다. 병합된 풀 요청에서 변경한 내용이 표시됩니다. ## 리소스 정리 소스 리포지토리 및 풀 요청 작업을 탐색한 후에는 필요하지 않은 리소스를 모두 제거할 수 있습니다. 풀 요청은 삭제할 수 없지만 종료할 수 있습니다. 생성한 모든 브랜치를 삭제할 수 있습니다. 소스 리포지토리 또는 프로젝트가 더 이상 필요하지 않은 경우 해당 리소스를 삭제할 수도 있습니다. 자세한 내용은 [소스 리포지토리 삭제](source-repositories-delete.md) 및 [프로젝트 삭제](projects-delete.md) 섹션을 참조하세요. # CodeCatalyst에서 프로젝트의 리포지토리에 소스 코드 저장 소스 리포지토리는 프로젝트에 대한 코드 및 파일을 안전하게 저장합니다. 또한 첫 번째 커밋부터 마지막 변경 내용까지 소스 기록을 저장합니다. 소스 리포지토리가 포함된 블루프린트를 선택하면 해당 리포지토리에는 프로젝트의 워크플로 및 알림을 위한 구성 파일과 기타 정보도 포함됩니다. 이 구성 정보는 **.codecatalyst** 폴더에 저장됩니다. 프로젝트를 만들 때 소스 리포지토리를 만드는 블루프린트가 있는 프로젝트를 만들거나 기존 프로젝트에 소스 리포지토리를 만들어서 CodeCatalyst에서 소스 리포지토리를 만들 수 있습니다. 프로젝트 사용자는 프로젝트에 대해 만든 리포지토리를 자동으로 보고 사용할 수 있습니다. GitHub, Bibucket 또는 GitLab에서 호스팅되는 Git 리포지토리를 프로젝트에 연결하도록 선택할 수도 있습니다. 이렇게 하면 프로젝트 사용자는 프로젝트의 리포지토리 목록에서 연결된 리포지토리를 보고 액세스할 수 있습니다. **참고** 리포지토리를 연결하려면 먼저 리포지토리를 호스팅하는 서비스에 대한 확장 프로그램을 설치해야 합니다. 아카이브된 리포지토리는 연결할 수 없습니다. 빈 리포지토리를 연결할 수는 있지만 기본 브랜치를 만드는 초기 커밋으로 초기화하기 전까지는 CodeCatalyst에서 리포지토리를 사용할 수 없습니다. 자세한 내용은 [스페이스에 확장 프로그램 설치](install-extension.md) 섹션을 참조하세요. 기본적으로 소스 리포지토리는 Amazon CodeCatalyst 프로젝트의 다른 멤버와 공유됩니다. 프로젝트에 대한 추가 소스 리포지토리를 만들거나 리포지토리를 프로젝트에 연결할 수 있습니다. 프로젝트의 모든 멤버는 프로젝트의 소스 리포지토리에서 파일과 폴더를 보고, 추가하고, 편집하고, 삭제할 수 있습니다. 소스 리포지토리에서 코드를 빠르게 작업하려면 지정된 리포지토리를 복제하는 개발 환경을 만들고 이 환경으로 브랜치하여 개발 환경에 대해 선택한 통합 개발 환경(IDE)에서 코드를 작업할 수 있습니다. 로컬 컴퓨터에 소스 리포지토리를 복제하고 로컬 리포지토리와 원격 리포지토리 간에 변경 사항을 풀 앤 푸시하여 CodeCatalyst에서 작업할 수 있습니다. 또한 선호하는 IDE가 자격 증명 관리를 지원하는 한, 선호하는 IDE에서 소스 리포지토리에 대한 액세스를 구성하여 작업할 수도 있습니다. 리포지토리 이름은 CodeCatalyst 프로젝트에서 고유해야 합니다. **Topics** + [소스 리포지토리 생성](source-repositories-create.md) + [기존 Git 리포지토리를 소스 리포지토리로 복제](source-repositories-add-existing.md) + [소스 리포지토리 연결](source-repositories-link.md) + [소스 리포지토리 보기](source-repositories-view.md) + [소스 리포지토리의 설정 편집](source-repositories-edit.md) + [소스 리포지토리 복제](source-repositories-clone.md) + [소스 리포지토리 삭제](source-repositories-delete.md) # 소스 리포지토리 생성 Amazon CodeCatalyst에서 블루프린트를 사용하여 프로젝트를 생성하면 CodeCatalyst가 소스 리포지토리를 생성합니다. 해당 소스 리포지토리에는 워크플로에 대한 구성 정보 및 사용자를 위해 만들어진 기타 리소스 외에도 샘플 코드가 포함되어 있습니다. 이는 CodeCatalyst에서 리포지토리를 시작하는 권장 방법입니다. 프로젝트의 리포지토리를 생성하도록 선택할 수 있습니다. 이러한 리포지토리에는 언제든지 편집하거나 삭제할 수 있는 **README.md** 파일이 포함됩니다. 소스 리포지토리를 만들 때 선택한 사항에 따라 소스 리포지토리에 `.gitignore` 파일이 포함될 수도 있습니다. 기존 Git 리포지토리를 CodeCatalyst 소스 리포지토리로 복제하려면 대신 빈 리포지토리를 만드는 것을 고려하세요. 이 리포지토리는 몇 가지 간단한 Git 명령으로 콘텐츠를 추가할 때까지 CodeCatalyst에서 사용할 수 없습니다. 또는 CodeCatalyst 콘솔에서 직접 빈 리포지토리에 콘텐츠를 추가할 수도 있습니다. 또는 지원되는 Git 리포지토리 제공업체의 소스 리포지토리를 연결할 수도 있습니다. 자세한 내용은 [소스 리포지토리 연결](source-repositories-link.md) 섹션을 참조하세요. **소스 리포지토리를 생성하려면** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다. 1. 프로젝트로 이동합니다. 1. 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다. 1. **리포지토리 추가**를 선택하고 **리포지토리 생성**을 선택합니다. 1. **리포지토리 이름**에 리포지토리 이름을 제공합니다. 이 안내서에서는 *codecatalyst-source-repository*를 사용하지만 다른 이름을 선택할 수 있습니다. 리포지토리 이름은 프로젝트에서 고유해야 합니다. 리포지토리 이름 요구 사항에 대한 자세한 내용은 [CodeCatalyst의 소스 리포지토리 할당량](source-quotas.md) 섹션을 참조하세요. 1. (선택 사항) **설명**에 리포지토리에 대한 설명을 추가하여 프로젝트의 다른 사용자가 리포지토리의 용도를 이해하는 데 도움이 되도록 합니다. 1. **리포지토리 생성(기본)**을 선택합니다. 이 옵션은 기본 브랜치와 README.md 파일을 포함하는 리포지토리를 생성합니다. 빈 리포지토리와 달리 이 리포지토리가 생성되는 즉시 사용할 수 있습니다. 1. **기본 브랜치**에서 다른 이름을 선택할 이유가 없는 한 이름을 *main*으로 둡니다. 이 가이드의 예시는 모두 기본 브랜치의 이름으로 *main*을 사용합니다. 1. (선택 사항) 푸시하려는 코드 유형에 맞는 `.gitignore` 파일을 추가합니다. 1. **생성(Create)**을 선택합니다. **참고** CodeCatalyst는 `README.md` 파일을 만들 때 리포지토리에 파일을 추가합니다. 또한 CodeCatalyst는 **main**이라는 기본 브랜치에 리포지토리에 대한 초기 커밋을 생성합니다. README.md 파일을 편집하거나 삭제할 수 있지만 기본 브랜치를 삭제할 수는 없습니다. **빈 소스 리포지토리 생성** 1. CodeCatalyst 콘솔에서 빈 리포지토리를 만들려는 프로젝트로 이동합니다. 1. 프로젝트 요약 페이지의 **소스 리포지토리**에서 **리포지토리 추가**를 선택한 다음 **리포지토리 만들기**를 선택합니다. 아니면 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다. **리포지토리 추가**를 선택하고 **리포지토리 생성**을 선택합니다. 1. **리포지토리 이름**에 리포지토리 이름을 제공합니다. 이 안내서에서는 *codecatalyst-source-repository*를 사용하지만 다른 이름을 선택할 수 있습니다. 리포지토리 이름은 프로젝트에서 고유해야 합니다. 리포지토리 이름 요구 사항에 대한 자세한 내용은 [CodeCatalyst의 소스 리포지토리 할당량](source-quotas.md) 섹션을 참조하세요. 1. (선택 사항) **설명**에 리포지토리에 대한 설명을 추가하여 프로젝트의 다른 사용자가 리포지토리의 용도를 이해하는 데 도움이 되도록 합니다. 1. **빈 리포지토리 생성**을 선택한 다음 **생성**을 선택합니다. # 기존 Git 리포지토리를 소스 리포지토리로 복제 기존 Git 리포지토리를 Amazon CodeCatalyst의 빈 소스 리포지토리에 복제할 수 있습니다. 이는 이전에 다른 Git 리포지토리 공급자에서 호스팅된 코드를 사용하여 CodeCatalyst를 시작하는 빠른 방법입니다. 미러 복제본을 생성한 다음 미러를 CodeCatalyst 로 푸시하여 리포지토리의 콘텐츠를 복제할 수 있습니다. 또는 CodeCatalyst에 콘텐츠를 추가하려는 리포지토리의 로컬 리포지토리가 있는 경우 CodeCatalyst 소스 리포지토리를 로컬 리포지토리에 다른 원격 리포지토리로 추가한 다음 빈 소스 리포지토리로 푸시할 수 있습니다. 두 접근 방식 모두 동일하게 유효합니다. 미러 복제본을 사용하면 브랜치를 매핑할 뿐만 아니라 모든 참조를 매핑합니다. CodeCatalyst에서 리포지토리의 작업 복사본을 생성하는 간단하고 깨끗한 방법입니다. 빈 CodeCatalyst 소스 리포지토리를 가리키는 로컬 리포지토리에 원격 를 추가하면 리포지토리 콘텐츠가 CodeCatalyst에 추가되지만, 로컬 리포지토리에서 CodeCatalyst 소스 리포지토리와 원래 Git 원격 리포지토리로 푸시할 수도 있습니다. 이는 코드를 서로 다른 원격 리포지토리에 유지하려는 경우 유용할 수 있지만 다른 개발자가 원격 리포지토리 중 하나에만 코드를 커밋하는 경우 충돌이 발생할 수 있습니다. 다음 절차에서는 기본 Git 명령을 사용하여 이 작업을 수행합니다. 복제를 포함하여 Git에서 작업을 수행하는 방법은 다양합니다. 자세한 내용은 [Git 설명서](https://git-scm.com/docs/git-clone)를 참조하세요. **중요** 콘텐츠를 복제하려면 먼저 CodeCatalyst에서 빈 리포지토리를 생성해야 합니다. 개인 액세스 토큰도 있어야 합니다. 자세한 내용은 [빈 소스 리포지토리 생성](source-repositories-create.md#source-repositories-create-empty) 및 [개인용 액세스 토큰 생성](source-setting-up.md#source-setting-up-pat) 섹션을 참조하세요. **`git clone --mirror`를 사용하여 기존 Git 리포지토리를 CodeCatalyst에 복제** 1. CodeCatalyst 콘솔에서 빈 리포지토리를 생성한 프로젝트로 이동합니다. 1. 프로젝트의 요약 페이지에서 목록에서 빈 리포지토리를 선택한 다음 **리포지토리 보기를** 선택합니다. 아니면 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다. 프로젝트의 소스 리포지토리 목록에서 빈 리포지토리의 이름을 선택합니다. 1. 빈 리포지토리의 HTTPS 복제 URL을 복사합니다. 미러 복제본을 푸시하려면 이 기능이 필요합니다. 예를 들어, ExampleCorp 스페이스의 MyExampleProject 프로젝트에서 소스 리포지토리 이름을 MyExampleRepo로 지정하고 사용자 이름이 LiJuan인 경우 복제 URL은 다음과 같이 보일 수 있습니다. ``` https://LiJuan@git.us-west-2.codecatalyst.aws/v1/ExampleCorp/MyExampleProject/MyExampleRepo ``` 1. 명령줄 또는 터미널 창에서 `git clone --mirror` 명령을 사용하여 CodeCatalyst 에 복제하려는 Git 리포지토리의 미러 복제본을 생성합니다. 예를 들어 GitHub에서 codecatalyst-blueprints 리포지토리의 미러 복제본을 생성하려면 다음 명령을 입력합니다. ``` git clone --mirror https://github.com/aws/codecatalyst-blueprints.git ``` 1. 디렉터리를 복제를 생성한 디렉터리로 변경합니다. ``` cd codecatalyst-blueprints.git ``` 1. URL과 대상 CodeCatalyst 소스 리포지토리의 이름, **--all** 옵션을 지정하여 **git push** 명령을 실행합니다. (여기서 URL은 3단계에서 복사해 놓은 것입니다.) 예제: ``` git push https://LiJuan@git.us-west-2.codecatalyst.aws/v1/ExampleCorp/MyExampleProject/MyExampleRepo --all ``` **원격 리포지토리를 추가하고 로컬 리포지토리를 CodeCatalyst로 푸시하려면** 1. CodeCatalyst 콘솔에서 빈 리포지토리를 생성한 프로젝트로 이동합니다. 1. 프로젝트의 요약 페이지에서 목록에서 빈 리포지토리를 선택한 다음 **리포지토리 보기를** 선택합니다. 아니면 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다. 프로젝트의 소스 리포지토리 목록에서 빈 리포지토리의 이름을 선택합니다. 1. 빈 리포지토리의 HTTPS 복제 URL을 복사합니다. 미러 복제본을 푸시하려면 이 기능이 필요합니다. 예를 들어, ExampleCorp 스페이스의 MyExampleProject 프로젝트에서 소스 리포지토리 이름을 MyExampleRepo로 지정하고 사용자 이름이 LiJuan인 경우 복제 URL은 다음과 같이 보일 수 있습니다. ``` https://LiJuan@git.us-west-2.codecatalyst.aws/v1/ExampleCorp/MyExampleProject/MyExampleRepo ``` 1. 명령줄 또는 터미널 창에서 디렉터리를 CodeCatalyst로 푸시하려는 로컬 리포지토리로 변경합니다. 1. git remote -v 명령을 실행하여 로컬 리포지토리의 기존 원격을 확인합니다. 예를 들어 미국 동부(오하이오) 리전에 이름이 **MyDemoRepo**인 AWS CodeCommit 리포지토리의 로컬 리포지토리를 복제하는 경우 명령 출력은 다음과 같을 수 있습니다. ``` origin https://git-codecommit.us-east-2.amazonaws.com/v1/repos/MyDemoRepo (fetch) origin https://git-codecommit.us-east-2.amazonaws.com/v1/repos/MyDemoRepo (push) ``` 리포지토리를 계속 사용하려면 원격 URL을 복사합니다. 1. `git remote remove` 명령을 사용하여 오리진 가져오기 및 푸시에 대한 CodeCommit 리포지토리 URL을 제거합니다. ``` git remote remove origin ``` 1. **git remote add** 명령을 사용하여 CodeCatalyst 소스 리포지토리 URL을 로컬 리포지토리의 가져오기 및 푸시 원격 로 추가합니다. 예제: ``` git remote add origin https://LiJuan@git.us-west-2.codecatalyst.aws/v1/ExampleCorp/MyExampleProject/MyExampleRepo ``` 이는 CodeCommit 리포지토리 푸시 URL을 CodeCatalyst 소스 리포지토리 URL로 대체하지만 가져오기 URL은 변경하지 않습니다. 따라서 git remote -v 명령을 다시 실행하면 CodeCommit 원격 리포지토리에서 코드를 가져오고(가져오고) 있지만 로컬 리포지토리의 변경 사항을 CodeCatalyst 소스 리포지토리로 푸시하도록 구성되어 있습니다. ``` origin https://git-codecommit.us-east-2.amazonaws.com/v1/repos/MyDemoRepo (fetch) origin https://LiJuan@git.us-west-2.codecatalyst.aws/v1/ExampleCorp/MyExampleProject/MyExampleRepo (push) ``` `git remote set-url` 명령을 사용하여 두 리포지토리로 푸시하려는 경우 선택적으로 CodeCommit 원격 URL을 다시 추가할 수 있습니다. ``` git remote set-url --add --push origin https://git-codecommit.us-east-2.amazonaws.com/v1/repos/MyDemoRepo ``` 1. `git push` 명령을 실행하여 구성된 모든 푸시 원격에 로컬 리포지토리를 푸시합니다. 또는 로컬 리포지토리를 두 리포지토리로 푸시하는 **--all** 옵션을 지정하여 **git push -u -origin** 명령을 실행합니다. 예제: ``` git push -u -origin --all ``` **작은 정보** Git 버전에 따라 로컬 리포지토리의 모든 브랜치를 빈 리포지토리로 푸시하는 데 모두 작동하지 않을 수 있습니다. 각 브랜치를 체크아웃하고 별도로 푸시해야 할 수 있습니다. # 소스 리포지토리 연결 소스 리포지토리를 프로젝트에 연결할 때 리포지토리를 호스팅하는 서비스에 대해 CodeCatalyst 확장 프로그램이 설치되어 있는 경우 해당 확장 프로그램이 있는 리포지토리를 포함할 수 있습니다(해당 스페이스에 대해 해당 확장 프로그램이 설치되어 있는 경우). 스페이스 관리자 역할을 가진 사용자만 확장 프로그램을 설치할 수 있습니다. 확장 프로그램이 설치되면 해당 확장 프로그램에서 액세스하도록 구성된 리포지토리에 연결할 수 있습니다. 자세한 내용은 [스페이스에 확장 프로그램 설치](install-extension.md) 섹션을 참조하거나 [CodeCatalyst에서 GitHub 리포지토리, Bitbucket 리포지토리, GitLab 프로젝트 리포지토리 및 Jira 프로젝트 연결](extensions-link.md)를 따르세요. **중요** 리포지토리 확장 프로그램을 설치한 후 CodeCatalyst에 연결하는 모든 리포지토리의 코드가 CodeCatalyst에 인덱싱 및 저장됩니다. 이렇게 하면 CodeCatalyst에서 코드를 검색할 수 있습니다. CodeCatalyst에서 연결된 리포지토리를 사용할 때 코드에 대한 데이터 보호를 더 잘 이해하려면 *Amazon CodeCatalyst 사용 설명서*의 [데이터 보호](https://docs.aws.amazon.com/codecatalyst/latest/userguide/data-protection.html)를 참조하세요. 리포지토리를 한 스페이스에 있는 하나의 프로젝트에만 연결할 수 있습니다. 아카이브된 리포지토리는 연결할 수 없습니다. 빈 리포지토리를 연결할 수는 있지만 기본 브랜치를 만드는 초기 커밋으로 초기화하기 전까지는 CodeCatalyst에서 리포지토리를 사용할 수 없습니다. 뿐만 아니라 + GitHub 리포지토리, Bitbucket 리포지토리 또는 GitLab 프로젝트 리포지토리는 한 스페이스에서 하나의 CodeCatalyst 프로젝트에만 연결할 수 있습니다. + 비어있거나 보관된 GitHub 리포지토리, Bitbucket 리포지토리 또는 GitLab 프로젝트 리포지토리를 CodeCatalyst 프로젝트와 함께 사용할 수 없습니다. + CodeCatalyst 프로젝트의 리포지토리와 이름이 동일한 GitHub 리포지토리, Bitbucket 리포지토리 또는 GitLab 프로젝트 리포지토리를 연결할 수 없습니다. + **GitHub 리포지토리** 확장 프로그램은 GitHub Enterprise Server 리포지토리와 호환되지 않습니다. + **Bitbucket 리포지토리** 확장 프로그램은 Bitbucket Data Center 리포지토리와 호환되지 않습니다. + **GitLab 리포지토리** 확장 프로그램은 GitLab 자체 관리형 프로젝트 리포지토리와 호환되지 않습니다. + 연결된 리포지토리에서는 **설명 쓰기** 또는 **설명 요약** 기능을 사용할 수 없습니다. 이러한 기능은 CodeCatalyst의 풀 요청에서만 사용할 수 있습니다. GitHub 리포지토리, Bitbucket 리포지토리 또는 GitLab 프로젝트 리포지토리를 **기고자**로 연결할 수 있지만 타사 리포지토리를 **스페이스 관리자** 또는 **프로젝트 관리자**로서만 연결 해제할 수 있습니다. 자세한 내용은 [CodeCatalyst에서 GitHub 리포지토리, Bitbucket 리포지토리, GitLab 프로젝트 리포지토리 및 Jira 프로젝트 연결 해제](extensions-unlink.md) 섹션을 참조하세요. **중요** CodeCatalyst는 연결된 리포지토리에 대한 기본 브랜치의 변경 사항 감지를 지원하지 않습니다. 연결된 리포지토리의 기본 브랜치를 변경하려면 먼저 CodeCatalyst에서 연결을 해제하고 기본 브랜치를 변경한 다음 다시 연결해야 합니다. 자세한 내용은 [CodeCatalyst에서 GitHub 리포지토리, Bitbucket 리포지토리, GitLab 프로젝트 리포지토리 및 Jira 프로젝트 연결](extensions-link.md) 섹션을 참조하세요. 리포지토리를 연결하기 전에 항상 최신 버전의 확장 프로그램을 사용하는 것이 좋습니다. **소스 리포지토리 연결** 1. 리포지토리를 연결하려는 프로젝트로 이동합니다. **참고** 리포지토리를 연결하려면 먼저 스페이스 관리자 역할이 있는 사용자가 리포지토리를 호스팅하는 제공업체의 확장 프로그램을 설치해야 합니다. 자세한 내용은 [스페이스에 확장 프로그램 설치](install-extension.md) 섹션을 참조하세요. 1. 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다. 1. **리포지토리 추가**를 선택하고 **리포지토리 연결**을 선택합니다. 1. **리포지토리 공급자** 드롭다운 메뉴에서 다음 타사 리포지토리 공급자 중 하나를 선택합니다. **GitHub** 또는 **Bitbucket** 1. 연결하도록 선택한 타사 리포지토리 공급자에 따라 다음 중 하나를 수행합니다. + **GitHub 리포지토리**: GitHub 리포지토리를 연결합니다. 1. **GitHub 계정** 드롭다운 메뉴에서 연결할 리포지토리가 포함된 GitHub 계정을 선택합니다. 1. **GitHub 리포지토리** 드롭다운 메뉴에서 CodeCatalyst 프로젝트를 연결할 GitHub 계정을 선택합니다. 1. (선택 사항) 리포지토리 목록에 GitHub 리포지토리가 표시되지 않는 경우 GitHub의 Amazon CodeCatalyst 애플리케이션에서 리포지토리 액세스에 대해 구성되지 않았을 수 있습니다. 연결된 계정의 CodeCatalyst에서 사용할 수 있는 GitHub 리포지토리를 구성할 수 있습니다. 1. [GitHub](https://github.com/) 계정으로 이동하여 **설정**을 선택한 다음 **애플리케이션**을 선택합니다. 1. **설치된 GitHub 앱** 탭에서 Amazon CodeCatalyst 애플리케이션에 대해 **구성**을 선택합니다. 1. 다음 중 하나를 수행하여 CodeCatalyst에서 연결하려는 GitHub 리포지토리의 액세스를 구성합니다. + 모든 현재 및 향후 리포지토리에 대한 액세스를 제공하려면 **모든 리포지토리**를 선택합니다. + 특정 리포지토리에 대한 액세스 권한을 제공하려면 **선택된 리포지토리만**을 선택하고 **리포지토리 선택** 드롭다운을 선택한 다음 CodeCatalyst에서 연결할 수 있도록 허용할 리포지토리를 선택합니다. + **Bitbucket 리포지토리:** Bitbucket 리포지토리를 연결합니다. 1. **Bitbucket 작업 영역** 드롭다운 메뉴에서 연결하려는 리포지토리가 포함된 Bitbucket 작업 영역을 선택합니다. 1. **Bitbucket 리포지토리** 드롭다운 메뉴에서 CodeCatalyst 프로젝트를 연결할 Bitbucket 리포지토리를 선택합니다. **작은 정보** 리포지토리 이름이 회색으로 표시된 경우 Amazon CodeCatalyst 의 다른 프로젝트에 이미 연결되어 있으므로 해당 리포지토리를 연결할 수 없습니다. 1. **연결**을 선택합니다. CodeCatalyst에서 GitHub 리포지토리, Bitbucket 리포지토리 또는 GitLab 프로젝트 리포지토리를 더 이상 사용하지 않으려면 CodeCatalyst 프로젝트에서 연결을 해제할 수 있습니다. 리포지토리가 연결 해제되면 해당 리포지토리의 이벤트는 워크플로를 시작하지 않으며 CodeCatalyst 개발 환경에서 해당 리포지토리를 사용할 수 없습니다. 자세한 내용은 [CodeCatalyst에서 GitHub 리포지토리, Bitbucket 리포지토리, GitLab 프로젝트 리포지토리 및 Jira 프로젝트 연결 해제](extensions-unlink.md) 섹션을 참조하세요. # 소스 리포지토리 보기 Amazon CodeCatalyst에서 프로젝트와 연결된 소스 리포지토리를 볼 수 있습니다. CodeCatalyst의 소스 리포지토리의 경우 리포지토리의 개요 페이지에서는 다음을 포함하여 해당 리포지토리의 정보 및 활동에 대한 간략한 개요를 제공합니다. + 리포지토리에 대한 설명(있을 경우) + 리포지토리의 브랜치 수 + 리포지토리에 대한 열린 풀 요청 수 + 리포지토리에 대한 관련 워크플로 수 + 기본 브랜치의 파일 및 폴더 또는 선택한 브랜치 + 표시된 브랜치에 대한 마지막 커밋의 제목, 작성자 및 날짜 + README.md 파일이 포함된 경우 마크다운에 렌더링된 README.md 파일의 내용 또한 이 페이지에서는 리포지토리에 대한 커밋, 브랜치 및 풀 요청에 연결하는 링크와 개별 파일을 빠르게 열고 보고 편집할 수 있는 방법을 제공합니다. **참고** CodeCatalyst 콘솔에서는 연결된 리포지토리에 대한 이 정보를 볼 수 없습니다. 연결된 리포지토리에 대한 정보를 보려면, 리포지토리 목록에서 링크를 선택하여 리포지토리를 호스팅하는 서비스에서 해당 리포지토리를 엽니다. **프로젝트의 소스 리포지토리로 이동하려면** 1. 프로젝트로 이동하여 다음 중 하나를 수행합니다. + 프로젝트의 요약 페이지에서 목록에서 원하는 리포지토리를 선택한 다음 **리포지토리 보기**를 선택합니다. + 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다. **소스 리포지토리**의 경우 목록에서 리포지토리의 이름을 선택합니다. 필터 표시줄에 리포지토리 이름의 일부를 입력하여 리포지토리 목록을 필터링할 수 있습니다. 1. 리포지토리의 홈 페이지에서 리포지토리의 내용과 풀 요청 수 및 워크플로와 같은 관련 리소스에 대한 정보를 확인합니다. 기본적으로 기본 브랜치의 내용이 표시됩니다. 드롭다운 목록에서 다른 브랜치를 선택하여 보기를 변경할 수 있습니다. **작은 정보** 프로젝트 요약 페이지에서 **프로젝트 코드 보기**를 선택하여 프로젝트의 리포지토리로 빠르게 이동할 수도 있습니다. # 소스 리포지토리의 설정 편집 리포지토리에 대한 설명 편집, 기본 브랜치 선택, 브랜치 규칙 생성 및 관리, CodeCatalyst에서 풀 요청에 대한 승인 규칙 생성 및 관리 등 리포지토리 설정을 관리할 수 있습니다. 이를 통해 프로젝트 멤버가 리포지토리의 용도를 이해하고 팀에서 사용하는 모범 사례와 프로세스를 적용하는 데 도움이 될 수 있습니다. **참고** 소스 리포지토리의 이름은 편집할 수 없습니다. 연결된 리포지토리의 이름, 설명 또는 기타 정보는 CodeCatalyst에서 편집할 수 없습니다. 연결된 리포지토리에 대한 정보를 수정하려면 연결된 리포지토리를 호스팅하는 제공업체에서 정보를 편집해야 합니다. 자세한 내용은 연결된 리포지토리를 호스팅하는 서비스의 설명서를 참조하세요. **리포지토리의 설정 편집** 1. CodeCatalyst 콘솔에서 설정을 편집하려는 소스 리포지토리가 포함된 프로젝트로 이동합니다. 1. 프로젝트의 요약 페이지에서 목록에서 원하는 리포지토리를 선택한 다음 **리포지토리 보기**를 선택합니다. 아니면 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다. 프로젝트의 소스 리포지토리 목록에서 리포지토리 이름을 선택합니다. 1. 리포지토리의 개요 페이지에서 **추가**를 선택한 다음 **설정 관리**를 선택합니다. 1. 다음 중 한 개 이상을 수행할 수 있습니다. + 리포지토리에 대한 설명을 편집한 다음 **저장**을 선택합니다. + 리포지토리의 기본 브랜치를 변경하려면 **기본 브랜치**에서 **편집**을 선택합니다. 자세한 내용은 [리포지토리의 기본 브랜치 관리](source-branches-default-branch.md) 섹션을 참조하세요. + 브랜치에서 특정 작업을 수행할 수 있는 권한을 가진 프로젝트 역할에 대한 규칙을 추가, 제거 또는 변경하려면 **브랜치 규칙**에서 **편집**을 선택합니다. 자세한 내용은 [브랜치 규칙을 사용하여 브랜치에 대한 작업 관리](source-branches-branch-rules.md) 섹션을 참조하세요. + 브랜치에 풀 요청을 병합하기 위한 승인 규칙을 추가, 제거 또는 변경하려면 **승인 규칙**에서 **편집**을 선택합니다. 자세한 내용은 [풀 요청을 승인 규칙과 병합하기 위한 요구 사항 관리](source-pull-requests-approval-rules.md) 섹션을 참조하세요. # 소스 리포지토리 복제 소스 리포지토리에 있는 여러 파일, 브랜치 및 커밋을 효과적으로 작업하려면 소스 리포지토리를 로컬 컴퓨터에 복제하고 Git 클라이언트 또는 통합 개발 환경(IDE)을 사용하여 변경 작업을 수행합니다. 문제 및 풀 요청과 같은 CodeCatalyst 특성을 사용하려면 소스 리포지토리에 변경 사항을 커밋하고 푸시합니다. 코드 작업을 위한 개발 환경을 생성하도록 선택할 수도 있습니다. 개발 환경을 만들면 지정한 리포지토리와 브랜치가 자동으로 개발 환경으로 복제됩니다. **참고** 연결된 리포지토리를 CodeCatalyst 콘솔에서 복제하거나 이에 대한 개발 환경을 생성할 수 없습니다. 연결된 리포지토리를 로컬에서 복제하려면 리포지토리 목록에서 링크를 선택하여 리포지토리를 호스팅하는 서비스에서 해당 리포지토리를 연 다음 복제합니다. 자세한 내용은 연결된 리포지토리를 호스팅하는 서비스의 설명서를 참조하세요. **소스 리포지토리에서 개발 환경 생성** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다. 1. 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다. 1. 코드 작업을 수행할 소스 리포지토리를 선택합니다. 1. **개발 환경 생성**을 선택합니다. 1. 드롭다운 메뉴에서 지원되는 IDE를 선택합니다. 자세한 정보는 [개발 환경에 지원되는 통합 개발 환경](devenvironment-create.md#devenvironment-supported-ide)을 참조하세요. 1. 다음 중 하나를 수행하세요. + **기존 브랜치에서 작업**을 선택한 다음 **기존 브랜치 드롭다운** 메뉴에서 브랜치를 선택합니다. + **새 브랜치에서 작업**을 선택하고, **브랜치 이름** 필드에 브랜치 이름을 입력하고, **다음에서 브랜치 생성** 드롭다운 메뉴에서 새 브랜치를 만들 브랜치를 선택합니다. 1. 선택적으로 개발 환경의 이름을 추가하거나 구성을 편집합니다. 1. **생성(Create)**을 선택합니다. **소스 리포지토리 생성** 1. 프로젝트로 이동합니다. 1. 프로젝트의 요약 페이지에서 목록에서 원하는 리포지토리를 선택한 다음 **리포지토리 보기**를 선택합니다. 아니면 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다. 프로젝트의 소스 리포지토리 목록에서 리포지토리 이름을 선택합니다. 필터 표시줄에 리포지토리 이름의 일부를 입력하여 리포지토리 목록을 필터링할 수 있습니다. 1. 1. **리포지토리 복제**를 선택합니다. 리포지토리의 복제 URL을 복사합니다. **참고** 개인 액세스 토큰(PAT)이 없는 경우 **토큰 생성**을 선택합니다. 토큰을 복사하여 안전한 위치에 저장합니다. Git 클라이언트 또는 통합 개발 환경(IDE)에서 암호를 입력하라는 메시지가 표시되면 이 PAT를 사용합니다. 1. 다음 중 하나를 수행하세요. + 로컬 컴퓨터에 리포지토리를 복제하려면 터미널 또는 명령줄을 열고 **git clone** 명령 뒤에 복제 URL을 사용하여 명령을 실행합니다. 예제: ``` git clone https://LiJuan@git.us-west-2.codecatalyst.aws/v1/ExampleCorp/MyExampleProject/MyExampleRepo ``` 암호를 입력하라는 메시지가 표시되면 이전에 저장한 PAT를 붙여넣습니다. **참고** 운영 체제가 자격 증명 관리를 제공하거나 자격 증명 관리 시스템을 설치한 경우 PAT를 한 번만 제공하면 됩니다. 그렇지 않으면 모든 Git 작업에 대해 PAT를 제공해야 할 수 있습니다. 가장 좋은 방법은 자격 증명 관리 시스템이 PAT를 안전하게 저장하는 것입니다. 복제 URL 문자열의 일부로 PAT를 포함하지 마세요. + IDE를 사용하여 리포지토리를 복제하려면 IDE에 대한 설명서를 따르세요. Git 리포지토리를 복제하고 URL을 제공하는 옵션을 선택합니다. 암호를 입력하라는 메시지가 표시되면 PAT를 제공합니다. # 소스 리포지토리 삭제 Amazon CodeCatalyst 프로젝트의 소스 리포지토리가 더 이상 필요하지 않은 경우 삭제할 수 있습니다. 소스 리포지토리를 삭제하면 리포지토리에 저장된 모든 프로젝트 정보도 삭제됩니다. 워크플로가 소스 리포지토리에 종속된 경우 리포지토리가 삭제된 후 해당 워크플로는 프로젝트 워크플로 목록에서 삭제됩니다. 소스 리포지토리를 참조하는 문제는 삭제되거나 변경되지 않지만 리포지토리가 삭제되면 문제에 추가된 소스 리포지토리 링크는 모두 실패합니다. **중요** 소스 리포지토리 삭제는 실행 취소할 수 없습니다. 소스 리포지토리를 삭제한 후에는 더 이상 복제하거나, 리포지토리에서 데이터를 가져오거나, 리포지토리로 데이터를 푸시할 수 없습니다. 소스 리포지토리를 삭제한다고 해서 해당 리포지토리의 모든 로컬 사본(로컬 리포지토리)이 삭제되는 것은 아닙니다. 로컬 리포지토리를 삭제하려면 로컬 컴퓨터의 디렉터리와 파일 관리 도구를 사용하세요. **참고** 연결된 리포지토리는 CodeCatalyst 콘솔에서 삭제할 수 없습니다. 연결된 리포지토리를 삭제하려면 리포지토리 목록에서 링크를 선택하여 해당 리포지토리를 호스팅하는 서비스에서 해당 리포지토리를 연 다음 삭제합니다. 자세한 내용은 연결된 리포지토리를 호스팅하는 서비스의 설명서를 참조하세요. 프로젝트에서 연결된 리포지토리를 제거하려면 [CodeCatalyst에서 GitHub 리포지토리, Bitbucket 리포지토리, GitLab 프로젝트 리포지토리 및 Jira 프로젝트 연결 해제](extensions-unlink.md) 섹션을 참조하세요. **소스 리포지토리 삭제** 1. 삭제하려는 소스 리포지토리가 포함된 프로젝트로 이동합니다. 1. 프로젝트의 요약 페이지에서 목록에서 원하는 리포지토리를 선택한 다음 **리포지토리 보기**를 선택합니다. 아니면 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다. 프로젝트의 소스 리포지토리 목록에서 리포지토리 이름을 선택합니다. 1. 리포지토리의 홈 페이지에서 **추가**를 선택한 다음 **설정 관리**와 **리포지토리 삭제**를 차례로 선택합니다. 1. 브랜치, 풀 요청 및 관련 워크플로 정보를 검토하여 아직 사용 중이거나 완료되지 않은 작업이 있는 리포지토리를 삭제하지 않는지 확인합니다. 계속하려면 **delete** 입력한 다음 **삭제**를 선택합니다. # Amazon CodeCatalyst의 브랜치를 사용하여 소스 코드 작업 구성 Git에서 브랜치는 커밋에 대한 포인터 또는 참조입니다. 개발 시 작업을 체계적으로 정리할 수 있는 편리한 수단입니다. 브랜치를 사용하면 다른 브랜치의 작업에 영향을 주지 않으면서 파일의 새 버전이나 다른 버전에 대한 작업을 분리할 수 있습니다. 브랜치를 사용하면 새 기능을 개발하고 프로젝트 버전을 저장하는 등의 작업을 수행할 수 있습니다. 소스 리포지토리에서 브랜치에 대한 규칙을 구성하여 브랜치에 대한 특정 작업을 해당 프로젝트의 특정 역할로 제한할 수 있습니다. Amazon CodeCatalyst의 소스 리포지토리에는 생성 방법에 관계없이 콘텐츠와 기본 브랜치가 있습니다. 연결된 리포지토리에는 기본 브랜치나 콘텐츠가 없을 수도 있지만, 초기화하고 기본 브랜치를 생성하기 전까지는 CodeCatalyst에서 사용할 수 없습니다. 블루프린트를 사용하여 프로젝트를 만들면 CodeCatalyst는 해당 프로젝트의 소스 리포지토리를 생성하며, 여기에는 README.md 파일, 샘플 코드, 워크플로 정의 및 기타 리소스가 포함됩니다. 블루프린트를 사용하지 않고 소스 리포지토리를 만들면 첫 번째 커밋으로 README.md 파일이 추가되고 *기본 브랜치*가 만들어집니다. 이 기본 브랜치의 이름은 *기본*입니다. 이 기본 브랜치는 사용자가 리포지토리를 복제할 때 로컬 리포지토리에서 기본 브랜치로 사용될 브랜치입니다. **참고** 기본 브랜치는 삭제할 수 없습니다. 소스 리포지토리에 대해 처음 만든 브랜치가 해당 리포지토리의 기본 브랜치입니다. 또한 검색은 기본 브랜치의 결과만 표시합니다. 다른 브랜치에 있는 코드는 검색할 수 없습니다. CodeCatalyst에서 리포지토리를 만들면 첫 번째 커밋이 생성되며, 이 커밋에는 README.md 파일이 포함된 *기본 브랜치*가 생성됩니다. 기본 브랜치의 이름은 *main*입니다. 이 이름이 본 안내서의 예시에 사용된 기본 브랜치 이름입니다. **Topics** + [브랜치 생성](source-create-delete-branch.md) + [리포지토리의 기본 브랜치 관리](source-branches-default-branch.md) + [브랜치 규칙을 사용하여 브랜치에 대한 작업 관리](source-branches-branch-rules.md) + [브랜치에 대한 Git 명령](source-branches-git.md) + [브랜치 및 세부 정보 보기](source-branches-view.md) + [브랜치 삭제](source-branches-delete.md) # 브랜치 생성 CodeCatalyst 콘솔을 사용하여 CodeCatalyst 리포지토리에 브랜치를 만들 수 있습니다. 생성한 브랜치는 다음에 다른 사용자가 리포지토리에서 변경 내용을 가져올 때 표시됩니다. **작은 정보** 코드에서 작업할 개발 환경을 생성하는 과정에서 브랜치를 생성할 수도 있습니다. 자세한 내용은 [개발 환경 생성](devenvironment-create.md) 섹션을 참조하세요. Git을 사용하여 브랜치를 생성할 수도 있습니다. 자세한 내용은 [브랜치에 대한 공통 Git 명령](source-branches-git.md#source-branches-git-table) 섹션을 참조하세요. **브랜치를 생성하려면(콘솔)** 1. CodeCatalyst 콘솔에서 소스 리포지토리가 있는 프로젝트로 이동합니다. 1. 프로젝트의 소스 리포지토리 목록에서 리포지토리 이름을 선택합니다. 아니면 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다. 1. 브랜치를 생성하려는 리포지토리의 이름을 선택합니다. 1. 리포지토리의 개요 페이지에서 **추가**를 선택한 다음 **브랜치 생성**을 선택합니다. 1. 브랜치의 이름을 입력합니다. 1. 브랜치를 생성할 브랜치를 선택한 다음 **생성**을 선택합니다. # 리포지토리의 기본 브랜치 관리 Amazon CodeCatalyst에서 어떤 브랜치를 소스 리포지토리의 기본 브랜치로 할지 지정할 수 있습니다. CodeCatalyst의 모든 소스 리포지토리에는 생성 방식에 관계없이 콘텐츠와 기본 브랜치가 있습니다. 블루프린트를 사용하여 프로젝트를 생성하는 경우, 해당 프로젝트에 대해 생성된 소스 리포지토리의 기본 브랜치 이름이 *메인*으로 지정됩니다. 기본 브랜치의 내용은 해당 리포지토리의 개요 페이지에 자동으로 표시됩니다. **중요** CodeCatalyst는 연결된 리포지토리에 대한 기본 브랜치의 변경 사항 감지를 지원하지 않습니다. 연결된 리포지토리의 기본 브랜치를 변경하려면 먼저 CodeCatalyst에서 연결을 해제하고 기본 브랜치를 변경한 다음 다시 연결해야 합니다. 자세한 내용은 [CodeCatalyst에서 GitHub 리포지토리, Bitbucket 리포지토리, GitLab 프로젝트 리포지토리 및 Jira 프로젝트 연결](extensions-link.md) 섹션을 참조하세요. 리포지토리를 연결하기 전에 항상 최신 버전의 확장 프로그램을 사용하는 것이 좋습니다. 기본 브랜치는 소스 리포지토리의 다른 모든 브랜치와 약간 다르게 처리됩니다. 이름 옆에는 **기본**이라는 특수 레이블이 있습니다. 이 기본 브랜치는 사용자가 리포지토리를 Git 클라이언트로 로컬 컴퓨터로 복제할 때 로컬 리포지토리에서 기본 브랜치로 사용될 브랜치입니다. 또한 워크플로 YAML 파일을 저장하고 문제에 대한 정보를 저장하는 워크플로를 생성할 때 사용되는 기본값입니다. CodeCatalyst에서 검색을 사용하는 경우 리포지토리의 기본 브랜치만 검색됩니다. 기본 브랜치는 프로젝트의 여러 측면에서 기본이므로, 기본 브랜치로 지정된 브랜치는 삭제할 수 없습니다. 그러나 다른 브랜치를 기본 브랜치로 사용하도록 선택할 수 있습니다. 이렇게 하면 이전 기본 브랜치에 적용된 모든 [브랜치 규칙](source-branches-branch-rules.md)이 기본 브랜치로 지정한 브랜치에 자동으로 적용됩니다. **참고** CodeCatalyst 프로젝트에서 소스 리포지토리의 기본 브랜치를 변경하려면 프로젝트 관리자 역할이 있어야 합니다. 이는 연결된 리포지토리에는 적용되지 않습니다. **리포지토리의 기본 브랜치를 보고 변경하려면** 1. 리포지토리가 있는 프로젝트로 이동합니다. 1. 프로젝트의 소스 리포지토리 목록에서 리포지토리 이름을 선택합니다. 아니면 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다. 기본 브랜치를 포함하여 설정을 보려는 리포지토리를 선택합니다. 1. 리포지토리의 개요 페이지에서 **추가**를 선택한 다음 **설정 관리**를 선택합니다. 1. **기본 브랜치**에서 기본 브랜치로 지정된 브랜치의 이름은 이름 옆에 **기본**이라는 레이블과 함께 표시됩니다. 이 동일한 레이블이 **브랜치**의 브랜치 목록에서 브랜치 이름 옆에 나타납니다. 1. 기본 브랜치를 변경하려면 **편집**을 선택합니다. **참고** 기본 브랜치를 변경하려면 프로젝트에 프로젝트 관리자 역할이 있어야 합니다. 1. 드롭다운 목록에서 기본 브랜치를 만들 브랜치의 이름을 선택한 다음, **저장**을 선택합니다. # 브랜치 규칙을 사용하여 브랜치에 대한 작업 관리 브랜치를 생성할 때, 해당 역할에 대한 권한을 기반으로 해당 브랜치에 대한 특정 작업이 허용됩니다. 브랜치 규칙을 구성하여 특정 브랜치에 허용되는 작업을 변경할 수 있습니다. 브랜치 규칙은 사용자가 프로젝트에서 수행하는 역할을 기반으로 합니다. 브랜치에 커밋 푸시와 같은 사전 정의된 일부 작업을 프로젝트에서 특정 역할을 가진 사용자로 제한하도록 선택할 수 있습니다. 이를 통해 특정 작업을 수행할 수 있는 역할을 제한하여 프로젝트의 특정 브랜치를 보호할 수 있습니다. 예를 들어, 프로젝트 **관리자** 역할이 있는 사용자만 해당 브랜치에 병합하거나 푸시하도록 브랜치 규칙을 구성하면, 프로젝트의 다른 역할이 있는 사용자는 해당 브랜치의 코드를 변경할 수 없습니다. 브랜치에 대한 규칙 생성이 미치는 모든 영향을 신중하게 고려해야 합니다. 예를 들어, 브랜치에 대한 푸시를 **프로젝트 관리자** 역할이 있는 사용자만 할 수 있도록 제한하면, **기고자** 역할이 있는 사용자는 해당 브랜치에서 워크플로를 생성하거나 편집할 수 없습니다. 이는 워크플로 YAML이 해당 브랜치에 저장되고 허용된 역할이 아닌 사용자는 YAML에 대한 변경 사항을 커밋하거나 푸시할 수 없기 때문입니다. 가장 좋은 방법은 브랜치 규칙을 생성한 후 테스트하여 의도하지 않은 영향이 나타나지 않는지 확인하는 것입니다. 풀 요청에 대한 승인 규칙과 함께 브랜치 규칙을 사용할 수도 있습니다. 자세한 내용은 [풀 요청을 승인 규칙과 병합하기 위한 요구 사항 관리](source-pull-requests-approval-rules.md) 단원을 참조하십시오. **참고** CodeCatalyst 프로젝트의 소스 리포지토리에 대한 브랜치 규칙을 관리하려면 프로젝트 관리자 역할이 있어야 합니다. 연결된 리포지토리에 대한 브랜치 규칙은 생성할 수 없습니다. 역할에 대한 기본 권한보다 더 제한적인 브랜치 규칙만 생성할 수 있습니다. 프로젝트에서 사용자의 역할이 허용하는 것보다 더 허용적인 브랜치 규칙은 생성할 수 없습니다. 예를 들어, 검토자 역할이 있는 사용자가 브랜치로 푸시할 수 있도록 허용하는 브랜치 규칙을 생성할 수 없습니다. 소스 리포지토리의 기본 브랜치에 적용되는 브랜치 규칙은 다른 브랜치에 적용되는 브랜치 규칙과 약간 다르게 작동합니다. 기본 브랜치에 적용되는 모든 규칙은 기본 브랜치로 지정한 모든 브랜치에 자동으로 적용됩니다. 이전에 기본 브랜치로 설정된 브랜치는 삭제 방지 기능이 더 이상 없다는 점을 제외하면 기존 규칙이 적용된 상태로 유지됩니다. 이 보호 기능은 현재 기본 브랜치에만 적용됩니다. 브랜치 규칙에는 **표준** 및 **사용자 지정**이라는 두 가지 상태가 있습니다. **표준**은 브랜치에서 허용되는 작업이 브랜치 작업에 대해 CodeCatalyst에서 사용자가 가진 역할에 대한 권한과 일치하는 작업임을 나타냅니다. 어떤 역할에 어떤 권한이 있는지에 대한 자세한 내용은 [사용자 역할로 액세스 권한 부여](ipa-roles.md) 섹션을 참조하세요. **사용자 지정**은 하나 이상의 브랜치 작업에 프로젝트의 사용자 역할이 부여한 기본 권한과 다른 작업을 수행할 수 있는 특정 역할 목록이 있는 작업이 있음을 나타냅니다. **참고** 브랜치에 대해 하나 이상의 작업을 제한하는 브랜치 규칙을 생성하면, 프로젝트 관리자 역할이 있는 사용자만 해당 브랜치를 삭제할 수 있도록 **브랜치 삭제** 작업이 자동으로 설정됩니다. 다음 표에는 브랜치에서 이러한 작업을 수행할 수 있는 역할에 대한 작업과 기본 설정이 나열되어 있습니다. **브랜치 작업 및 역할** | **브랜치 작업** | 브랜치 규칙이 적용되지 않을 때 이 작업을 수행할 수 있는 역할 | | --- | --- | | 브랜치에 병합(풀 요청을 브랜치에 병합하는 것 포함) | 프로젝트 관리자, 기고자 | | 브랜치로 푸시 | 프로젝트 관리자, 기고자 | | 브랜치 삭제 | 프로젝트 관리자, 기고자 | | 브랜치 삭제(기본 브랜치) | 허용되지 않음 | 브랜치 규칙은 삭제할 수 없지만, 브랜치에서 이 작업을 수행할 수 있는 모든 역할의 작업을 허용하도록 업데이트하여 규칙을 효과적으로 제거할 수 있습니다. **참고** CodeCatalyst 프로젝트의 소스 리포지토리에 대한 브랜치 규칙을 구성하려면 프로젝트 관리자 역할이 있어야 합니다. 이는 연결된 리포지토리에는 적용되지 않습니다. 연결된 리포지토리는 CodeCatalyst의 브랜치 규칙을 지원하지 않습니다. **리포지토리의 브랜치 규칙을 보고 편집하려면** 1. 리포지토리가 있는 프로젝트로 이동합니다. 1. 프로젝트의 소스 리포지토리 목록에서 리포지토리 이름을 선택합니다. 아니면 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다. 브랜치 규칙을 보려는 리포지토리를 선택합니다. 1. 리포지토리의 개요 페이지에서 **브랜치**를 선택합니다. 1. **브랜치 규칙** 열에서 리포지토리의 각 브랜치에 대한 규칙 상태를 확인합니다. **표준**은 브랜치 작업 규칙이 소스 리포지토리에서 생성된 모든 브랜치의 기본 규칙이며, 프로젝트의 해당 역할에 부여된 권한과 일치함을 나타냅니다. **사용자 지정**은 하나 이상의 브랜치 작업에 해당 브랜치에 대해 허용되는 하나 이상의 작업을 다른 역할 집합으로 제한하는 규칙이 있음을 나타냅니다. 브랜치에 대한 브랜치 규칙의 세부 정보를 보려면, 검토하려는 브랜치 옆에 있는 **표준** 또는 **사용자 지정**이라는 단어를 선택합니다. 1. 브랜치 규칙을 생성하거나 변경하려면 **설정 관리**를 선택합니다. 소스 리포지토리의 설정 페이지에 있는 **브랜치 규칙**에서 **편집**을 선택합니다. 1. **Branch name**의 드롭다운 목록에서 규칙을 구성하려는 브랜치의 이름을 선택합니다. 허용되는 각 작업 유형에 대해, 드롭다운 목록에서 해당 작업을 수행하도록 허용할 역할을 선택한 다음, **저장**을 선택합니다. # 브랜치에 대한 Git 명령 Git을 사용하여 컴퓨터(로컬 리포지토리) 또는 개발 환경에 있는 소스 리포지토리의 복제본에서 브랜치를 생성, 관리 및 삭제한 다음 변경 사항을 CodeCatalyst 소스 리포지토리(원격 리포지토리)에 커밋하고 푸시할 수 있습니다. 예제: **브랜치에 대한 공통 Git 명령** | | | | --- |--- | | 로컬 리포지토리의 모든 브랜치를 나열하며, 현재 브랜치 옆에 별표(`*`)를 표시합니다. | `git branch` | | 원격 리포지토리에 있는 모든 기존 브랜치에 대한 정보를 로컬 리포지토리로 가져옵니다. | `git fetch` | | 로컬 리포지토리의 브랜치와 로컬 리포지토리의 원격 추적 브랜치를 모두 나열합니다. | `git branch -a` | | 로컬 리포지토리의 원격 추적 브랜치만 나열합니다. | `git branch -r` | | 지정된 브랜치 이름을 사용하여 로컬 리포지토리에 브랜치를 생성합니다. 이 브랜치는 커밋하고 변경 내용을 푸시할 때까지 원격 리포지토리에 나타나지 않습니다. | `git branch branch-name` | | 지정된 브랜치 이름을 사용하여 로컬 리포지토리에 브랜치를 만든 다음 해당 브랜치로 전환합니다. | `git checkout -b branch-name` | | 지정된 브랜치 이름을 사용하여 로컬 리포지토리의 다른 브랜치로 전환합니다. | `git checkout other-branch-name` | | 원격 리포지토리에 대해 로컬 리포지토리의 지정된 닉네임과 지정된 브랜치 이름을 사용하여 로컬 리포지토리에서 원격 리포지토리로 브랜치를 푸시합니다. 또한 로컬 리포지토리에 있는 브랜치에 대한 업스트림 추적 정보도 설정합니다. | `git push -u remote-name branch-name` | | 로컬 리포지토리의 다른 브랜치에서 변경한 내용을 로컬 리포지토리의 현재 브랜치에 병합합니다. | `git merge from-other-branch-name` | | 병합되지 않은 작업이 포함되어 있지 않는 한 로컬 리포지토리에서 브랜치를 삭제합니다. | `git branch -d branch-name` | | 로컬 리포지토리가 원격 리포지토리에 대해 지정한 닉네임과 지정된 브랜치 이름을 사용하여 원격 리포지토리의 새 브랜치를 삭제합니다. (콜론(`:`) 사용에 주의하세요.) 또는 명령의 일부로 `--delete`를 지정합니다. | `git push remote-name :branch-name` `git push remote-name --delete branch-name` | 자세한 내용은 Git 설명서를 참조하세요. # 브랜치 및 세부 정보 보기 특정 브랜치에 대한 파일, 폴더 및 가장 최근 커밋을 비롯한 원격 브랜치에 대한 정보를 Amazon CodeCatalyst 콘솔에서 볼 수 있습니다. Git 명령과 로컬 운영 체제를 사용하여 원격 및 로컬 브랜치에 대한 이 정보를 볼 수도 있습니다. **브랜치 보기(콘솔)** 1. CodeCatalyst 콘솔에서 브랜치를 보려는 소스 리포지토리가 포함된 프로젝트로 이동합니다. **코드**를 선택하고 **소스 리포지토리**를 선택한 다음 소스 리포지토리를 선택합니다. 1. 프로젝트의 소스 리포지토리 목록에서 리포지토리 이름을 선택합니다. 아니면 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다. 브랜치를 보려는 리포지토리를 선택합니다. 1. 리포지토리의 기본 브랜치가 표시됩니다. 브랜치에 있는 파일 및 폴더 목록, 가장 최근 커밋에 대한 정보, README.md 파일의 내용(브랜치에 있는 경우)을 볼 수 있습니다. 다른 브랜치에 대한 정보를 보려면 리포지토리의 브랜치 드롭다운 목록에서 해당 브랜치를 선택합니다. 1. 리포지토리의 모든 브랜치를 보려면 **모두 보기**를 선택합니다. 브랜치 페이지에는 각 브랜치의 이름, 가장 최근 커밋 및 규칙에 대한 정보가 표시됩니다. Git 및 운영 체제를 사용하여 브랜치 및 세부 정보를 보는 방법에 대한 자세한 내용은 Git 설명서 및 운영 체제 설명서, [Common Git commands for branches](source-branches-git.md#source-branches-git-table)를 참조하세요. # 브랜치 삭제 브랜치가 더 이상 필요하지 않으면 삭제할 수 있습니다. 예를 들어, 특성이 변경된 브랜치를 기본 브랜치에 병합했는데 해당 특성이 릴리스된 경우, 변경 사항이 이미 기본 브랜치에 포함되어 있으므로 원래 특성이 있는 브랜치를 삭제하고 싶을 수 있습니다. 브랜치 수를 적게 유지하면 사용자가 작업하려는 변경 사항이 포함된 브랜치를 쉽게 찾을 수 있습니다. 브랜치를 삭제하면 사용자가 변경 내용을 가져와 동기화할 때까지 해당 브랜치의 복사본이 로컬 컴퓨터의 리포지토리 복제본에 남아 있습니다. **브랜치 삭제(콘솔)** 1. 리포지토리가 있는 프로젝트로 이동합니다. 1. 프로젝트의 소스 리포지토리 목록에서 리포지토리 이름을 선택합니다. 아니면 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다. 브랜치를 삭제할 리포지토리를 선택합니다. 1. 리포지토리 개요 페이지에서 브랜치 이름 옆의 드롭다운 선택기를 선택한 다음 **모두 보기**를 선택합니다. 1. 삭제하려는 브랜치를 선택한 다음 **브랜치 삭제**를 선택합니다. **참고** 리포지토리의 기본 브랜치는 삭제할 수 없습니다. 1. 확인 대화 상자가 표시됩니다. 리포지토리, 진행 중인 풀 리퀘스트 수, 브랜치와 관련된 워크플로 수를 보여줍니다. 1. 브랜치 삭제를 확인하려면 텍스트 상자에 **delete**를 입력한 다음 **삭제**를 선택합니다. Git을 사용하여 브랜치를 삭제할 수도 있습니다. 자세한 내용은 [브랜치에 대한 공통 Git 명령](source-branches-git.md#source-branches-git-table) 섹션을 참조하세요. # Amazon CodeCatalyst에서 소스 코드 파일 관리 Amazon CodeCatalyst에서 파일은 버전이 관리되고 독립적으로 작동하는 정보입니다. 본래의 사용자 외에, 해당 파일이 저장된 소스 리포지토리와 브렌치의 다른 사용자들도 이용할 수 있습니다. 사용자는 디렉터리 구조를 활용하여 리포지토리 파일을 정리할 수 있습니다. CodeCatalyst는 파일에 대해 커밋된 모든 변경 내용을 자동으로 추척합니다. 사용자는 서로 다른 버전의 파일을 서로 다른 리포지토리 브랜치에 저장할 수 있습니다. 소스 리포지토리에서 여러 파일을 추가하거나 편집하려면 Git 클라이언트, 개발 환경 또는 통합 개발 환경(IDE)을 사용할 수 있습니다. 단일 파일을 추가하거나 편집하려면 CodeCatalyst 콘솔을 사용할 수 있습니다. **Topics** + [파일 생성 또는 추가](source-files-create.md) + [파일 보기](source-files-view.md) + [파일 변경 내역 보기](source-files-view-history.md) + [파일 편집](source-files-edit.md) + [파일 이름 바꾸기 또는 삭제](source-files-delete.md) # 파일 생성 또는 추가 Amazon CodeCatalyst 콘솔, 개발 환경, 연결된 통합 개발 환경(IDE) 또는 Git 클라이언트를 사용하여 소스 리포지토리에 파일을 생성하고 추가할 수 있습니다. CodeCatalyst 콘솔에는 파일을 생성하기 위한 코드 편집기가 포함되어 있습니다. 이 편집기는 리포지토리의 브랜치에서 README.md 파일과 같은 간단한 파일을 생성하거나 편집하는 편리한 방법입니다. 둘 이상의 파일에서 작업할 때는 [개발 환경 생성](devenvironment-create.md)을 고려하세요. **소스 리포지토리에서 개발 환경 생성** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다. 1. 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다. 1. 코드 작업을 수행할 소스 리포지토리를 선택합니다. 1. **개발 환경 생성**을 선택합니다. 1. 드롭다운 메뉴에서 지원되는 IDE를 선택합니다. 자세한 정보는 [개발 환경에 지원되는 통합 개발 환경](devenvironment-create.md#devenvironment-supported-ide)을 참조하세요. 1. 다음 중 하나를 수행하세요. + **기존 브랜치에서 작업**을 선택한 다음 **기존 브랜치 드롭다운** 메뉴에서 브랜치를 선택합니다. + **새 브랜치에서 작업**을 선택하고, **브랜치 이름** 필드에 브랜치 이름을 입력하고, **다음에서 브랜치 생성** 드롭다운 메뉴에서 새 브랜치를 만들 브랜치를 선택합니다. 1. 선택적으로 개발 환경의 이름을 추가하거나 구성을 편집합니다. 1. **생성(Create)**을 선택합니다. **CodeCatalyst 콘솔에서 파일 생성** 1. 파일을 생성하려는 프로젝트로 이동합니다. 리포지토리로 이동하는 방법에 대한 자세한 내용은 [소스 리포지토리 보기](source-repositories-view.md) 섹션을 참조하세요. 1. 프로젝트의 소스 리포지토리 목록에서 리포지토리 이름을 선택합니다. 아니면 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다. 파일을 생성할 리포지토리를 선택합니다. 1. (선택 사항) 기본 브랜치가 아닌 다른 브랜치에 파일을 만들려면 파일을 만들 브랜치를 선택합니다. 1. **새 파일 생성**을 선택합니다. 1. **파일 이름**에 파일 이름을 입력합니다. 편집기에 파일 내용을 추가합니다. **작은 정보** 브랜치 루트의 하위 폴더 또는 하위 디렉터리에서 파일을 생성하려면 해당 구조를 파일 이름에 포함시킵니다. 선택 사항에 만족하는 경우, **확인**을 선택합니다. 1. **파일 이름**에서 파일 이름을 검토하고 원하는 대로 변경합니다. 필요에 따라 **브랜치**의 사용 가능한 브랜치 목록에서 파일을 만들 브랜치를 선택합니다. **커밋 메시지**에 선택 사항으로 이 변경을 수행한 이유에 대한 간략하지만 유익한 설명을 입력합니다. 소스 리포지토리에 파일을 추가하는 커밋에 대한 기본 커밋 정보로 표시됩니다. 1. **커밋**을 선택하여 파일을 커밋하고 소스 리포지토리로 푸시합니다. 로컬 컴퓨터에 복제하고 Git 클라이언트 또는 연결된 통합 개발 환경(IDE)을 사용하여 파일과 변경 사항을 푸시하여 소스 리포지토리에 파일을 추가할 수도 있습니다. **참고** Git 하위 모듈을 추가하려면 Git 클라이언트 또는 개발 환경을 사용하고 **git submodule add** 명령을 실행해야 합니다. CodeCatalyst 콘솔에서 Git 하위 모듈을 추가하거나 보거나 풀 요청에서 Git 하위 모듈의 차이를 볼 수 없습니다. Git 하위 모듈에 대한 자세한 내용은 [Git 설명서](https://git-scm.com/book/en/v2/Git-Tools-Submodules)를 참조하세요. **Git 클라이언트 또는 연결된 통합 개발 환경(IDE)을 사용하여 파일 추가** 1. 소스 리포지토리를 로컬 컴퓨터에 복제합니다. 자세한 내용은 [소스 리포지토리 복제](source-repositories-clone.md) 섹션을 참조하세요. 1. 로컬 리포지토리에 파일을 생성하거나 로컬 리포지토리에 파일을 복사합니다. 1. 다음 중 하나를 수행하여 커밋을 생성하고 푸시합니다. + Git 클라이언트를 사용하는 경우 터미널 또는 명령줄에서 **git add** 명령을 실행하고 추가하려는 파일의 이름을 지정합니다. 또는 추가되거나 변경된 모든 파일을 추가하려면 **git add** 명령 뒤에 마침표 또는 마침표를 붙여 현재 디렉터리 수준의 모든 변경 사항(마침표 하나)을 포함할지, 현재 디렉터리와 모든 하위 디렉터리의 모든 변경 사항(마침표 둘)을 포함할지 표시합니다. 변경 사항을 커밋하려면 **git commit -m** 명령을 실행하고 커밋 메시지를 제공합니다. 변경 사항을 CodeCatalyst의 소스 리포지토리로 푸시하려면 **git push**를 실행합니다. Git 설명에 대한 자세한 내용은 Git 설명서 및 [브랜치에 대한 Git 명령](source-branches-git.md)을 참조하세요. + 개발 환경 또는 IDE를 사용하는 경우 파일을 생성하고 IDE에 파일을 추가한 다음 커밋하고 변경 사항을 푸시합니다. 자세한 내용은 [CodeCatalyst에서 개발 환경으로 코드 작성 및 수정개발 환경으로 코드 작성 및 수정](devenvironment.md) 또는 IDE 관련 문서를 참조하세요. # 파일 보기 Amazon CodeCatalyst 콘솔에서 소스 리포지토리에 있는 파일을 볼 수 있습니다. 기본 브랜치 및 다른 브랜치에서 파일을 볼 수 있습니다. 파일 내용은 보려는 브랜치에 따라 다를 수 있습니다. **CodeCatalyst 콘솔에서 파일 보기** 1. 파일을 보려는 프로젝트로 이동합니다. 자세한 내용은 [소스 리포지토리 보기](source-repositories-view.md) 섹션을 참조하세요. 1. 프로젝트의 소스 리포지토리 목록에서 리포지토리 이름을 선택합니다. 아니면 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다. 파일을 보려는 리포지토리를 선택합니다. 1. 기본 브랜치에 대한 파일 및 폴더 목록이 표시됩니다. 파일은 종이 아이콘으로 표시되고 폴더는 폴더 아이콘으로 표시됩니다. 1. 해결 방법: + 다른 브랜치에 있는 파일과 폴더를 보려면 브랜치 목록에서 해당 브랜치를 선택합니다. + 폴더를 확장하려면 목록에서 폴더를 선택합니다. 1. 특정 파일의 콘텐츠를 보려면 목록에서 해당 파일을 선택합니다. 파일의 내용이 브랜치에 표시됩니다. 다른 브랜치에 있는 파일의 내용을 보려면 브랜치 선택기에서 원하는 브랜치를 선택합니다. **작은 정보** 파일의 내용을 볼 때 **파일 보기**에서 볼 추가 파일을 선택할 수 있습니다. 파일을 편집하려면 **편집**을 선택합니다. 콘솔에서 여러 파일을 볼 수 있습니다. Git 클라이언트 또는 통합 개발 환경(IDE)을 사용하여 로컬 컴퓨터에 복제한 파일을 볼 수도 있습니다. 자세한 내용은 Git 클라이언트나 IDE 관련 설명서를 참조하세요. **참고** CodeCatalyst 콘솔에서는 Git 하위 모듈을 볼 수 없습니다. Git 하위 모듈에 대한 자세한 내용은 [Git 설명서](https://git-scm.com/book/en/v2/Git-Tools-Submodules)를 참조하세요. # 파일 변경 내역 보기 소스 리포지토리의 파일 변경 내역은 Amazon CodeCatalyst 콘솔에서 볼 수 있습니다. 이렇게 하면 파일 이력을 보도록 선택한 브랜치에 대한 다양한 커밋에 의해 파일이 변경된 내용을 이해하는 데 도움이 될 수 있습니다. 예를 들어, 소스 리포지토리의 **main** 브랜치에서 **readme.md** 파일의 변경 내역을 보면 해당 브랜치에서 해당 파일에 대한 변경 사항이 포함된 커밋 목록이 표시됩니다. **참고** CodeCatalyst 콘솔에서 연결된 리포지토리의 파일 기록을 볼 수 없습니다. # CodeCatalyst 콘솔에서 파일 기록 보기 1. 파일 기록을 보려는 프로젝트로 이동합니다. 자세한 내용은 [소스 리포지토리 보기](source-repositories-view.md) 섹션을 참조하세요. 1. 프로젝트의 소스 리포지토리 목록에서 리포지토리 이름을 선택합니다. 아니면 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다. 1. 파일 기록을 보려는 리포지토리를 선택합니다. 파일 기록을 보려는 브랜치를 선택한 다음 목록에서 파일을 선택합니다. **내역 보기**를 선택합니다. 1. 지정한 브랜치에서 이 파일에 대한 변경 사항이 포함된 커밋 목록을 검토합니다. 특정 커밋에 포함된 변경 사항의 세부 정보를 보려면 목록에서 해당 커밋에 대한 커밋 메시지를 선택합니다. 해당 커밋과 상위 커밋의 차이점이 표시됩니다. 1. 다른 브랜치에 있는 파일의 변경 기록을 검토하려면 브랜치 선택기를 사용하여 해당 브랜치로 보기를 변경하고 파일 목록에서 파일을 선택한 다음 **기록 보기**를 선택합니다. **참고** CodeCatalyst 콘솔에서는 Git 하위 모듈에 대한 변경 기록을 볼 수 없습니다. Git 하위 모듈에 대한 자세한 내용은 [Git 설명서](https://git-scm.com/book/en/v2/Git-Tools-Submodules)를 참조하세요. # 파일 편집 Amazon CodeCatalyst 콘솔에서 개별 파일을 편집할 수 있습니다. 한 번에 여러 파일을 편집하려면 개발 환경을 만들거나 리포지토리를 복제하고 Git 클라이언트 또는 통합 개발 환경(IDE)을 사용하여 변경하세요. 자세한 내용은 [CodeCatalyst에서 개발 환경으로 코드 작성 및 수정개발 환경으로 코드 작성 및 수정](devenvironment.md) 또는 [소스 리포지토리 복제](source-repositories-clone.md)을 참조하세요. **CodeCatalyst 콘솔에서 파일 편집 보기** 1. 파일을 편집하려는 프로젝트로 이동합니다. 리포지토리로 이동하는 방법에 대한 자세한 내용은 [소스 리포지토리 보기](source-repositories-view.md) 섹션을 참조하세요. 1. 파일을 편집할 리포지토리를 선택합니다. **브랜치 보기**를 선택한 다음 작업할 브랜치를 선택합니다. 해당 브랜치의 파일 및 폴더 목록에서 파일을 선택합니다. 파일의 내용이 표시됩니다. 1. **편집**을 선택합니다. 1. 편집기에서 파일의 내용을 편집한 다음 **커밋**을 선택합니다. 선택 사항으로 **변경 사항 커밋**에서 **커밋 메시지**에 변경 사항에 대한 자세한 정보를 추가합니다. 선택 사항에 만족하는 경우, **확인**을 선택합니다. # 파일 이름 바꾸기 또는 삭제 개발 환경에서, 컴퓨터의 로컬 환경에서 또는 통합 개발 환경(IDE)에서 파일 이름을 바꾸거나 삭제할 수 있습니다. 파일 이름을 변경하거나 삭제한 후, 그 변경 사항을 소스 리포지토리에 커밋하고 푸시합니다. Amazon CodeCatalyst 콘솔에서는 파일 이름을 변경하거나 삭제할 수 없습니다. # Amazon CodeCatalyst에서 풀 요청을 사용하여 코드 검토 풀 요청은 나와 프로젝트 멤버가 검토하고, 주석을 추가하며, 한 브랜치에서 다른 브랜치로 코드를 변경하기 위한 기본적인 방법입니다. 풀 요청을 사용하여 중요하지 않은 변경 내용이나 수정 사항, 중요 기능 추가 또는 릴리스된 소프트웨어의 새 버전에 대한 코드 변경 내용을 공동으로 검토할 수 있습니다. 문제를 사용하여 프로젝트의 작업을 추적하는 경우 특정 이슈를 풀 요청에 연결하여 풀 요청의 코드 변경으로 어떤 문제가 해결되고 있는지 추적할 수 있습니다. 풀 요청을 생성, 업데이트, 설명, 병합 또는 종료하면 풀 요청의 작성자는 물론 풀 요청의 필수 또는 선택 검토자에게 자동으로 이메일이 전송됩니다. **작은 정보** 프로파일의 일부로서 이메일을 수신할 풀 요청 이벤트를 구성할 수 있습니다. 자세한 내용은 [CodeCatalyst에서 Slack 및 이메일 알림 전송](notifications-manage.md) 섹션을 참조하세요. 풀 요청에는 소스 리포지토리에 검토하려는 코드가 포함된 소스 브랜치와 검토한 코드를 병합하려는 대상 브랜치, 두 개의 브랜치가 필요합니다. 소스 브랜치에는 AFTER 커밋이 포함되며 이 커밋은 대상 브랜치에 병합하려는 변경 내용을 포함합니다. 대상 브랜치에는 BEFORE 커밋이 포함되며, 이 커밋은 풀 요청 브랜치가 대상 브랜치에 병합되기 전 코드의 상태를 나타냅니다. **참고** 풀 요청을 생성하는 동안 나타나는 차이는 소스 브랜치의 최신 커밋과 대상 브랜치의 최신 커밋의 차이입니다. 풀 요청을 만들면 선택한 풀 요청의 수정본과 풀 요청을 만들 때 대상 브랜치의 끝이었던 커밋의 차이점이 표시됩니다. Git의 차이점 및 병합 기반에 대한 자세한 내용은 Git 설명서의 [git-merge-base](https://git-scm.com/docs/git-merge-base)를 참조하세요. 특정 소스 리포지토리 및 브랜치에 대한 풀 요청이 생성되는 동안 프로젝트 작업의 일부로 풀 요청을 만들고, 보고, 검토하고, 닫을 수 있습니다. 풀 요청을 보고 작업하기 위해 소스 리포지토리를 볼 필요는 없습니다. 풀 요청 상태는 생성할 때 **열기**로 설정됩니다. 풀 요청은 상태가 **병합됨**으로 변경되는 CodeCatalyst 콘솔에서 병합하거나 상태가 **종결됨**으로 변경될 때까지 열려 있습니다. 코드를 검토했으면 다음 방법 중 하나를 사용하여 풀 요청 상태를 변경할 수 있습니다. + CodeCatalyst 콘솔에서 풀 요청을 병합합니다. 풀 요청의 소스 브랜치에 있는 코드는 대상 브랜치로 병합됩니다. 풀 요청 상태가 **병합됨**으로 변경됩니다. 다시 **열기**로 변경할 수 없습니다. + 브랜치를 로컬로 병합하고 변경 사항을 푸시한 다음 CodeCatalyst 콘솔에서 풀 요청을 닫습니다. + 병합하지 않고 풀 요청을 닫으려면 CodeCatalyst 콘솔을 사용하세요. 이렇게 하면 상태가 **종료됨**으로 변경되고 소스 브랜치의 코드가 대상 브랜치로 병합되지 않습니다. 풀 요청을 생성하려면 먼저 다음을 수행해야 합니다. + 검토하려는 코드 변경 사항을 브랜치(소스 브랜치)에 커밋하고 푸시합니다. + 프로젝트에 대한 알림을 설정하여 풀 리퀘스트를 만들 때 실행되는 워크플로에 대해 다른 사용자가 알림을 받을 수 있도록 하세요. (이 단계는 선택 사항이며, 권장 사항은 아닙니다.) **Topics** + [풀 요청 생성](pull-requests-create.md) + [풀 요청 보기](pull-requests-view.md) + [풀 요청을 승인 규칙과 병합하기 위한 요구 사항 관리](source-pull-requests-approval-rules.md) + [풀 요청 검토](pull-requests-review.md) + [풀 요청 업데이트](pull-requests-update.md) + [풀 요청 병합](pull-requests-merge.md) + [풀 요청 닫기](pull-requests-close.md) # 풀 요청 생성 풀 요청을 생성하면 변경 내용을 다른 브랜치에 병합하기 전에 다른 사용자가 코드 변경을 보고 검토할 수 있습니다. 먼저 코드 변경을 위한 브랜치를 생성합니다. 이 브랜치를 풀 요청의 소스 브랜치라고도 합니다. 리포지토리에 변경 사항을 커밋하고 푸시한 후, 소스 브랜치의 내용을 대상 브랜치의 내용과 비교하는 풀 요청을 생성할 수 있습니다. Amazon CodeCatalyst 콘솔의 특정 브랜치, 풀 요청 페이지 또는 프로젝트 개요에서 풀 요청을 생성할 수 있습니다. 특정 브랜치에서 풀 요청을 생성하면 풀 요청 생성 페이지에 리포지토리 이름과 소스 브랜치가 자동으로 제공됩니다. 풀 요청을 생성하면 풀 요청에 대한 업데이트와 풀 요청이 병합되거나 종료되는 시기를 알려주는 이메일이 자동으로 수신됩니다. **참고** 풀 요청을 생성하는 동안 나타나는 차이는 소스 브랜치의 최신 커밋과 대상 브랜치의 최신 커밋의 차이입니다. 풀 요청이 생성되면, 표시된 차이는 선택한 풀 요청의 수정본과 풀 요청을 생성할 때 대상 브랜치의 가장 최신 커밋 간에 발생합니다. Git의 차이점 및 병합 기반에 대한 자세한 내용은 Git 설명서의 [git-merge-base](https://git-scm.com/docs/git-merge-base)를 참조하세요. 풀 요청을 생성할 때 **설명 쓰기** 기능을 사용하여 Amazon Q가 풀 요청에 포함된 변경 사항에 대한 설명을 자동으로 생성하도록 할 수 있습니다. 이 옵션을 선택하면 Amazon Q는 코드 변경 사항이 포함된 소스 브랜치와 이러한 변경 사항을 병합할 대상 브랜치 간의 차이를 분석합니다. 그런 다음 이러한 변경 사항에 대한 요약과 이러한 변경의 의도 및 효과에 대한 최상의 해석을 생성합니다. 이 기능은 CodeCatalyst 풀 요청에 대해 미국 서부(오리건) 리전에서만 사용할 수 있습니다. 연결된 리포지토리의 풀 요청에는 **설명 쓰기** 기능을 사용할 수 없습니다. **참고** **Amazon Bedrock:implements 자동 침해 탐지로 구동**됩니다. AWS [https://docs.aws.amazon.com//bedrock/latest/userguide/abuse-detection.html](https://docs.aws.amazon.com//bedrock/latest/userguide/abuse-detection.html) 소프트웨어 개발용 Amazon Q Developer Agent의 **설명 쓰기**, **콘텐츠 요약 생성**, **권장 작업**, **Amazon Q를 사용하여 프로젝트에 기능을 생성하거나 추가**, **Amazon Q에 문제 할당** 기능은 Amazon Bedrock에 구축되므로, 사용자는 Amazon Bedrock에서 구현된 제어 기능을 최대한 활용하여 안전, 보안 및 인공 지능(AI)을 책임 있게 사용할 수 있습니다. **풀 요청을 생성하려면** 1. 프로젝트로 이동합니다. 1. 다음 중 하나를 수행하세요. + 탐색 창에서 **코드**를 선택하고 **풀 요청**을 선택한 다음 **풀 요청 생성**을 선택합니다. + 리포지토리 홈 페이지에서 **추가**를 선택한 다음 **풀 요청 생성**을 선택합니다. + 프로젝트 페이지에서 **풀 요청 생성**을 선택합니다. 1. **소스 리포지토리**에서 지정된 소스 리포지토리가 커밋된 코드가 포함된 리포지토리인지 확인합니다. 이 옵션은 리포지토리의 메인 페이지에서 풀 요청을 생성하지 않은 경우에만 나타납니다. 1. **대상 브랜치**에서 코드를 검토한 후 병합할 브랜치를 선택합니다. 1. **소스 브랜치**에서 커밋된 코드가 포함된 브랜치를 선택합니다. 1. **풀 요청 제목**에 다른 사용자가 검토해야 할 사항과 이유를 이해하는 데 도움이 되는 제목을 입력합니다. 1. (선택 사항) **풀 요청 설명**에서 문제에 대한 연결 또는 변경 사항에 대한 설명과 같은 정보를 제공합니다. **작은 정보** CodeCatalyst가 풀 요청에 포함된 변경 사항에 대한 설명을 자동으로 생성하도록 **설명 쓰기**를 선택할 수 있습니다. 자동으로 생성된 설명은 풀 요청에 추가한 후에 변경할 수 있습니다. 이 기능을 사용하려면 스페이스에 생성형 AI 기능을 활성화해야 하며 연결된 리포지토리의 풀 요청에 사용할 수 없습니다. 자세한 내용은 [생성형 AI 기능 관리](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-generative-ai-features.html)를 참조하세요. 1. (선택 사항) **문제**에서 **문제 연결**을 선택한 다음 목록에서 문제를 선택하거나 해당 ID를 입력합니다. 문제를 연결 해제하려면 연결 해제 아이콘을 선택합니다. 1. (선택 사항) **필수 검토자**에서 **필수 검토자 추가**를 선택합니다. 프로젝트 멤버 목록에서 추가할 멤버를 선택합니다. 필수 검토자는 풀 요청을 대상 브랜치에 병합하기 전에 변경 사항을 승인해야 합니다. **참고** 검토자를 추가할 때 필수 검토자이면서 동시에 선택적 검토자로 추가할 수 없습니다. 자신을 검토자로 추가할 수 없습니다. 1. (선택 사항) **선택적 검토자**에서 **선택적 검토자 추가**를 선택합니다. 프로젝트 멤버 목록에서 추가할 멤버를 선택합니다. 선택적 검토자는 풀 요청을 대상 브랜치에 병합하기 전에 변경 사항을 요구 사항으로 승인할 필요가 없습니다. 1. 브랜치 간의 차이점을 검토합니다. 풀 요청에 표시되는 차이점은 소스 브랜치의 수정본과 풀 요청이 생성된 시점의 대상 브랜치의 헤드 커밋인 병합 기반 간의 변경 사항입니다. 변경 사항이 표시되지 않으면 브랜치가 동일하거나 소스와 대상 모두에 대해 동일한 브랜치를 선택했을 수 있습니다. 1. 풀 요청에 검토하려는 코드와 변경 사항이 포함되어 있다고 판단되면 **생성**을 선택합니다. **참고** 풀 요청을 생성한 후 설명을 추가할 수 있습니다. 풀 요청 또는 파일의 개별 줄 및 풀 요청 전반에 설명을 추가할 수 있습니다. @ 기호와 파일 이름을 사용하여 파일과 같은 리소스에 대한 연결을 추가할 수 있습니다. **브랜치에서 풀 요청을 생성하려면** 1. 풀 요청을 생성하려는 프로젝트로 이동합니다. 1. 탐색 창에서 **소스 리포지토리**를 선택한 다음, 검토할 코드 변경 사항이 있는 브랜치를 포함하는 리포지토리를 선택합니다. 1. 기본 브랜치 이름 옆의 드롭다운 화살표를 선택한 다음, 목록에서 원하는 브랜치를 선택합니다. 리포지토리의 모든 브랜치를 보려면 **모두 보기**를 선택합니다. 1. **추가**를 선택한 다음 **풀 요청 생성**을 선택합니다. 1. 리포지토리와 소스 브랜치는 미리 선택되어 있습니다. **대상 브랜치**에서 코드를 검토한 후 병합할 브랜치를 선택합니다. **풀 요청 제목**에 다른 프로젝트 사용자가 검토해야 하는 내용과 이유를 이해하는 데 도움이 되는 제목을 입력합니다. 선택적으로 CodeCatalyst 의 관련 문제에 대한 링크를 붙여넣거나 변경 사항에 대한 설명을 추가하는 등 **풀 요청 설명** 에 자세한 정보를 제공합니다. **참고** 풀 요청 생성 이벤트를 위해 실행하도록 구성된 워크플로는 풀 요청의 대상 브랜치가 워크플로에 지정된 브랜치 중 하나와 일치하는 경우 풀 요청이 생성된 후 실행됩니다. 1. 브랜치 간의 차이점을 검토합니다. 변경 사항이 표시되지 않으면, 브랜치가 동일하거나, 소스와 대상 모두에 대해 동일한 브랜치를 선택했을 수 있습니다. 1. (선택 사항) **문제**에서 **문제 연결**을 선택한 다음 목록에서 문제를 선택하거나 해당 ID를 입력합니다. 문제를 연결 해제하려면 연결 해제 아이콘을 선택합니다. 1. (선택 사항) **필수 검토자**에서 **필수 검토자 추가**를 선택합니다. 프로젝트 멤버 목록에서 추가할 멤버를 선택합니다. 필수 검토자는 풀 요청을 대상 브랜치에 병합하기 전에 변경 사항을 승인해야 합니다. **참고** 검토자를 필수 검토자이면서 동시에 선택적 검토자로 추가할 수 없습니다. 자신을 검토자로 추가할 수 없습니다. 1. (선택 사항) **선택적 검토자**에서 **선택적 검토자 추가**를 선택합니다. 프로젝트 멤버 목록에서 추가할 멤버를 선택합니다. 선택적 검토자는 풀 요청을 대상 브랜치에 병합하기 전에 변경 사항을 승인할 필요가 없습니다. 1. 풀 요청에 검토하려는 변경 사항이 포함되어 있고 필수 검토자가 포함되어 있다고 판단되면, **생성**을 선택합니다. 브랜치가 풀 요청의 대상 브랜치와 일치하는 워크플로를 실행하도록 구성된 경우 풀 요청이 생성된 후 **풀 요청 세부** 정보 영역의 **개요**에서 해당 워크플로 실행에 대한 정보를 볼 수 있습니다. 자세한 내용은 [워크플로에 트리거 추가](workflows-add-trigger-add.md) 단원을 참조하십시오. # 풀 요청 보기 Amazon CodeCatalyst 콘솔에서 프로젝트의 풀 요청을 볼 수 있습니다. 프로젝트 요약 페이지에는 프로젝트에 대한 모든 열린 풀 요청이 표시됩니다. 상태에 관계없이 모든 풀 요청을 보려면, 프로젝트의 풀 요청 페이지로 이동합니다. 풀 요청을 볼 때 생성된 풀 요청의 변경 사항에 대한 모든 설명의 요약을 남기도록 선택할 수 있습니다. **참고** **Amazon Bedrock:implements 자동 침해 탐지로 구동**됩니다. AWS [https://docs.aws.amazon.com//bedrock/latest/userguide/abuse-detection.html](https://docs.aws.amazon.com//bedrock/latest/userguide/abuse-detection.html) 소프트웨어 개발용 Amazon Q Developer Agent의 **설명 쓰기**, **콘텐츠 요약 생성**, **권장 작업**, **Amazon Q를 사용하여 프로젝트에 기능을 생성하거나 추가**, **Amazon Q에 문제 할당** 기능은 Amazon Bedrock에 구축되므로, 사용자는 Amazon Bedrock에서 구현된 제어 기능을 최대한 활용하여 안전, 보안 및 인공 지능(AI)을 책임 있게 사용할 수 있습니다. **열린 풀 요청을 보려면** 1. 풀 요청을 보려는 프로젝트로 이동합니다. 1. 프로젝트 페이지에 풀 요청을 생성한 사람, 풀 요청에 대한 브랜치를 포함하는 리포지토리, 풀 요청이 생성된 날짜에 대한 정보를 포함하여 열린 풀 요청이 표시됩니다. 소스 리포지토리별로 열린 풀 요청 보기를 필터링할 수 있습니다. 1. 모든 풀 요청을 보려면 **모두 보기**를 선택합니다. 선택기를 사용하여 옵션 중에서 선택할 수 있습니다. 예를 들어, 모든 풀 요청을 보려면 **모든 상태** 및 **모든 작성자**를 선택합니다. 또는 탐색 창에서 **코드**를 선택한 다음 **풀 요청**을 선택한 다음, 선택기를 사용하여 보기를 구체화합니다. 1. **풀 요청** 페이지에서 ID, 제목, 상태 등을 기준으로 풀 요청을 정렬할 수 있습니다. 풀 요청 페이지에 표시되는 정보와 정보의 양을 사용자 지정하려면, 기어 아이콘을 선택합니다. 1. 특정 풀 요청을 보려면 목록에서 선택합니다. 1. 이 풀 요청과 연결된 워크플로 실행의 상태를 보려면 **개요**를 선택하고, **워크플로 실행**에서 풀 요청의 **풀 요청 세부 정보** 영역의 정보를 검토합니다. 워크플로가 풀 요청 생성 또는 수정 이벤트로 구성되어 있고 워크플로의 대상 브랜치 요구 사항이 풀 요청에 지정된 대상 브랜치와 일치하는 경우, 워크플로 실행이 발생합니다. 자세한 내용은 [워크플로에 트리거 추가](workflows-add-trigger-add.md) 단원을 참조하십시오. 1. 연결된 문제를 보려면 **개요**를 선택하고 **문제**에서 **풀 요청 세부 정보**의 정보를 검토합니다. 연결된 문제를 보려면 목록에서 해당 ID를 선택합니다. 1. (선택 사항) 풀 요청 수정본의 코드 변경에 남아 있는 설명에 대해 요약을 생성하려면 **콘텐츠 요약 생성**을 선택합니다. 요약에는 전체 풀 요청에 남아 있는 설명이 포함되지 않습니다. **참고** 이 기능을 사용하려면 생성형 AI 기능이 스페이스에 활성화되어 있어야 하고, 연결된 리포지토리에는 사용할 수 없으며, 미국 서부(오리건) 리전에서만 사용할 수 있습니다. 자세한 내용은 [생성형 AI 기능 관리](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-generative-ai-features.html)를 참조하세요. 1. 풀 요청에서 코드 변경 사항을 보려면 **변경**을 선택합니다. 풀 요청에서 변경 사항이 있는 파일의 수와 설명이 있는 파일은 **변경된 파일**에서 빠르게 볼 수 있습니다. 폴더 옆에 표시되는 설명 수는 해당 폴더의 파일에 대한 설명 수를 나타냅니다. 폴더를 확장하여 폴더의 각 파일에 대한 설명 수를 확인합니다. 특정 코드 줄에 남아 있는 모든 설명을 볼 수도 있습니다. **참고** 콘솔에 풀 요청의 모든 변경 사항을 표시할 수 있는 것은 아닙니다. 예를 들어, 콘솔에서 Git 하위 모듈을 볼 수 없으므로 풀 요청에서 하위 모듈의 차이를 볼 수 없습니다. 일부 차이는 표시하기에 너무 클 수 있습니다. 자세한 내용은 [CodeCatalyst의 소스 리포지토리 할당량](source-quotas.md) 및 [파일 보기파일 변경 내역 보기](source-files-view.md) 섹션을 참조하세요. 1. 이 풀 요청에 대한 품질 보고서를 보려면 **보고서**를 선택합니다. **참고** 풀 요청에 나타나는 보고서를 생성하도록 워크플로를 구성해야 합니다. 자세한 내용은 [워크플로를 사용한 테스트워크플로를 사용한 테스트](test-workflow-actions.md) 단원을 참조하십시오. # 풀 요청을 승인 규칙과 병합하기 위한 요구 사항 관리 풀 요청을 생성할 때 개별 풀 요청에 필수 또는 선택적 검토자를 추가하도록 선택할 수 있습니다. 그러나 특정 대상 브랜치에 병합할 때 모든 풀 요청이 충족해야 하는 요구 사항을 생성할 수도 있습니다. 이러한 요구 사항을 승인 규칙이라고 합니다. 리포지토리의 브랜치에 대해 승인 규칙이 구성됩니다. 대상 브랜치에 승인 규칙이 구성된 풀 요청을 생성할 때는 풀 요청을 해당 브랜치에 병합하기 전에 필요한 검토자의 승인 외에도 해당 규칙의 요구 사항을 충족해야 합니다. 승인 규칙을 생성하면 가 기본 브랜치와 같은 브랜치에 병합하기 위한 품질 표준을 유지하는 데 도움이 될 수 있습니다. 소스 리포지토리의 기본 브랜치에 적용되는 승인 규칙은 다른 브랜치에 적용되는 승인 규칙과 약간 다르게 작동합니다. 기본 브랜치에 적용되는 모든 규칙은 기본 브랜치로 지정한 모든 브랜치에 자동으로 적용됩니다. 이전에 기본 브랜치로 설정된 브랜치에는 해당 브랜치에 적용된 규칙이 계속 유지됩니다. 승인 규칙을 만들 때는 현재와 미래의 프로젝트 사용자가 해당 규칙을 어떻게 충족할지 고려해야 합니다. 예를 들어 프로젝트에 6명의 사용자가 있고 대상 브랜치에 병합하기 전에 5명의 승인이 필요한 승인 규칙을 만들면, 풀 리퀘스트를 만든 사람을 제외한 모든 사람이 해당 풀 리퀘스트를 승인해야 병합할 수 있는 규칙을 만든 것이 됩니다. **참고** CodeCatalyst 프로젝트에서 승인 규칙을 만들고 관리하려면 프로젝트 관리자 역할이 있어야 합니다. 연결된 리포지토리에 대한 승인 규칙은 생성할 수 없습니다. 승인 규칙을 삭제할 수는 없지만 승인 횟수가 0이 되도록 업데이트하여 규칙을 효과적으로 제거할 수는 있습니다. **풀 요청에 대한 대상 브랜치의 승인 규칙 보기 및 편집** 1. 리포지토리가 있는 프로젝트로 이동합니다. 1. 프로젝트의 소스 리포지토리 목록에서 리포지토리 이름을 선택합니다. 아니면 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다. 승인 규칙을 보려는 리포지토리를 선택합니다. 1. 리포지토리의 개요 페이지에서 **브랜치**를 선택합니다. 1. **승인 규칙** 열에서 **보기**를 선택하여 리포지토리의 각 브랜치에 대한 규칙 상태를 확인합니다. **최소 승인 수**에서 숫자는 풀 요청을 해당 브랜치에 병합하기 위해 필요한 승인 수에 해당합니다. 1. 승인 규칙을 생성하거나 변경하려면 **설정 관리**를 선택합니다. 소스 리포지토리 설정 페이지에 있는 **승인 규칙**에서 **편집**을 선택합니다. **참고** 승인 규칙을 편집하려면 **프로젝트 관리자** 역할이 있어야 합니다. 1. **브랜치**의 드롭다운 목록에서 승인 규칙을 구성할 브랜치의 이름을 선택합니다. **최소 승인 수**에서 숫자를 입력한 다음 **저장**을 선택합니다. # 풀 요청 검토 Amazon CodeCatalyst 콘솔을 사용하여 풀 요청에 포함된 변경 사항을 공동으로 검토하고 의견을 제시할 수 있습니다. 소스 브랜치와 대상 브랜치 간의 차이 또는 풀 요청의 개정 간의 차이에서 개별 코드 줄에 설명을 추가할 수 있습니다. 풀 요청의 코드 변경에 남아 있는 설명의 요약을 생성하여, 다른 사용자가 남긴 피드백을 빠르게 이해할 수 있도록 할 수 있습니다. 코드 작업을 위한 개발 환경을 생성하도록 선택할 수도 있습니다. **참고** **Amazon Bedrock:implements 자동 침해 탐지로 구동**됩니다. AWS [https://docs.aws.amazon.com//bedrock/latest/userguide/abuse-detection.html](https://docs.aws.amazon.com//bedrock/latest/userguide/abuse-detection.html) 소프트웨어 개발용 Amazon Q Developer Agent의 **설명 쓰기**, **콘텐츠 요약 생성**, **권장 작업**, **Amazon Q를 사용하여 프로젝트에 기능을 생성하거나 추가**, **Amazon Q에 문제 할당** 기능은 Amazon Bedrock에 구축되므로, 사용자는 Amazon Bedrock에서 구현된 제어 기능을 최대한 활용하여 안전, 보안 및 인공 지능(AI)을 책임 있게 사용할 수 있습니다. **작은 정보** 프로파일의 일부로서 이메일을 수신할 풀 요청 이벤트를 구성할 수 있습니다. 자세한 내용은 [CodeCatalyst에서 Slack 및 이메일 알림 전송](notifications-manage.md) 단원을 참조하십시오. 풀 요청은 풀 요청의 개정과 풀 요청을 생성할 때 대상 브랜치의 최신 커밋이었던 커밋 간의 차이를 보여줍니다. 이를 병합 기반이라고 합니다. Git의 차이점 및 병합 기반에 대한 자세한 내용은 Git 설명서의 [git-merge-base](https://git-scm.com/docs/git-merge-base)를 참조하세요. **작은 정보** 콘솔에서 작업할 때, 특히 풀 요청이 한동안 열려있는 경우, 검토를 시작하기 전에 풀 요청에 사용할 수 있는 최신 수정본이 있는지 확인하기 위해 브라우저를 새로 고치는 것이 좋습니다. **CodeCatalyst 콘솔에서 풀 요청을 검토하려면** 1. 프로젝트로 이동합니다. 1. 다음 중 하나를 수행하여 풀 요청으로 이동합니다. + 풀 요청이 프로젝트 페이지에 나열되면, 목록에서 선택합니다. + 풀 요청이 프로젝트 페이지에 나열되지 않은 경우, **모두 보기**를 선택합니다. 필터와 정렬을 사용하여 풀 요청을 찾은 다음, 목록에서 선택합니다. + 탐색 창에서 **코드**를 선택한 다음, **풀 요청**을 선택합니다. 1. 목록에서 검토하려는 풀 요청을 선택합니다. 필터 표시줄에 이름의 일부를 입력하여 풀 요청 목록을 필터링할 수 있습니다. 1. **개요**에서 풀 요청의 이름과 제목을 검토할 수 있습니다. 풀 요청 자체에 남아 있는 설명을 생성하고 볼 수 있습니다. 워크플로 실행, 연결된 문제, 검토자, 풀 요청 작성자, 실행 가능한 병합 전략에 대한 정보를 포함하여 풀 요청의 세부 정보를 볼 수도 있습니다. **참고** 특정 코드 줄에 남긴 설명은 **변경 사항**에 표시됩니다. 1. (선택 사항) 전체 풀 요청에 적용되는 설명을 추가하려면 **풀 요청에 대한 설명**을 확장한 다음 **설명 생성** 선택합니다. 1. (선택 사항) 이 풀 요청 수정본의 변경 사항에 대해 남아 있는 모든 설명의 요약을 보려면 **설명 요약 생성**을 선택합니다. **참고** 이 기능을 사용하려면 생성형 AI 기능이 스페이스에 대해 활성화되어 있어야 하며 미국 서부(오리건) 리전에서만 사용할 수 있습니다. 자세한 내용은 [생성형 AI 기능 관리](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-generative-ai-features.html)를 참조하세요. 1. **변경**에서 대상 브랜치와 풀 요청의 최신 수정본 간의 차이점을 확인할 수 있습니다. 수정본이 두 개 이상 있는 경우, 차이에서 비교할 수정본을 변경할 수 있습니다. 수정에 대한 자세한 내용은 [개정](source-concepts.md#revision-concept) 섹션을 참조하세요. **작은 정보** 풀 요청에서 변경 사항이 있는 파일의 수와 설명이 있는 파일은 **변경된 파일**에서 빠르게 볼 수 있습니다. 폴더 옆에 표시되는 설명 수는 해당 폴더의 파일에 대한 설명 수를 나타냅니다. 폴더를 확장하여 폴더의 각 파일에 대한 설명 수를 확인합니다. 1. 차이가 표시되는 방식을 변경하려면, **통합** 및 **분할** 중에서 선택합니다. 1. 풀 요청의 행에 설명을 추가하려면, 설명을 작성할 행으로 이동합니다. 해당 행에 나타나는 설명 아이콘을 선택하고 설명을 입력한 다음 **저장**을 선택합니다. 1. 풀 요청의 수정본 간 또는 소스 브랜치와 대상 브랜치 간의 변경 사항을 보려면, **비교**에서 사용 가능한 옵션을 선택합니다. 수정본에서 행에 대한 설명은 해당 수정본에 보존됩니다. 1. 풀 요청 트리거에 대한 코드 적용 범위 보고서를 생성하도록 워크플로를 구성한 경우, 관련 풀 요청에서 행 및 브랜치 적용 범위 조사 결과를 볼 수 있습니다. 코드 적용 범위 조사 결과를 숨기려면 **코드 적용 범위 숨기기**를 선택합니다. 자세한 내용은 [코드 적용 범위 보고서](test-workflow-actions.md#test-code-coverage-reports) 단원을 참조하십시오. 1. 풀 요청에서 코드 변경하려는 경우, 풀 요청에서 개발 환경을 생성할 수 있습니다. **개발 환경 생성**을 선택합니다. 선택적으로 개발 환경의 이름을 추가하거나 구성을 편집한 다음, **생성**을 선택합니다. 1. **보고서**에서 이 풀 요청의 품질 보고서를 볼 수 있습니다. 수정본이 두 개 이상 있는 경우, 차이에서 비교할 수정본을 변경할 수 있습니다. 보고서를 이름, 상태, 워크플로, 작업 및 유형별로 필터링할 수 있습니다. **참고** 풀 요청에 나타나는 보고서를 생성하도록 워크플로를 구성해야 합니다. 자세한 내용은 [작업에서 품질 보고서 구성](test-config-action.md) 단원을 참조하십시오. 1. 특정 보고서를 보려면, 목록에서 선택합니다. 자세한 내용은 [워크플로를 사용한 테스트워크플로를 사용한 테스트](test-workflow-actions.md) 단원을 참조하십시오. 1. 이 풀 요청의 검토자로 등록되어 있고 변경 사항을 승인하려면, 최신 수정본을 보고 있는지 확인한 다음 **승인**을 선택합니다. **참고** 모든 필수 검토자는 풀 요청을 승인해야 병합할 수 있습니다. # 풀 요청 업데이트 풀 요청을 업데이트하여 다른 프로젝트 멤버가 코드를 더 쉽게 검토할 수 있습니다. 풀 요청을 업데이트하여 검토자, 문제에 대한 링크, 풀 요청 제목 또는 설명을 변경할 수 있습니다. 예를 들어, 풀 요청에 필수 검토자를 변경하여 휴가 중인 사람을 제거하고 다른 사람을 추가할 수 있습니다. 풀 요청 업데이트는 열린 풀 요청의 소스 브랜치에 커밋을 푸시하여 추가 코드를 변경하는 방식으로 수행할 수 있습니다. CodeCatalyst 소스 리포지토리에서 풀 요청의 소스 브랜치로 푸시할 때마다 수정본이 생성됩니다. 프로젝트 멤버는 풀 요청에서 수정본 간의 차이점을 볼 수 있습니다. **풀 요청에 대한 검토자를 업데이트하려면** 1. 풀 요청의 검토자를 업데이트하려는 프로젝트로 이동합니다. 1. 프로젝트 페이지의 **풀 요청 열기**에서 검토자를 업데이트하려는 풀 요청을 선택합니다. 또는 탐색 창에서 **코드**를 선택하고 **풀 요청**을 선택한 다음 업데이트할 풀 요청을 선택합니다. 1. (선택 사항) **개요**의 **풀 요청 세부 정보** 영역에서 더하기 기호를 선택하여 필수 또는 선택적 검토자를 추가합니다. 검토자 옆의 **X**를 선택하여 선택적 또는 필수 검토자를 제거합니다. 1. (선택 사항) **개요의** **풀 요청 세부 정보** 영역에서 **문제 연결**을 선택하여 풀 요청에 문제를 연결한 다음, 목록에서 문제를 선택하거나 해당 ID를 입력합니다. 문제를 연결 해제하려면, 연결 해제하려는 문제 옆에 있는 연결 해제 아이콘을 선택합니다. **풀 요청의 소스 브랜치에서 파일 및 코드를 업데이트하려면** 1. 여러 파일을 업데이트하려면, [개발 환경을 생성](devenvironment-create.md)하거나 리포지토리 및 해당 소스 브랜치를 복제하고, Git 클라이언트 또는 통합 개발 환경(IDE)을 사용하여 소스 브랜치의 파일을 변경합니다. CodeCatalyst 소스 리포지토리의 소스 브랜치에 변경 사항을 커밋하고 푸시하여, 변경 사항으로 풀 요청을 자동으로 업데이트합니다. 자세한 내용은 [소스 리포지토리 복제](source-repositories-clone.md) 및 [Amazon CodeCatalyst에서 커밋을 사용한 소스 코드 변경 사항 이해](source-commits.md) 섹션을 참조하세요. 1. 소스 브랜치에서 개별 파일을 업데이트하려면, 여러 파일에 대해 업데이트 할 때처럼 Git 클라이언트 또는 IDE를 사용할 수 있습니다. CodeCatalyst 콘솔에서 직접 편집할 수도 있습니다. 자세한 내용은 [파일 편집](source-files-edit.md) 단원을 참조하십시오. **풀 요청의 제목 및 설명을 업데이트하려면** 1. 풀 요청의 제목 또는 설명을 업데이트하려는 프로젝트로 이동합니다. 1. 프로젝트 페이지에는 풀 요청을 생성한 사람, 풀 요청에 대한 브랜치가 포함된 리포지토리, 풀 요청이 생성된 시기에 대한 정보를 포함한 열린 풀 요청이 표시됩니다. 소스 리포지토리별로 열린 풀 요청 보기를 필터링할 수 있습니다. 목록에서 변경하려는 풀 요청을 선택합니다. 1. 모든 풀 요청을 보려면 **모두 보기**를 선택합니다. 또는 탐색 창에서 **코드**를 선택한 다음 **풀 요청**을 선택합니다. 필터 상자 또는 정렬 함수를 사용하여 변경하려는 풀 요청을 찾은 다음, 해당 풀 요청을 선택합니다. 1. **개요**에서 **편집**을 선택합니다. 1. 제목 또는 설명을 변경한 다음 **저장**을 선택합니다. # 풀 요청 병합 코드를 검토하고 모든 필수 검토자가 승인하면, 패스트 포워드와 같은 지원되는 병합 전략을 사용하여 CodeCatalyst 콘솔에서 풀 요청을 병합할 수 있습니다. CodeCatalyst 콘솔에서 지원되는 모든 병합 전략을 모든 풀 요청에서 선택하여 사용할 수 있는 것은 아닙니다. CodeCatalyst는 병합을 평가하며, 콘솔에서 사용할 수 있고 소스 브랜치를 대상 브랜치로 병합할 수 있는 병합 전략 중에서만 선택할 수 있습니다. 로컬 컴퓨터나 개발 환경에서 **git merge** 명령을 실행해 소스 브랜치를 대상 브랜치로 병합하여, 풀 요청을 선택한 Git 병합 전략과 병합할 수도 있습니다. 그런 다음 대상 브랜치의 변경 사항을 CodeCatalyst의 소스 리포지토리로 푸시할 수 있습니다. **참고** Git에서 브랜치를 병합하고 변경 사항을 푸시해도 풀 요청이 자동으로 닫히지 않습니다. 프로젝트 관리자 역할이 있는 경우, 승인 및 승인 규칙에 대한 모든 요구 사항을 아직 충족하지 않은 풀 요청을 병합하도록 선택할 수도 있습니다. ## 풀 요청 병합 (콘솔) 소스 브랜치와 대상 브랜치 간에 병합 충돌이 없고 모든 필수 검토자가 풀 요청을 승인한 경우, CodeCatalyst 콘솔에서 풀 요청을 병합할 수 있습니다. 충돌이 있거나 병합을 완료할 수 없는 경우, 병합 버튼이 비활성화되고 **병합할 수 없음** 레이블이 표시됩니다. 이 경우 임의의 필수 검토자의 승인을 얻고, 필요한 경우 충돌을 로컬에서 해결한 다음, 이러한 변경 사항을 푸시해야 병합할 수 있습니다. 풀 요청을 병합하면 풀 요청 생성자와 필수 또는 선택적 검토자에게 이메일이 자동으로 전송됩니다. 풀 요청에 연결된 문제는 자동으로 닫히거나 상태가 변경되지 않습니다. **작은 정보** 프로파일의 일부로서 이메일을 수신할 풀 요청 이벤트를 구성할 수 있습니다. 자세한 내용은 [CodeCatalyst에서 Slack 및 이메일 알림 전송](notifications-manage.md) 단원을 참조하십시오. **풀 요청 병합을 병합하려면** 1. 풀 요청을 병합하려는 프로젝트로 이동합니다. 1. 프로젝트 페이지의 **풀 요청 열기**에서 병합할 풀 요청을 선택합니다. 풀 요청이 표시되지 않으면 **모든 풀 요청 보기**를 선택한 다음 목록에서 선택합니다. 또는 탐색 창에서 **코드**를 선택하고 **풀 요청**을 선택한 다음 병합할 풀 요청을 선택합니다. **병합**을 선택합니다. 1. 풀 요청에서 사용 가능한 병합 전략 중에서 선택합니다. 선택적으로 풀 요청을 병합한 후 소스 브랜치를 삭제하는 옵션을 선택하거나 선택 취소한 다음, **병합**을 선택합니다. **참고** **병합** 버튼이 비활성 상태이거나 **병합할 수 없음** 레이블이 표시되는 경우, 필수 검토자가 아직 풀 요청을 승인하지 않았거나 CodeCatalyst 콘솔에서 풀 요청을 병합할 수 없는 것입니다. 풀 요청을 승인하지 않은 검토자는 **개요**의 **풀 요청 세부 정보** 영역에 시계 아이콘으로 표시됩니다. 모든 필수 검토자가 풀 요청을 승인했지만 **병합** 버튼이 여전히 비활성 상태인 경우, 병합 충돌이 발생할 수 있습니다. 밑줄이 그어진 **병합할 수 없음** 레이블을 선택하여 풀 요청을 병합할 수 없는 이유에 대한 자세한 내용을 확인합니다. 개발 환경 또는 CodeCatalyst 콘솔에서 대상 브랜치의 병합 충돌을 해결한 뒤, 풀 요청을 병합하거나 충돌을 해결하고 로컬에서 병합한 다음, 병합이 포함된 커밋을 CodeCatalyst의 소스 브랜치로 푸시할 수 있습니다. 자세한 내용은 [풀 요청 병합(Git)](#pull-requests-merge-git) 섹션 및 Git 설명서를 참조하세요. ## 병합 요구 사항 재정의 **프로젝트 관리자** 역할이 있는 경우, 필수 승인 및 승인 규칙에 대한 모든 요구 사항을 아직 충족하지 못한 풀 요청을 병합하도록 선택할 수 있습니다. 이를 풀 요청의 요구 사항 재정의라고 합니다. 필수 검토자가 작업할 수 없거나 특정 풀 요청을 신속하게 충족할 수 없는 승인 규칙이 있는 브랜치에 병합해야 하는 긴급한 필요가 발생하는 경우, 이 작업을 수행할 수 있습니다. **풀 요청 병합을 병합하려면** 1. 요구 사항을 재정의하고 병합하려는 풀 요청에서 **병합** 버튼 옆의 드롭다운 화살표를 선택합니다. **승인 요구 사항 재정의**를 선택합니다. 1. **재정의 이유**에서 승인 규칙 및 필수 검토자 요구 사항을 충족하지 않고 이 풀 요청을 병합하는 이유에 대한 세부 정보를 제공합니다. 이는 선택 사항이지만 적극 권장됩니다. 1. 선택 사항으로 병합 전략을 선택하거나 기본값을 수락합니다. 자동 생성된 커밋 메시지와 추가적인 세부 정보를 업데이트하도록 선택할 수도 있습니다. 1. 병합 시 소스 브랜치를 삭제하는 옵션을 선택하거나 선택 취소합니다. 풀 요청을 병합하기 위한 요구 사항을 재정의할 때는 다른 팀원과 결정을 검토할 수 있을 때까지 소스 브랜치를 유지하는 것이 좋습니다. 1. **병합**을 선택합니다. ## 풀 요청 병합(Git) Git은 브랜치를 병합하고 관리하기 위한 다양한 옵션을 지원합니다. 다음은 명령은 사용할 수 있는 몇 가지 옵션입니다. 자세한 내용은 [Git 웹사이트](https://git-scm.com/doc)에서 확인할 수 있는 설명서를 참조하세요. 변경 사항을 병합하고 푸시한 후에는 풀 요청을 수동으로 닫습니다. 자세한 내용은 [풀 요청 닫기](pull-requests-close.md) 단원을 참조하십시오. **브랜치 병합을 위한 공통 Git 명령** | | | | --- |--- | | 로컬 리포지토리의 소스 브랜치에서 변경한 내용을 로컬 리포지토리의 대상 브랜치에 병합합니다. | `git checkout destination-branch-name` `git merge source-branch-name` | | 소스 브랜치를 대상 브랜치로 병합하여 패스트 포워드 병합을 지정합니다. 이렇게 하면 브랜치가 병합되고 대상 브랜치 포인터가 소스 브랜치의 최신 커밋으로 이동합니다. | `git checkout destination-branch-name` `git merge --ff-only source-branch-name` | | 소스 브랜치를 대상 브랜치로 병합하며 스쿼시 병합을 지정합니다. 이렇게 하면 소스 브랜치의 모든 커밋이 대상 브랜치의 단일 병합 커밋으로 결합됩니다. | `git checkout destination-branch-name` `git merge --squash source-branch-name` | | 소스 브랜치를 대상 브랜치로 병합하며 3방향 병합을 지정합니다. 이렇게 하면 병합 커밋이 생성되고 소스 브랜치의 개별 커밋이 대상 브랜치에 추가됩니다. | `git checkout destination-branch-name` `git merge --no-ff source-branch-name` | | 로컬 리포지토리에서 소스 브랜치를 삭제합니다. 이는 대상 브랜치로 병합하고 변경 사항을 소스 리포지토리로 푸시한 후, 로컬 리포지토리를 정리하는 데 유용합니다. | `git branch -d source-branch-name` | | 원격 리포지토리에 대해 지정된 로컬 리포지토리 별명을 사용하여 원격 리포지토리(CodeCatalyst의 소스 리포지토리)의 소스 브랜치를 삭제합니다. (콜론(`:`) 사용에 주의하세요.) 또는 명령의 일부로 `--delete`를 지정합니다. | `git push remote-name :source-branch-name` `git push remote-name --delete source-branch-name` | # 풀 요청 닫기 풀 요청을 **종결됨**으로 표시할 수 있습니다. 이렇게 하면 풀 요청이 병합되지 않지만 작업이 필요한 풀 요청과 더 이상 관련이 없는 풀 요청을 판단하는 데 도움이 될 수 있습니다. 더 이상 이러한 변경 사항을 병합할 계획이 없거나 변경 사항이 다른 풀 요청에서 병합된 경우, 풀 요청을 닫는 것이 좋습니다. 풀 요청을 닫으면 풀 요청 생성자와 필수 또는 선택적 검토자에게 이메일이 자동으로 전송됩니다. 풀 요청을 닫더라도 풀 요청에 연결된 문제의 상태는 자동으로 변경되지 않습니다. **참고** 풀 요청을 닫은 후에는 다시 열 수 없습니다. **풀 요청을 닫으려면** 1. 풀 요청을 닫으려는 프로젝트로 이동합니다. 1. 프로젝트 페이지에 열린 풀 요청이 표시됩니다. 닫으려는 풀 요청을 선택합니다. 1. **닫기**를 선택하세요. 1. 정보를 검토한 후 **닫기**를 선택합니다. # Amazon CodeCatalyst에서 커밋을 사용한 소스 코드 변경 사항 이해 커밋은 리포지토리의 콘텐츠 및 변경 사항에 대한 스냅샷입니다. 사용자가 브랜치에 변경 내용을 커밋하고 푸시할 때마다 해당 정보가 저장됩니다. Git 커밋 정보에는 커밋 작성자, 변경 사항을 커밋한 사람, 날짜 및 시간, 변경 사항이 포함됩니다. Amazon CodeCatalyst 콘솔에서 파일을 생성하거나 편집할 때 유사한 정보가 자동으로 포함되지만 작성자 이름은 CodeCatalyst 사용자 이름입니다. 특정 커밋을 식별하는 데 도움이 되도록 커밋에 Git 태그를 추가할 수도 있습니다. Amazon CodeCatalyst에서 다음을 수행할 수 있습니다. + 브랜치에 대한 커밋 목록을 봅니다. + 상위 또는 상위와 비교할 때 커밋의 변경 사항을 포함하여 개별 커밋을 봅니다. 파일과 폴더를 볼 수도 있습니다. 자세한 내용은 [Amazon CodeCatalyst에서 소스 코드 파일 관리](source-files.md) 섹션을 참조하세요. **Topics** + [브랜치에 대한 커밋 보기](#source-commits-view) + [커밋 표시 방식 변경(CodeCatalyst 콘솔)](#source-commits-settings) ## 브랜치에 대한 커밋 보기 CodeCatalyst 콘솔에서 브랜치 커밋을 검토하여 브랜치 변경 기록을 볼 수 있습니다. 이렇게 하면 누가 언제 브랜치를 변경했는지 이해하는 데 도움이 됩니다. 특정 커밋에서 변경된 내용을 검토할 수도 있습니다. **작은 정보** 특정 파일을 변경한 커밋의 기록을 볼 수도 있습니다. 자세한 내용은 [파일 보기파일 변경 내역 보기](source-files-view-history.md)을 참조하세요. Git 클라이언트를 사용하여 커밋을 볼 수도 있습니다. 자세한 내용은 Git 설명서를 참조하세요. **커밋 보기(콘솔)** 1. 커밋을 보려는 소스 리포지토리가 포함된 프로젝트로 이동합니다. 1. 프로젝트의 소스 리포지토리 목록에서 리포지토리 이름을 선택합니다. 아니면 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다. 브랜치에 커밋을 보려는 리포지토리를 선택합니다. 1. 리포지토리의 기본 브랜치가 표시되며, 브랜치에 대한 가장 최근 커밋에 대한 정보도 포함됩니다. **커밋**을 선택합니다. 또는 **추가**를 선택한 다음 **커밋 보기**를 선택합니다. 1. 다른 브랜치에 대한 커밋을 보려면 브랜치 선택기를 선택한 다음 브랜치의 이름을 선택합니다. 1. 특정 커밋에 대한 세부 정보를 보려면 **커밋 제목**에서 해당 제목을 선택합니다. 상위 커밋에 대한 정보와 상위 커밋을 지정된 커밋과 비교하여 코드를 변경한 내용을 포함하여 커밋에 대한 세부 정보가 표시됩니다. **작은 정보** 커밋에 둘 이상의 상위가 있는 경우 상위 커밋 ID 옆의 드롭다운 아이콘을 선택하여 정보를 보고 변경 사항을 표시할 상위 커밋을 선택할 수 있습니다. ## 커밋 표시 방식 변경(CodeCatalyst 콘솔) **커밋** 보기에 표시되는 정보를 변경할 수 있습니다. 작성자 및 커밋 ID와 같은 열을 숨기거나 표시하도록 선택할 수 있습니다. **커밋 표시 방법 변경(콘솔)** 1. 커밋을 보려는 소스 리포지토리가 포함된 프로젝트로 이동합니다. 1. 프로젝트의 소스 리포지토리 목록에서 리포지토리 이름을 선택합니다. 아니면 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다. 커밋을 보는 방식을 변경하려는 리포지토리를 선택합니다. 1. 리포지토리의 기본 브랜치가 표시되며, 브랜치에 대한 가장 최근 커밋에 대한 정보도 포함됩니다. **커밋**을 선택합니다. 1. 기어 모양 아이콘을 선택합니다. 1. **기본 설정**에서 표시할 커밋 수를 선택하고 커밋 작성자, 커밋 날짜 및 커밋 ID에 대한 정보를 표시할지 여부를 선택합니다. **참고** 정보 표시에서는 커밋 제목을 숨길 수 없습니다. 1. 변경한 후에는 **저장**을 선택하여 저장하거나 **취소**를 선택하여 취소합니다. # CodeCatalyst의 소스 리포지토리 할당량 다음 테이블에서는 Amazon CodeCatalyst의 소스 리포지토리에 대한 쿼터 및 제한에 대해 설명합니다. Amazon CodeCatalyst의 할당량에 대한 자세한 내용은 [CodeCatalyst 할당량](quotas.md) 섹션을 참조하세요. | Resource | 정보 | | --- | --- | | 브랜치 이름 | 허용되는 문자의 길이는 1\$1256자 사이이며 리포지토리 내에서 고유한 문자의 조합이어야 합니다. 브랜치 이름에는 다음과 같은 제한이 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/source-quotas.html) 브랜치 이름은 참조입니다. 브랜치 이름에 대한 대부분의 제한 사항은 Git 참조 표준에 근거합니다. 자세한 내용은 [Git Internals](https://git-scm.com/book/en/v2/Git-Internals-Git-References) 및 [git-check-ref-format](https://git-scm.com/docs/git-check-ref-format)을 참조하세요. | | 풀 요청에 대한 설명 | 풀 요청 시 최대 1,000개. | | 커밋 메시지 | 최대 1,024자입니다. | | 파일 경로 | 1\$14,096자의 허용되는 문자 조합이면 됩니다. 파일 경로는 파일과 파일의 정확한 위치를 지정하는 명확한 이름이어야 합니다. 파일 경로는 깊이가 디렉터리 20개를 초과할 수 없습니다. 또한 파일 경로는 다음과 같아서는 안 됩니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/source-quotas.html) 파일 이름 및 경로는 정규화된 이름과 경로여야합니다. 로컬 컴퓨터의 파일 이름과 경로는 해당 운영 체제에 대한 표준을 따라야 합니다. 리포지토리의 파일에 경로를 지정할 때는 Amazon Linux에 대한 표준을 사용합니다. | | 파일 크기 | CodeCatalyst 콘솔 사용 시 개별 파일의 경우 최대 6MB입니다. | | CodeCatalyst 콘솔에서 볼 수 있는 파일 크기 | CodeCatalyst 콘솔 사용 시 개별 파일의 경우 최대 6MB입니다. | | Git BLOB 크기 | 최대 2GB 단일 커밋의 모든 파일 수 또는 총 파일 크기에 대한 제한은 없습니다. 단, 메타데이터는 6MB를 초과할 수 없고 단일 BLOB은 2GB를 초과할 수 없습니다. 그러나 모범 사례로 하나의 대규모 커밋이 아닌 여러 개의 소규모 커밋을 수행하는 것이 좋습니다. | | 커밋에 대한 메타데이터 | [커밋에 대한 결합 메타데이터](https://git-scm.com/book/en/v2/Git-Internals-Git-Objects)(예시: 작성자 정보, 날짜, 상위 커밋 목록, 커밋 메시지 조합)의 경우 최대 6MB입니다. 단일 커밋의 모든 파일 수 또는 총 파일 크기에 대한 제한은 없습니다. 단, 데이터는 20MB를 초과할 수 없고 개별 파일은 6MB를 초과할 수 없으며 단일 BLOB은 2GB를 초과할 수 없습니다. | | 풀 요청에 연결할 수 있는 CodeCatalyst 문제 수 | 50 | | 풀 요청에 연결할 수 있는 Jira 문제 수 | 50 | | 스페이스에 열려 있는 풀 요청 수 | Amazon CodeCatalyst 스페이스의 경우 최대 1,000개입니다. | | 스페이스의 총 풀 요청 수 | Amazon CodeCatalyst 스페이스의 경우 최대 10,000개입니다. | | 단일 푸시의 참조 수 | 생성, 삭제, 업데이트를 포함하여 최대 4,000개. 리포지토리의 최대 참조 수는 제한이 없습니다. | | 스페이스의 리포지토리 수 | Amazon CodeCatalyst 스페이스의 경우 최대 5,000개입니다. | | 리포지토리 설명 | 0\$11,000자의 문자 조합이면 됩니다. 리포지토리 설명은 선택 사항입니다. | | 리포지토리 이름 | 리포지토리 이름은 프로젝트에서 고유해야 합니다. 문자, 숫자, 마침표, 밑줄, 대시를 조합하여 사용할 수 있으며 길이는 1\$1100자 사이여야 합니다. 이름은 대/소문자를 구분하지 않습니다. 리포지토리 이름은 .git으로 끝날 수 없으며 다음 문자를 포함할 수 없습니다. `! ? @ # $ % ^ & * ( ) + = { } [ ] \| \ / > < ~ ` ' " ; : ` | | 리포지토리 크기 | 리포지토리 크기는 스페이스의 전체 스토리지 제한에 따라 영향을 받습니다. 자세한 내용은 [요금](https://codecatalyst.aws/explore/pricing) 및 [소스 리포지토리 문제 해결](troubleshooting-source.md) 섹션을 참조하세요. | | 풀 요청에 대한 검토자 | 풀 요청에 대해 최대 총 100명의 검토자(선택 또는 필수 사항). | | 풀 요청에 대한 서면 요약 | 풀 요청에 대한 최대 서면 요약 수는 스페이스의 청구 계층에 따라 달라집니다. 자세한 설명은 [ 요금](https://codecatalyst.aws/explore/pricing)을 참조하세요. |