스택형 풀 리퀘스트 관리

스택을 다듬어 가는 동안 하위 계층에서 변경하거나, 선형 기록을 유지하도록 리베이스하거나, 브랜치 구조를 재정리해야 하는 경우가 많습니다. GitHub CLI의 gh stack 확장은 영향을 받는 모든 분기를 업데이트하는 연속 작업으로 이러한 작업을 처리합니다. 스택형 풀 리퀘스트 CLI 명령을(를) 참조하세요.

하위 계층 변경

최상위 계층에서 작업하고 스택에서 더 낮은 항목을 변경해야 하는 경우, 현재 계층에서 우회하는 대신 해당 항목이 속한 브랜치에서 변경하고 리베이스합니다.

변경이 필요한 분기로 이동합니다.
Shell
```
gh stack down
```
```
gh stack down
```

gh stack checkout BRANCH-NAME로 특정 분기를 확인할 수도 있습니다.

변경한 후 커밋하세요.

Shell

git add .
git commit -m "helpful-commit-message"

git add .
git commit -m "helpful-commit-message"

위의 브랜치를 리베이스하여 변경 사항을 반영하도록 합니다.
Shell
```
gh stack rebase --upstack
```
```
gh stack rebase --upstack
```
업데이트된 분기를 푸시하고 작업하던 곳으로 돌아갑니다.
Shell
```
gh stack push
gh stack top
```
```
gh stack push
gh stack top
```

스택 리베이스하기

스택을 병합하려면 먼저 분기 간에 선형 기록이 있어야 합니다. gh stack rebase을 실행하면 main부터 시작해 각 분기가 바로 아래 분기 위로 리베이스되는 계단식 리베이스를 수행하므로, 모든 분기는 모든 하위 계층의 최신 변경 사항을 반영합니다.

스택을 리베이스합니다. 기본적으로 아래쪽에서 위쪽으로 모든 브랜치를 리베이스합니다.
Shell
```
gh stack rebase
```
```
gh stack rebase
```
재베이스를 제한하려면 가장 낮은 계층에서 현재 분기까지 재베이스할 때는 --downstack를 사용하고, 현재 분기에서 맨 위까지 재베이스할 때는 --upstack를 사용합니다.
업데이트된 브랜치를 푸시합니다. 이렇게 하면 --force-with-lease를 사용하여 리베이스된 브랜치를 안전하게 업데이트할 수 있습니다.
Shell
```
gh stack push
```
```
gh stack push
```

재베이스에서 충돌이 발생하면 gh stack rebase 중지되고 충돌한 파일이 나열됩니다.

영향을 받는 파일의 표식을 해결한 후 파일을 git add로 스테이징한 다음 gh stack rebase --continue를 실행합니다.
다시 시작하려면 gh stack rebase --abort를 실행하여 모든 분기를 리베이스 이전 상태로 복원합니다.

참고

끌어오기 요청에서 서버 쪽 리베이스를 트리거할 수도 있지만 해당 커밋은 서명되지 않았습니다. 리포지토리에 서명된 커밋이 필요한 경우, 커밋이 사용자의 로컬 Git 커밋 서명 구성을 따르도록 GitHub CLI에서 리베이스하세요.

웹GitHub사이트에서 리베이스

스택이 선형이 아닌 경우 병합 상자에 스택 리베이스 단추가 나타납니다. 이 옵션을 선택하면 서버 쪽 연계 재베이스가 트리거되며, 다음이 수행됩니다:

전체 스택을 최신 트렁크(예: main) 위로 리베이스합니다.
스택의 맨 아래에서 위쪽으로 작업하여 기본 분기 위에 있는 모든 병합되지 않은 분기를 다시 지정합니다.
리베이스된 각 브랜치를 강제로 푸시하여 원격을 업데이트합니다.

리베이스가 완료되면 모든 풀 리퀘스트는 업데이트된 분기를 반영하고 CI 검사는 다시 트리거됩니다.

참고

서버 쪽 리베이스에서 만든 커밋은 서명되지 않습니다. 리포지토리에 서명된 커밋이 필요한 경우, 커밋이 로컬 Git 커밋 서명 구성을 따르도록 GitHub CLI에서 gh stack rebase로 리베이스한 다음 gh stack push로 푸시합니다.

스택 재구성

스택의 구성을 변경할 수 있습니다. 예를 들어 브랜치를 삭제하거나, 브랜치를 결합하거나, 브랜치를 삽입하거나, 순서를 변경하거나, 이름을 바꿔야 하는 경우 대화형 명령 gh stack modify을 사용합니다.

gh stack modify를 실행하기 전에 다음을 확인하세요:

활성 스택이 체크 아웃된 상태입니다.
작업 트리는 깨끗합니다.
재베이스가 진행 중이 아닙니다.
병합을 위해 대기 중인 끌어오기 요청이 없습니다.
커밋 기록은 선형입니다.

수정 터미널 UI를 엽니다.
Shell
```
gh stack modify
```
```
gh stack modify
```
브랜치를 선택하고 작업을 스테이징하세요. 순서 변경 및 구조적 변경 내용(삭제, 접기, 삽입, 이름 바꾸기)은 동일한 세션에서 혼합할 수 없습니다.
- x — 분기와 그에 속한 커밋 삭제
- d — 가지를 그 아래에 있는 가지에 접습니다.
- u — 브랜치를 위의 브랜치에 병합합니다.
- i / I — 커서 아래 또는 위에 새 분기를 삽입합니다.
- r — 분기 이름 바꾸기
- Shift+↑ / Shift+↓ — 분기 순서를 다시 지정합니다.
- z — 마지막으로 스테이징된 작업을 실행 취소합니다.
저장하여 스테이징된 변경 사항을 적용합니다. 저장할 때까지 아무것도 수정되지 않습니다.

Ctrl/Cmd+S를 사용하세요.

적용하는 동안 충돌이 발생하면 해결한 후 gh stack modify --continue을 실행하거나, 사전 수정 상태를 복원하려면 gh stack modify --abort을 실행합니다.

업데이트된 분기를 푸시하고 GitHub에서 스택을 다시 만듭니다.
Shell
```
gh stack submit
```
```
gh stack submit
```

GitHub 웹사이트에서 스택 해제

웹사이트에서 스택을 해제하여(예: 순서를 변경하거나 다시 구성하려면) 스택에서 스택 해제 옵션을 사용합니다.

스택 해제하면 스택에서 열림, 초안 및 닫힘 풀 리퀘스트가 제거됩니다. 각각은 현재 기본 분기를 유지하지만 더 이상 다른 것들과 연결되지 않으며 스택 맵 및 스택 병합 요구 사항이 사라집니다.

병합된 풀 리퀘스트와 대기 중인 풀 리퀘스트는 스택에 유지됩니다. 끌어오기 요청이 병합되거나 병합을 위해 큐에 대기되면 스택의 일부로서 스택에서 분리할 수 없습니다. 스택은 병합되었거나 병합 대기 중인 풀 리퀘스트가 하나도 없을 때만 완전히 해제됩니다. 그렇지 않으면 해당 풀 리퀘스트가 여전히 스택에 남아 있는 상태로 유지됩니다.

스택을 디졸브하지 않고 순서를 다시 지정하거나 재구성하려면 대신 gh stack modify 명령을 사용합니다. 스택 재구성을 참조하세요.

병합 후 로컬 환경 동기화하기

스택의 맨 아래 풀 리퀘스트가 병합되면 단일 동기화 명령으로 로컬 상태를 업데이트합니다. 병합된 끌어오기 요청에 대한 로컬 분기를 동시에 자동으로 정리하려면 이 옵션을 추가합니다 --prune .

Shell

gh stack sync --prune

gh stack sync --prune

이렇게 하면 최신 변경 내용을 가져오고, 트렁크를 fast-forward하고, 나머지 브랜치를 그 위로 리베이스하고, 업데이트된 분기를 푸시하고, 풀 리퀘스트 상태를 GitHub에서 동기화합니다.

스택에 추가된 pull request를 가져오는 중 GitHub

다른 사용자가 스택에 GitHub에서 끌어오기 요청을 추가하는 경우, gh stack sync는 새 분기를 가져와서 로컬 스택에 추가하여 원격을 미러링합니다. 이와 같은 원격이 앞선 깔끔한 업데이트는 자동으로 내려받아지므로 gh stack sync 자동화에서 실행해도 안전합니다.

분기된 스택 해결

로컬 및 원격 스택은 어느 한쪽도 다른 한쪽의 클린 확장이 아닐 때 분기됩니다. 예를 들어, 로컬에서 분기를 추가하는 동안 동일한 스택에 GitHub에서 다른 끌어오기 요청이 추가되는 경우가 그렇습니다. 이 경우 두 가지를 gh stack sync가 자동으로 병합할 수 없습니다. 대화형 터미널에서는 다음 세 가지 선택 항목을 제공합니다.

원격 스택을 신뢰할 수 있는 기준 정보로 사용합니다. 누락된 분기를 끌어와 로컬 스택 컴퍼지션을 원격의 것으로 바꿉니다. 원격 스택에 더 이상 포함되지 않는 분기에 있던 경우 가장 가까운 생존 분기로 이동됩니다. 이렇게 하려면 커밋되지 않은 변경 내용이 없는 깨끗한 작업 트리가 필요합니다.
GitHub에서 스택을 삭제합니다. 스택 개체 GitHub 를 삭제하고 동기화를 중지합니다. 끌어오기 요청 및 로컬 분기는 그대로 유지됩니다. 아직 제출하지 않은 브랜치에 대한 끌어오기 요청도 만드는 스택 gh stack submit을 다시 만듭니다. 구조를 변경하려면 gh stack modify를 먼저 실행합니다.
취소. 분기를 푸시하거나 끌어오기 요청을 업데이트하지 않고 동기화를 중단합니다.

CI와 같은 비대화형 터미널에서는 분기 불일치가 발생하면 분기를 푸시하거나 끌어오기 요청을 업데이트하지 않고 동기화가 중단됩니다. 스택을 해제하고 다시 만들어 해결합니다.

이 기사에서