각 프로젝트는 하나의 저장소를 가리킵니다. 해당 저장소 설정에서는 Coroid가 사용자의 브랜칭 모델과 상호작용하는 방식을 제어합니다.
프로젝트 설정에서 이 항목들을 찾아보세요.
동기화 또는 로컬 전용
저장소 모드는 Coroid가 GitHub 또는 GitLab에 쓰기 작업을 수행할 수 있는지 여부를 결정합니다.
- 동기화(기본값): Coroid는 각 작업별 브랜치를 생성한 뒤 기본 브랜치에 대한 Pull Request를 열어줍니다.
- 로컬 전용: Coroid는 저장소에서 코드를 복제하고 가져오기는 하지만 저장소에 쓰기 작업은 수행하지 않습니다. 원격 저장소에 브랜치 생성, Push, Pull Request 개설, 댓글 작성, 리뷰 진행, 상태 확인 실행, 웹훅 호출, 병합 및 파이프라인 실행이 모두 이루어지지 않습니다. 브랜치, 커밋, 리뷰, QA 및 미리보기 기능은 모두 Coroid 내부에서 처리됩니다.
동기화됨
- GitHub에서 데이터를 가져옵니다.
- 브랜치를 업데이트하고 풀 요청을 엽니다.
로컬 전용
- GitHub에서 데이터를 가져옵니다.
- 절대 데이터를 업데이트하거나 댓글을 남기거나 풀 요청을 열지 않습니다.
- Coroid 자체의 Git에서 해당 브랜치를 가져옵니다.
모드는 프로젝트 생성 시 선택하며, 프로젝트 설정에서 변경할 수 있습니다. 로컬 전용 프로젝트에는 저장소 이름 옆에로컬 전용라벨이 표시됩니다.
로컬 전용 모드는 실제 저장소에서 Coroid를 테스트하기에 가장 안전한 방법입니다. 작업 및 계획은 리뷰 단계까지 정상적으로 진행되며, pull request 대신 리뷰 화면에Coroid에 보관됨상태와 함께동기화 시작버튼이 표시됩니다. 승인을 완료하려면 동기화된 프로젝트가 필요합니다. 승인 시 기본 브랜치에 병합되기 때문입니다. 계획 내에서는 여전히 작업들이 Coroid의 계획 브랜치에서 함께 처리됩니다. Coroid에 저장된 기본 브랜치 사본은 원격 저장소의 내용과 동일하게 유지되므로, 사용자가 pull request을 열어 확인하지 않은 코드는 기본 브랜치에 반영될 수 없습니다.
로컬 머신에서 작업 내용을 확인하려면 저장소 설정의복제 및 내보내기메뉴를 열고 액세스 토큰을 생성한 뒤 Coroid 자체의 Git에서 브랜치를 가져오세요:
git remote add coroid https://coroid@git.coroid.ai/git/<project-id>.git
git fetch coroid동기화 시작버튼을 누르면 프로젝트가 동기화 모드로 전환됩니다. 이후 새로 발생하는 작업은 자동으로 Push되어 Pull Request가 생성됩니다. 이미 Coroid에 보관된 작업들은 그대로 유지되며, 리뷰 페이지에서 해당 pull request을 열어 확인할 수 있습니다 (pull request 생성을 통해 작업별로,pull request 열기을 통해 계획별로 진행할 수 있습니다). 다시 로컬 전용 모드로 전환하면 즉시 적용됩니다.
로컬 전용 모드에서는 토큰의 권한 범위와 관계없이 Coroid가 저장소에 대한 모든 쓰기 작업을 거부합니다. 이 모드는 프로젝트의 브랜치 설정에 따라 결정되며설정 이식성.
기본 브랜치
Coroid는 기본 브랜치에서 작업을 시작하여 해당 브랜치를 대상으로 풀 요청을 엽니다. 이 값은 저장소의 기본 브랜치로 기본 설정됩니다.
다른 곳에 병합하는 경우에는 이 값을 변경하세요 — 예를 들어develop브랜치, 릴리스 트레인 또는
오랫동안 유지되는 통합 브랜치 등이 있습니다. 이 설정을 잘못 지정하면 가장 흔하게 발생하는
설정 오류이며, 결과적으로 아무도 검토하지 않는 브랜치를 대상으로 하는 풀 요청이 생성됩니다.
대상 브랜치가 변경될 경우
계획에는 시작 시점의 기본 브랜치 커밋 정보가 기록됩니다. 계획의 pull request이 병합되기 전에 기본 브랜치가 변경되면, Coroid는 병합 작업을 보류합니다. 자세한 내용은기본 브랜치가 이동할 경우. 이 설정은 이후의 처리 방식을 결정합니다:
- 검토를 위해 일시 중지(기본값) — 담당자가 새로 추가된 커밋을 확인한 뒤 이를 승인하거나, Coroid에게 병합 및 재검증을 요청합니다.
- 병합 후 재검증— Coroid는 변경 사항을 계획에 지정된 레인 브랜치에 병합한 뒤, 개발자·QA·검토자 단계를 다시 실행합니다. 이 과정에서 사람의 개입을 기다리지 않습니다. 이 작업에는 에이전트 시간이 소모됩니다. 만약 병합 또는 재검증에 실패하면 최종 결정권은 사람에게 돌아갑니다.
어떤 경우든 계획이 현재 기본 브랜치와 일치하는지 확인되거나 사람이 그 차이를 승인하기 전까지는 코드가 병합되지 않습니다. 이 설정은 프로젝트의 브랜치 설정에 포함되어 있어, 프로젝트와 함께 이동합니다.설정 이식성.
작업 브랜치
각 작업은 자체적인 브랜치에서 진행됩니다. 작업별로 브랜치가 생성되며 작업이 완료되면 해당 브랜치가 푸시됩니다(로컬 전용 프로젝트의 경우 Coroid에 저장됨). 따라서 동시에 실행되는 두 작업이 같은 브랜치를 공유하지 않으며, 서로의 진행 중인 작업 내용을 확인할 수 없습니다.
어떠한 코드도 기본 브랜치에 직접 커밋되지 않습니다. 이는 설정 옵션이 아니라 Coroid의 작동 방식입니다.
작업당 하나의 브랜치. 두 작업이 동일한 브랜치를 공유하지 않습니다.
사용자가 설정한 리뷰 및 상태 확인 절차가 그대로 적용됩니다.
사용자가 병합 main
브랜치 보호
기존의 브랜치 보호 규칙은 그대로 적용됩니다. Coroid는 일반적인 풀 요청을 열기 때문에, 필수 리뷰, 필수 상태 확인 및 병합 권한 제한 등이 팀에서 사용하는 규칙과 동일하게 적용됩니다.
보호 규칙에서 서명된 커밋이나 Coroid가 생성할 수 없는 특정 상태 확인을 요구하는 경우, pull request가 풀 요청을 열지만 병합될 수 없는 상태가 됩니다. 이는 Coroid의 문제가 아닌 규칙이 정상적으로 적용된 결과입니다.
정리
pull request의 작업이 병합되거나 종료된 후에는 완료된 작업의 브랜치를 정리할 수 있습니다. 감사 추적이나 릴리스 도구에서 브랜치 이름을 활용하는 경우에는 이 기능을 활성화하기 전에 반드시 확인하세요.
연결 변경하기
기반이 되는 저장소 연결이 변경되는 경우 — 토큰이 갱신되거나 앱을 재설치하거나 저장소 이름이 바뀌는 등 — 프로젝트는 자신의 식별 정보와 이력을 그대로 유지합니다. 새로운 프로젝트를 생성하는 대신 새 연결을 가리키도록 설정하세요. 그러면 컨텍스트, 설정 및 과거 작업 내용을 모두 보존할 수 있습니다.
릴리스 파이프라인 설정
기본 브랜치는 Coroid가 풀 요청을 여는 위치를 결정합니다. 배포는 별도의 프로젝트를 사용합니다.릴리스설정에는 환경, 해당 준비 정책, 그리고 선택적으로 GitHub Actions 또는 GitLab 파이프라인 참조 및 배포 작업이 포함됩니다. 이 참조는 Coroid가 실행을 요청하기 전에 릴리스에 고정된 커밋으로 확인되어야 합니다. 파이프라인이 그 결과를 보고할 수 있도록 환경 범위의 콜백 인증 정보를 구성하세요. 단순히 저장소 연결만으로는 배포된 내용을 입증할 수 없습니다. 외부 파이프라인은 Coroid에서 디스패치를 활성화하지 않고도 이벤트를 보고할 수 있습니다.