콘텐츠로 이동

Orca에서 커밋 및 푸시

Orca을 종료하지 않고도 검토를 커밋하고 푸시하고 열 수 있습니다. 커밋 패널은 diff 뷰어 옆에 있으며 검토, 단계, 커밋, 푸시, 이동 등 일반적인 경우에 맞게 설계되었습니다.

  1. diff에서 변경 사항을 헝크 또는 파일 단위로 스테이징합니다.
  2. 아래쪽 패널에 커밋 메시지를 작성하거나, 스테이징된 변경 사항을 바탕으로 Orca가 초안을 만들게 하려면 **Generate with AI(AI로 생성)**를 사용합니다.
  3. 소스 제어에 포커스가 있고 기본 작업이 커밋인 경우 **Commit(커밋)**을 누릅니다(macOS에서는 Cmd-Enter, Windows/Linux에서는 Ctrl-Enter).

저장소의 사전 커밋 후크는 평소와 같이 실행됩니다. 후크가 실패하면 Orca이 출력을 인라인으로 표시합니다.

커밋이 실패하면 실패 세부 정보에서 Fix with AI(AI로 수정)를 사용하여 후크 출력, 커밋 시도 메시지 및 준비된 파일 목록을 통해 활성 작업 트리에서 기본 에이전트를 시작합니다. 에이전트는 복구 메시지만 받습니다. 후크 우회, 커밋, 푸시 또는 검토 열기는 요청되지 않습니다.

Push(푸시)는 작업 트리의 분기를 origin로 푸시하여 처음으로 업스트림을 설정합니다. 분기가 뒤에 있으면 Orca는 자동으로 강제 푸시하지 않습니다.

기록(리베이스, 수정, 스쿼시)을 다시 작성했고 원격에 로컬 커밋의 이전 복사본만 있는 경우 소스 제어 패널에는 Force push with lease(임대를 통한 강제 푸시)가 명시적이고 별도의 작업으로 표시되며 일반 푸시에 대한 폴백은 절대 표시되지 않습니다. 레이블에는 대체되는 커밋 수와 업스트림 브랜치 이름이 표시되므로 무엇이 변경될지 정확히 알 수 있습니다. 강제 푸시는 --force-with-lease을 사용하므로 원격의 오래된 로컬 보기는 다른 사람의 커밋을 방해하는 대신 푸시를 중단합니다.

브랜치를 푸시한 뒤 Source Control(소스 제어) 패널의 호스팅 검토 작업을 사용하여 풀 리퀘스트 또는 병합 요청을 만듭니다. 제출하기 전에 기준 브랜치, 제목, 설명, 초안 상태를 확인합니다. Bitbucket Cloud에서는 같은 작성기에서 풀 리퀘스트를 만들 수 있습니다. 초안 PR을 지원하지 않으므로 Draft(초안)는 숨겨집니다. GitHub의 경우 선택한 기준 브랜치에 열린 PR이 이미 있으면 **Stack this PR above #N(이 PR을 #N 위에 스택)**을 사용할 수 있습니다. 스택형 풀 리퀘스트를 참조합니다.

Orca이 PR 만들기 흐름의 일부로 후속 커밋을 실행해야 하고 해당 커밋이 실패하는 경우(후크가 이를 거부하거나 작업 트리가 커밋할 수 없는 상태인 경우) 컨텍스트 없이 패널로 다시 돌아가는 대신 대화 상자에 후크 출력 및 다음 단계 버튼이 포함된 자세한 실패 요약이 표시됩니다. 요약에서 Fix with AI(AI로 수정)를 사용하여 오류를 에이전트에 전달하거나 직접 해결하고 다시 실행하세요.

Orca가 브랜치 차이와 커밋을 바탕으로 제목, 설명 및 초안 상태를 작성하게 하려면 검토 만들기 대화 상자에서 **Generate pull request details with AI(AI로 풀 리퀘스트 세부 정보 생성)**를 사용합니다. 생성된 문구는 짧고 이해하기 쉬운 problem/solution 섹션과 연결된 이슈에 대한 안내를 목표로 합니다. 이 안내는 FixesRefs 중 무엇을 사용할지 설명하며, GitHub 이슈가 연결되었는지에 따라 달라집니다. Orca는 선택한 기준 브랜치를 유지하고 빈 설명을 거부하며, 빈 본문이 게시되지 않도록 다시 시도할 수 있는 명확한 오류를 표시합니다. 검토를 만들기 전에 필드를 확인합니다.

Generate with AI(AI로 생성), Generate pull request details with AI(AI로 풀 요청 세부 정보 생성), Fix with AI(AI로 수정) 및 Resolve with AI(AI로 해결)은 모두 소스 제어 AI 작업입니다. 각 작업은 작업을 트리거할 때 실행되는 에이전트, CLI 인수 및 프롬프트 템플릿 Orca을 선택하는 action recipe(작업 레시피)로 지원됩니다. 설정 → Git 및 소스 제어Action recipes(액션 레시피)에서 전역 기본값으로 또는 현재 저장소 범위로 편집합니다.

템플릿에는 커밋 메시지용 {basePrompt}, {branch}, {stagedFiles}, {stagedPatch}, {linkedIssue} 같은 변수를 포함할 수 있습니다. PR 세부 정보에서는 {baseBranch}, {currentTitle}, {currentBody}, {commitSummary}, {changedFiles}, {patch}도 지원합니다.

{linkedIssue}은 작업 공간에 연결된 GitHub 이슈 번호로 확장되며, 연결된 이슈가 없으면 비어 있습니다(순수 Linear/GitLab 작업 공간 포함). 지시형 문구를 사용하는 것이 좋습니다. 이슈가 연결되지 않으면 단독 Fixes #{linkedIssue}Fixes #가 됩니다.

저장소에 특정 작업의 자체 레시피가 있으면 전역 기본값을 저장해도 해당 레시피는 변경되지 않습니다. 설정 창에는 어떤 저장소가 달라졌고 무엇(에이전트, CLI 인수 또는 명령 템플릿)을 재정의하는지 나열하는 Repository overrides(저장소 재정의) 메모가 표시되며, Review(검토) 링크를 사용하면 해당 저장소의 설정으로 이동하여 재정의를 업데이트하거나 제거할 수 있습니다.

수정은 명시적입니다. Commit → Amend(커밋 → 수정). Orca은 확인하지 않는 한 이미 푸시된 커밋을 수정하지 않습니다.

사이드바 Source Control(소스 제어) 패널은 현재 보기를 벗어나지 않고도 파일 준비 및 삭제, 커밋 메시지 작성, Commit(커밋), Push(푸시), Pull(풀) 또는 Sync(동기화) 실행과 같은 동일한 작업을 원클릭 작업으로 표시합니다. 경로에 ASCII가 아닌 문자가 포함된 경우에도 경로는 UTF-8로 렌더링됩니다.

상단의 브랜치 컨텍스트 행에는 현재 브랜치(또는 분리된 HEAD)가 비교 기준(branch → base) 위에 쌓여 표시되므로 Create PR(PR 만들기) 및 원격 작업을 사용할 때도 현재 브랜치를 항상 확인할 수 있습니다. 브랜치에 사용할 수 있는 병합 기준점이 있으면 간결한 칩에 해당 분기점 대비 추가·삭제된 전체 줄 수가 표시됩니다. 이는 staged/unstaged 영역의 합계가 아니라 하나의 범위 차이입니다. 호스트에서 구분 정보를 제공하면 칩에 마우스를 올려 **Code breakdown(코드 분석)**을 확인할 수 있습니다. Source(소스), Tests(테스트) 및 0이 아닐 때만 표시되는 **Generated(생성됨)**으로 나뉘며, 콘텐츠 분석이 아니라 경로 휴리스틱만 사용합니다. 긴 브랜치 이름은 칩을 가리지 않도록 잘립니다.

변경된 파일을 마우스 오른쪽 버튼으로 클릭하면 Copy Path(경로 복사) / **Copy Relative Path(상대 경로 복사)**를 사용할 수 있습니다(작업 트리 루트 기준).

아래쪽의 기본 버튼은 상태에 따라 바뀌어 다음으로 유용한 작업을 한 번의 클릭으로 실행할 수 있게 합니다. 스테이징되지 않은 변경이 있으면 Stage Files(파일 스테이징), 그다음은 Commit(커밋), 이후에는 브랜치와 업스트림의 관계에 따라 Push(푸시) / Pull(풀) / **Sync(동기화)**가 표시됩니다.

병합, 리베이스, 체리픽 또는 되돌리기 후 충돌이 남으면 소스 제어에서 Review conflicts(충돌 검토) 옆에 **Resolve with AI(AI로 해결)**가 표시됩니다. 충돌 집합을 에이전트에 맡기거나 직접 검토한 후 계속할 수 있습니다. 더 이상 진행하지 않을 병합이나 리베이스가 진행 중이면 소스 제어의 Abort merge(병합 중단) 또는 **Abort rebase(리베이스 중단)**를 사용합니다.