{"meta":{"title":"스택형 풀 리퀘스트 관리","intro":"스택된 pull request를 재구성하고, 브랜치를 리베이스하고, GitHub CLI를 사용하여 하위 계층을 변경합니다.","product":"끌어오기 요청","breadcrumbs":[{"href":"/ko/pull-requests","title":"끌어오기 요청"},{"href":"/ko/pull-requests/how-tos","title":"사용법"},{"href":"/ko/pull-requests/how-tos/create-pull-requests","title":"끌어오기 요청 만들기"},{"href":"/ko/pull-requests/how-tos/create-pull-requests/managing-stacked-pull-requests","title":"스택된 PR 관리"}],"documentType":"article"},"body":"# 스택형 풀 리퀘스트 관리\n\n스택된 pull request를 재구성하고, 브랜치를 리베이스하고, GitHub CLI를 사용하여 하위 계층을 변경합니다.\n\n스택을 다듬어 가는 동안 하위 계층에서 변경하거나, 선형 기록을 유지하도록 리베이스하거나, 브랜치 구조를 재정리해야 하는 경우가 많습니다.\nGitHub CLI의 `gh stack` 확장은 영향을 받는 모든 분기를 업데이트하는 연속 작업으로 이러한 작업을 처리합니다.\n[스택형 풀 리퀘스트 CLI 명령](/ko/pull-requests/reference/stacked-prs-cli-commands)을(를) 참조하세요.\n\n## 하위 계층 변경\n\n최상위 계층에서 작업하고 스택에서 더 낮은 항목을 변경해야 하는 경우, 현재 계층에서 우회하는 대신 해당 항목이 속한 브랜치에서 변경하고 리베이스합니다.\n\n1. 변경이 필요한 분기로 이동합니다.\n\n   ```shell copy\n   gh stack down\n   ```\n\n`gh stack checkout BRANCH-NAME`로 특정 분기를 확인할 수도 있습니다.\n\n1. 변경한 후 커밋하세요.\n\n   ```shell copy\n   git add .\n   git commit -m \"helpful-commit-message\"\n   ```\n\n2. 위의 브랜치를 리베이스하여 변경 사항을 반영하도록 합니다.\n\n   ```shell copy\n   gh stack rebase --upstack\n   ```\n\n3. 업데이트된 분기를 푸시하고 작업하던 곳으로 돌아갑니다.\n\n   ```shell copy\n   gh stack push\n   gh stack top\n   ```\n\n## 스택 리베이스하기\n\n스택을 병합하려면 먼저 분기 간에 선형 기록이 있어야 합니다.\n`gh stack rebase`을 실행하면 `main`부터 시작해 각 분기가 바로 아래 분기 위로 리베이스되는 계단식 리베이스를 수행하므로, 모든 분기는 모든 하위 계층의 최신 변경 사항을 반영합니다.\n\n1. 스택을 리베이스합니다. 기본적으로 아래쪽에서 위쪽으로 모든 브랜치를 리베이스합니다.\n\n   ```shell copy\n   gh stack rebase\n   ```\n\n   재베이스를 제한하려면 가장 낮은 계층에서 현재 분기까지 재베이스할 때는 `--downstack`를 사용하고, 현재 분기에서 맨 위까지 재베이스할 때는 `--upstack`를 사용합니다.\n\n2. 업데이트된 브랜치를 푸시합니다. 이렇게 하면 `--force-with-lease`를 사용하여 리베이스된 브랜치를 안전하게 업데이트할 수 있습니다.\n\n   ```shell copy\n   gh stack push\n   ```\n\n재베이스에서 충돌이 발생하면 `gh stack rebase` 중지되고 충돌한 파일이 나열됩니다.\n\n* 영향을 받는 파일의 표식을 해결한 후 파일을 `git add`로 스테이징한 다음 `gh stack rebase --continue`를 실행합니다.\n* 다시 시작하려면 `gh stack rebase --abort`를 실행하여 모든 분기를 리베이스 이전 상태로 복원합니다.\n\n> \\[!NOTE]\n> 끌어오기 요청에서 서버 쪽 리베이스를 트리거할 수도 있지만 해당 커밋은 서명되지 않았습니다. 리포지토리에 서명된 커밋이 필요한 경우, 커밋이 사용자의 로컬 Git 커밋 서명 구성을 따르도록 GitHub CLI에서 리베이스하세요.\n\n### 웹GitHub사이트에서 리베이스\n\n스택이 선형이 아닌 경우 병합 상자에 **스택 리베이스** 단추가 나타납니다. 이 옵션을 선택하면 서버 쪽 연계 재베이스가 트리거되며, 다음이 수행됩니다:\n\n1. 전체 스택을 최신 트렁크(예: `main`) 위로 리베이스합니다.\n2. 스택의 맨 아래에서 위쪽으로 작업하여 기본 분기 위에 있는 모든 병합되지 않은 분기를 다시 지정합니다.\n3. 리베이스된 각 브랜치를 강제로 푸시하여 원격을 업데이트합니다.\n\n리베이스가 완료되면 모든 풀 리퀘스트는 업데이트된 분기를 반영하고 CI 검사는 다시 트리거됩니다.\n\n> \\[!NOTE]\n> 서버 쪽 리베이스에서 만든 커밋은 서명**되지** 않습니다. 리포지토리에 서명된 커밋이 필요한 경우, 커밋이 로컬 Git 커밋 서명 구성을 따르도록 GitHub CLI에서 `gh stack rebase`로 리베이스한 다음 `gh stack push`로 푸시합니다.\n\n## 스택 재구성\n\n스택의 구성을 변경할 수 있습니다. 예를 들어 브랜치를 삭제하거나, 브랜치를 결합하거나, 브랜치를 삽입하거나, 순서를 변경하거나, 이름을 바꿔야 하는 경우 대화형 명령 `gh stack modify`을 사용합니다.\n\n`gh stack modify`를 실행하기 전에 다음을 확인하세요:\n\n* 활성 스택이 체크 아웃된 상태입니다.\n* 작업 트리는 깨끗합니다.\n* 재베이스가 진행 중이 아닙니다.\n* 병합을 위해 대기 중인 끌어오기 요청이 없습니다.\n* 커밋 기록은 선형입니다.\n\n1. 수정 터미널 UI를 엽니다.\n\n   ```shell copy\n   gh stack modify\n   ```\n\n2. 브랜치를 선택하고 작업을 스테이징하세요. 순서 변경 및 구조적 변경 내용(삭제, 접기, 삽입, 이름 바꾸기)은 동일한 세션에서 혼합할 수 없습니다.\n\n   * `x` — 분기와 그에 속한 커밋 삭제\n   * `d` — 가지를 그 아래에 있는 가지에 접습니다.\n   * `u` — 브랜치를 위의 브랜치에 병합합니다.\n   * `i`\n     /\n     `I` — 커서 아래 또는 위에 새 분기를 삽입합니다.\n   * `r` — 분기 이름 바꾸기\n   * <kbd>Shift</kbd>+<kbd>↑</kbd> / <kbd>Shift</kbd>+<kbd>↓</kbd> — 분기 순서를 다시 지정합니다.\n   * `z` — 마지막으로 스테이징된 작업을 실행 취소합니다.\n\n3. 저장하여 스테이징된 변경 사항을 적용합니다. 저장할 때까지 아무것도 수정되지 않습니다.\n\n<kbd>Ctrl/Cmd</kbd>+<kbd>S</kbd>를 사용하세요.\n\n적용하는 동안 충돌이 발생하면 해결한 후 `gh stack modify --continue`을 실행하거나, 사전 수정 상태를 복원하려면 `gh stack modify --abort`을 실행합니다.\n\n1. 업데이트된 분기를 푸시하고 GitHub에서 스택을 다시 만듭니다.\n\n   ```shell copy\n   gh stack submit\n   ```\n\n## GitHub 웹사이트에서 스택 해제\n\n웹사이트에서 스택을 해제하여(예: 순서를 변경하거나 다시 구성하려면) 스택에서 **스택 해제** 옵션을 사용합니다.\n\n스택 해제하면 스택에서 **열림, 초안 및 닫힘** 풀 리퀘스트가 제거됩니다. 각각은 현재 기본 분기를 유지하지만 더 이상 다른 것들과 연결되지 않으며 스택 맵 및 스택 병합 요구 사항이 사라집니다.\n\n**병합된 풀 리퀘스트와 대기 중인 풀 리퀘스트는 스택에 유지됩니다.** 끌어오기 요청이 병합되거나 병합을 위해 큐에 대기되면 스택의 일부로서 스택에서 분리할 수 없습니다. 스택은 병합되었거나 병합 대기 중인 풀 리퀘스트가 하나도 없을 때만 완전히 해제됩니다. 그렇지 않으면 해당 풀 리퀘스트가 여전히 스택에 남아 있는 상태로 유지됩니다.\n\n스택을 디졸브하지 않고 순서를 다시 지정하거나 재구성하려면 대신 `gh stack modify` 명령을 사용합니다.\n[스택 재구성을 참조하세요](#restructuring-a-stack).\n\n## 병합 후 로컬 환경 동기화하기\n\n스택의 맨 아래 풀 리퀘스트가 병합되면 단일 동기화 명령으로 로컬 상태를 업데이트합니다. 병합된 끌어오기 요청에 대한 로컬 분기를 동시에 자동으로 정리하려면 이 옵션을 추가합니다 `--prune` .\n\n```shell copy\ngh stack sync --prune\n```\n\n이렇게 하면 최신 변경 내용을 가져오고, 트렁크를 fast-forward하고, 나머지 브랜치를 그 위로 리베이스하고, 업데이트된 분기를 푸시하고, 풀 리퀘스트 상태를 GitHub에서 동기화합니다.\n\n### 스택에 추가된 pull request를 가져오는 중 GitHub\n\n다른 사용자가 스택에 GitHub에서 끌어오기 요청을 추가하는 경우, `gh stack sync`는 새 분기를 가져와서 로컬 스택에 추가하여 원격을 미러링합니다. 이와 같은 원격이 앞선 깔끔한 업데이트는 자동으로 내려받아지므로 `gh stack sync` 자동화에서 실행해도 안전합니다.\n\n### 분기된 스택 해결\n\n로컬 및 원격 스택은 어느 한쪽도 다른 한쪽의 클린 확장이 아닐 때 분기됩니다. 예를 들어, 로컬에서 분기를 추가하는 동안 동일한 스택에 GitHub에서 다른 끌어오기 요청이 추가되는 경우가 그렇습니다. 이 경우 두 가지를 `gh stack sync`가 자동으로 병합할 수 없습니다. 대화형 터미널에서는 다음 세 가지 선택 항목을 제공합니다.\n\n* **원격 스택을 신뢰할 수 있는 기준 정보로 사용합니다.** 누락된 분기를 끌어와 로컬 스택 컴퍼지션을 원격의 것으로 바꿉니다. 원격 스택에 더 이상 포함되지 않는 분기에 있던 경우 가장 가까운 생존 분기로 이동됩니다. 이렇게 하려면 커밋되지 않은 변경 내용이 없는 깨끗한 작업 트리가 필요합니다.\n* **GitHub에서 스택을 삭제합니다.** 스택 개체 GitHub 를 삭제하고 동기화를 중지합니다. 끌어오기 요청 및 로컬 분기는 그대로 유지됩니다. 아직 제출하지 않은 브랜치에 대한 끌어오기 요청도 만드는 스택 `gh stack submit`을 다시 만듭니다. 구조를 변경하려면 `gh stack modify`를 먼저 실행합니다.\n* **취소.** 분기를 푸시하거나 끌어오기 요청을 업데이트하지 않고 동기화를 중단합니다.\n\nCI와 같은 비대화형 터미널에서는 분기 불일치가 발생하면 분기를 푸시하거나 끌어오기 요청을 업데이트하지 않고 동기화가 중단됩니다. 스택을 해제하고 다시 만들어 해결합니다.\n\n## 다음 단계\n\n* [스택형 풀 리퀘스트 검토](/ko/pull-requests/how-tos/review-pull-requests/reviewing-stacked-pull-requests)\n* [스택된 풀 리퀘스트 병합하기](/ko/pull-requests/how-tos/merge-and-close-pull-requests/merging-stacked-pull-requests)"}