결과물에 대한 리뷰 및 병합

Coroid는 자체 브랜치에서 기반 브랜치에 맞춰 pull request을(를) 생성하여 작업을 마무리합니다. 이 도구는 절대 자동으로 병합하지 않습니다. 병합은 반드시 사람이 결정하며, 이는 제공업체 내에서 또는승인 및 병합는 Coroid에서 수행됩니다. 자세히 알아보세요병합.

함께 제공되는 내용#

• 코드 변경 사항
• 이와 함께 작성되거나 업데이트된 테스트
• 기존 테스트 스위트를 실행한 결과
• 조직에서 설정한 모든 품질 검사의 결과
• 차이점에 대한 리뷰 과정으로, 이미 수정된 내용이나 목록으로 정리된 문제점이 포함됩니다

목적은 리뷰를 대체하는 것이 아닙니다. 다만 리뷰가 첫 번째 검토 단계가 되어서는 안 된다는 점입니다.

실제로 확인해야 할 사항#

기계적인 검증은 이미 완료되었습니다. 이제 오직 사람만이 판단할 수 있는 사항에 집중하세요:

1. 올바른 문제를 해결하고 있나요?요구사항 명세에 명시된 수용 기준과 비교해 보세요. 자신의 기억에 의존하지 말고요.
2. 코드베이스에 잘 맞나요?규칙, 명명 방식, 추상화 구조 등을 확인하세요. Coroid는 코드를 분석하여 이런 사항을 유추하지만, 항상 정확한 것은 아닙니다.
3. 예상치 못한 부분이 변경되었나요?차이점을 확인하기 전에 파일 목록을 살펴보세요.
4. 새로 추가된 테스트가 의미가 있나요?아무것도 검증하지 않는 통과 테스트는 테스트가 없는 것보다 더 나쁩니다.

작업을 다시 보내기#

비용이 증가하는 순서대로 세 가지 옵션이 있습니다:

• 코멘트를 남기고 재작업을 요청하기— 해당 작업은 개발자 에이전트에게 다시 전달되며, 당신의 의견이 함께 전달되어 기존 컨텍스트가 유지됩니다. '올바르지만 미완성'인 경우에 적합합니다.
• 계획을 거부하고 다시 실행하기— 접근 방식에 문제가 있을 때 사용하며, 실행 과정에는 문제가 없을 수 있습니다.
• 작업 취소하기— 해당 작업이 전혀 필요하지 않을 때 사용합니다. 취소하면 실행이 중단되고 에이전트 슬롯이 다시 확보됩니다.

동료와 소통할 때처럼 수정 의견을 구체적으로 작성하세요. "이 코드는 빈 값 상황을 처리하지 못합니다"parseRange"수정 완료"라는 의견은 올바른 수정을 유도하고, "보완 필요"라는 의견은 잘못된 추측을 낳습니다.

병합#

Coroid는 절대 스스로 병합하지 않습니다. 작업 완료 시 자동으로 병합하는 설정도 존재하지 않습니다. 병합은 항상 사람이 직접 결정하며, 이는 제공업체 내에서 또는 수동으로 이루어집니다.

이는 ""로 시작된 작업에도 동일하게 적용됩니다.지침Coroid는 각 병합에 대해 어떤 결정을 내릴지 기록하여 자체 판단력을 평가하지만, 해당 기록에 따라 행동하지는 않습니다. 자세히 알아보기Coroid의 결정 내용과 사용자가 직접 관리하는 사항.

GitHub 또는 GitLab에서#

제공업체 내에서 pull request를 병합하려면 일반적인 브랜치 보호 규칙, 필수 검증 절차 및 승인 요건을 적용하세요. pull request는 일반적인 브랜치이므로 이미 신뢰하는 리뷰 및 CI 프로세스를 그대로 따릅니다.

Coroid에서 "Approve & merge" 기능을 사용하여#

Coroid의 리뷰 화면에는Approve & merge버튼이 있습니다. 이 버튼을 누르면 확인을 요청한 뒤, Coroid가 GitHub 또는 GitLab를 통해 프로젝트의 저장소 연결을 이용해 pull request를 병합합니다. 이는 제공업체에서 병합 버튼을 누르는 것과 동일한 과정이므로 브랜치 보호 규칙, 필수 검증 절차 및 승인 요건이 그대로 적용됩니다. 만약 이러한 규칙으로 인해 병합이 차단되면 Coroid는 제공업체의 거부 사유를 표시하며 병합은 진행되지 않습니다.

병합 전에 발생하는 과정은 승인하는 대상에 따라 달라집니다:

• 작업작업을 병합하려면 먼저 pull request가 필요합니다. 아직 생성되지 않았다면 리뷰 화면에서Create PR를 생성한 뒤Approve & merge를 클릭하세요. 승인하면 Coroid가 작업 브랜치를 업데이트하여 최신 리뷰 결과를 반영한 뒤 pull request를 병합합니다. 작업을 승인하려면 해당 프로젝트에 대한 쓰기 권한이 필요합니다.
• 계획계획에 속한 작업들은 개별적으로 병합할 수 없습니다. 계획의 단일 pull request는 승격 리뷰를 통해 승인됩니다. Coroid는 먼저 계획 시작 시점 이후로 기본 브랜치가 변경되지 않았는지 확인합니다(자세히 알아보기 기본 브랜치가 변경된 경우), 필수 품질 검증이 통과되고 pull request에 병합 충돌이 없으며 레인 게이트도 차단하지 않을 때 pull request를 병합합니다. 계획을 승인하려면 해당 프로젝트에 대한 쓰기 권한이 필요합니다.
• 강제 병합계획의 승격 리뷰 화면에는Force merge옵션도 있습니다. 이 옵션은 Coroid의 기본 브랜치, 병합 충돌, 레인 게이트 검사를 건너뛰지만 필수 품질 검증 및 제공업체의 규칙은 그대로 적용됩니다. 병합 사유를 서면으로 작성해야 하며, 이는 승격 기록과 함께 보관됩니다. 또한 프로젝트에 대한 관리자 권한이 필요합니다.

그채팅 어시스턴트및MCP 클라이언트또한 pull request를 승인하거나 강제로 병합할 수 있습니다. 이들은 사용자를 대신하므로 동일한 검증 절차와 프로젝트 접근 권한이 적용됩니다. 채팅 어시스턴트는 항상 먼저 사용자의 확인을 요청합니다. MCP 클라이언트가 강제로 병합하는 경우 항상 다음 위치에서 대기합니다.승인사람을 위한 용도입니다. MCP 클라이언트의 승인이 여기서 대기하는지는 자동화 정책에 따라 결정됩니다. 둘 다 단일 작업을 병합할 수는 없습니다.

출시할 내용을 준비하기#

병합이 완료되면 프로젝트의릴리스탭에서 ""을 선택하세요.새 릴리스. 출시하려는 병합 커밋을 선택하면 Coroid가 해당 커밋에 포함된 풀 리퀘스트 목록을 표시합니다. 그 후 릴리스 페이지에서는 각 환경을 검증, 승인, 배포, 상태 확인의 네 단계로 진행합니다. 배포 작업은 여전히 저장소와 CI/CD에서 수행합니다. Coroid는 파이프라인에서 배포가 확인되거나 소유자 또는 관리자가 검증된 외부 배포를 기록할 때만 릴리스가 배포된 것으로 표시합니다.

다음#

릴리스— 병합된 커밋을 준비하고 각 환경에서의 진행 과정을 따르세요.다음으로 할 일다른 워크플로우 목록을 표시합니다.

관련 항목#

• 출처