호스팅된 리뷰, 문제 및 조치

호스팅된 코드 검토는 작업 트리의 가장 중요한 부분입니다. Orca은 작업 트리를 끌어오기 요청 또는 병합 요청에 연결하고 검토 상태를 인라인으로 표시하며 앱을 종료하지 않고도 문제를 분류할 수 있습니다.

GitHub 통합 — 작업 트리를 떠나지 않고도 PR을 열고, 확인하고, 문제를 분류할 수 있습니다.

공급자 연결

Settings → Integrations(설정 → 통합)에서 저장소가 사용하는 공급자를 연결합니다. GitHub는 Actions와 이슈를 가장 폭넓게 지원하며, GitLab 병합 요청과 이슈도 같은 작업 트리 검토 흐름을 사용합니다.

Bitbucket Cloud는 같은 창에서 앱 내 연결을 지원합니다. **Connect(연결)**를 선택한 뒤 Email & API token(이메일 및 API 토큰) 또는 **Access token(액세스 토큰)**을 사용합니다. Orca는 자격 증명을 저장하기 전에 검증하며 Source Control(소스 제어)에서 풀 리퀘스트를 만들 수 있습니다. Bitbucket Cloud는 초안 PR을 지원하지 않으므로 작성기에서 Draft(초안) 토글을 숨깁니다. ORCA_BITBUCKET_* 환경 변수는 저장된 자격 증명보다 계속 우선합니다. Azure DevOps와 Gitea 풀 리퀘스트는 GitHub, GitLab, Bitbucket과 함께 작업 트리 사이드바와 Checks(검사) 패널에 표시됩니다. 작업 트리 생성 흐름은 푸시하기 전에 원격 충돌 여부를 확인합니다.

리뷰

• 작업 트리를 푸시한 뒤 Source Control(소스 제어) 패널에서 호스팅 검토를 엽니다. 만들기 전에 기준 브랜치, 제목, 설명, 초안 상태를 확인합니다.
• 호스팅 검토를 만들거나 여는 동안 Source Control(소스 제어)의 브랜치 컨텍스트 행에 현재 브랜치가 계속 표시되므로 Create PR(PR 만들기) 작업이 브랜치 레이블을 대체하지 않습니다.
• 연결된 검토는 사이드바에 상태와 함께 표시되므로 브랜치가 아직 open(열림), merged(병합됨), closed(닫힘) 중 어떤 상태인지 알 수 있습니다.
• Orca에 연결된 PR/MR의 URL이 있으면 브랜치 컨텍스트 행에 간결한 Open review page in browser(브라우저에서 검토 페이지 열기) 링크가 표시됩니다. 한 번 클릭하면 내부 PR 보기를 열지 않고 GitHub, GitLab, Bitbucket, Azure DevOps 또는 Gitea의 검토로 이동합니다.
• 연결된 검토 또는 이슈의 오버플로 메뉴에서 **Open in Orca browser(Orca 브라우저에서 열기)**를 선택하면 터미널이나 작업 보기를 벗어나지 않고 현재 작업 트리의 브라우저 탭에서 해당 URL을 엽니다.
• GitHub 풀 리퀘스트에서는 사이드바의 PR 작업 메뉴를 사용하여 검토 링크를 복사하거나, 검토를 닫거나, 상태 변경을 확인한 뒤 다시 엽니다.
• 초안 GitHub 풀 리퀘스트와 GitLab 병합 요청에서는 사이드바 작업의 Mark ready for review(검토 준비 완료로 표시) 또는 **Close(닫기)**를 사용합니다. GitLab 작업은 Draft/WIP 상태를 제거합니다. 검토가 아직 초안이면 병합과 자동 병합을 사용할 수 없습니다.
• 연결된 GitLab 병합 요청에서는 Checks(검사) 사이드바의 검토 링크 메뉴를 열고 Unlink MR(MR 연결 해제) 또는 **Link another MR(다른 MR 연결)**을 선택합니다.
• GitHub 검사, 검토, 댓글은 PR 탭에서 인라인으로 열리며, GitLab 병합 요청과 이슈도 같은 검토 화면에서 열립니다.
• GitLab 파이프라인에서는 Checks(검사) 사이드 패널에 최상위 작업뿐 아니라 브리지 및 하위 파이프라인 작업도 포함됩니다. 작업을 펼치면 사용할 수 있는 경우 해당 작업의 추적 로그를 불러옵니다. GitHub 검사 세부 정보가 열리는 곳과 같으므로 실패한 작업이 no inline details(인라인 세부 정보 없음) 스텁에서 막히지 않습니다.
• Checks(검사) 패널에서는 루트 댓글뿐 아니라 검토 스레드의 모든 댓글에 답글을 달 수 있습니다.
• GitHub PR 대화 댓글과 인라인 검토 스레드 댓글에는 GitHub의 8가지 반응(👍 👎 😄 😕 ❤️ 🎉 🚀 👀)과 일치하는 반응 선택기가 있습니다. 기존 칩은 토글로 동작합니다. GitLab 댓글은 변경되지 않습니다.
• 그룹화된 PR 댓글 섹션은 최신순으로 정렬되므로 새 답글이 달린 스레드가 맨 위로 올라옵니다. Timeline(타임라인) 탭은 계속 오래된순으로 정렬됩니다.
• GitHub 풀 리퀘스트의 검사가 실패하면 PR 보기의 **Fix broken checks(실패한 검사 수정)**를 사용하여 실패한 검사 이름과 링크를 에이전트에 전달합니다.

자동 병합

열려 있는 GitHub PR의 경우 PR 보기의 병합 버튼이 Enable auto-merge(자동 병합 활성화)를 제공하므로 GitHub는 요구 사항(검사, 필수 검토)이 통과되면 자동으로 분기를 병합합니다. 병합 방법은 저장소의 기본값을 따르며 Squash and merge(스쿼시 후 병합), Create merge commit(병합 커밋 만들기) 또는 Rebase and merge(리베이스 후 병합) 중 하나입니다. 저장소에서 허용하지 않는 방법은 표시되지 않습니다. 보류 중인 자동 병합을 취소하려면 동일한 컨트롤에서 Disable auto-merge(자동 병합 비활성화)를 사용하세요. 기본 분기가 GitHub의 병합 대기열을 사용하는 경우 동일한 컨트롤은 Merge when ready(준비 시 병합)을 읽고 대신 PR을 대기열에 추가합니다. PR GitHub 보고서가 초안, 마감, 충돌 또는 불안정으로 보고되고 자동 병합을 허용하지 않는 저장소의 경우 자동 병합 제어가 숨겨집니다. 이 경우 수동 병합 작업만 표시됩니다.

스택형 풀 리퀘스트

선택한 기준 브랜치에 열린 PR이 이미 있는 GitHub 풀 리퀘스트를 만들면 작성기에 Stack this PR above #N(이 PR을 #N 위에 스택) 옵션이 표시됩니다. 이 옵션을 선택하면 GitHub 스택을 만들거나 상위 PR의 기존 스택을 확장하고 제출 레이블을 **Create PR in stack(스택에 PR 만들기)**으로 바꿉니다. 상황에 따라 Create draft PR in stack(스택에 초안 PR 만들기) 또는 **Push & Create PR in stack(푸시하고 스택에 PR 만들기)**으로 표시됩니다. 작은 미리 보기에는 상위 PR과 새 브랜치가 표시됩니다. 이 옵션은 GitHub 전용이며 실행 호스트가 스택 생성을 지원할 때만 표시됩니다. GitLab 병합 요청과 Bitbucket 풀 리퀘스트는 계속 개별 PR 생성 방식을 사용합니다.

GitHub가 풀 리퀘스트를 **stack(스택)**의 일부로 등록하면 PR 사이드바에 접을 수 있는 Stack #N(스택 #N) 맵이 표시됩니다. 이 맵에는 스택 내 현재 위치, 스택 크기, 스택 기준 브랜치가 표시됩니다. 펼치면 순서대로 정렬된 레이어와 상태(open(열림), draft(초안), checks pending/failed(검사 보류/실패), review needed(검토 필요), conflicts(충돌), merged(병합됨), closed(닫힘))를 볼 수 있습니다. 레이어를 클릭하면 Orca에서 해당 PR이 열립니다.

스택 인식 병합은 단일 PR 병합 레이블을 **Merge through #N · M PRs(#N까지 병합 · PR M개)**로 바꿉니다. 저장소에서 병합 대기열을 사용하는 경우에는 **Queue through #N · M PRs(#N까지 대기열에 추가 · PR M개)**로 바뀝니다. 이 작업은 현재 PR과 스택에서 그 아래에 있는 모든 PR에 적용됩니다. 스택 메타데이터가 완전하면 확인 화면에 포함되는 PR 번호가 나열됩니다. 원자적 스택 병합은 실패 시 아무것도 병합하지 않습니다. 레이어 하나라도 병합할 수 없으면 모든 레이어를 병합하지 않습니다. GitHub에 등록된 스택 메타데이터가 없는 일반 종속 PR 체인은 기존의 단일 PR 병합 흐름을 유지합니다. GitLab 병합 요청은 변경되지 않습니다.

문제

이슈 서랍을 사용하면 GitHub 및 GitLab 이슈를 Orca 내에서 찾아보고 필터링하고 편집할 수 있습니다. GitHub 이슈 또는 PR에서 작업 트리를 만들면 백그라운드에서 조용히 생성하지 않고 대화형 작업 공간 작성기가 열립니다. 따라서 이슈 명령 자동화, SSH 대상 및 폴더 작업 공간이 다른 생성 경로와 같은 방식으로 작동합니다. 작성기는 작업 이름을 미리 채우고 이슈를 연결하므로 검토가 작업에 계속 연결됩니다.

GitHub 문제의 경우 세부 정보 대화 상자에는 코멘트를 타임라인 이벤트(할당, 멘션, 상호 참조, 상태 변경 및 프로젝트 열 이동)와 인터리브하는 Activity(활동) 섹션이 있으므로 Orca를 떠나지 않고도 전체 기록을 볼 수 있습니다.

작업 공간 사이드바에 있는 링크된 이슈 메뉴를 사용하면 서랍을 열지 않고도 이슈 링크를 복사할 수 있습니다.

GitLab 리포지토리의 경우 서랍에는 선택한 프로젝트의 미해결 문제가 나열되며 사용자에게 할당된 문제로 목록 범위를 좁힐 수 있습니다.

작업

실패한 GitHub 작업 확인은 작업 트리에 빨간색 칩으로 표시됩니다. 실패한 작업 로그를 인라인으로 보려면 클릭하세요.

작업

Orca은 Tasks(작업) 사이드바 항목 아래에 전체 GitHub 프로젝트 보기를 표시합니다. 저장소 전체에서 프로젝트 카드를 찾아보고, 소스 저장소별로 필터링하고, 풀 요청 초안 상태를 확인하고, 모든 카드에서 작업 트리를 생성합니다.

문제 해결

속도 제한, gh 인증, 권한 또는 네트워크 문제로 PR 상태, 검사 또는 Tasks가 갱신되지 않으면 **GitHub 오류 문제 해결**을 참조합니다.

다음 단계

• Orca에서 커밋 및 푸시 — 변경 사항을 스테이징하고 브랜치를 푸시한 다음 호스팅 검토를 만듭니다.
• Linear 항목 서랍 — 작업 소스가 git 공급자 외부에 있을 때 Linear를 사용합니다.
• GitHub 오류 문제 해결 — 속도 제한, 인증 및 gh 실패를 다룹니다.