GitHub Stacked PR 공개 프리뷰 시작

 (github.blog)
9P by GN⁺ | ★ favorite | 댓글 1개
  • 큰 변경을 작고 검토 가능한 계층으로 나누는 Stacked pull requests가 모든 저장소에 공개 미리보기로 순차 제공됨
  • 각 PR은 바로 아래 계층을 대상으로 삼아 팀원들이 좁은 범위의 diff를 병렬로 독립 검토할 수 있음
  • 최신 PR을 병합하면 아래의 미병합 계층까지 한 번에 반영되며, 일부만 병합할 경우 위쪽 PR은 자동 리베이스 및 대상 변경됨
  • 기존 PR 검토, 필수 검사, 브랜치 보호, 병합 요건이 그대로 적용되며 GitHub.com·CLI·모바일 앱·GitHub Copilot에서 스택을 다룰 수 있음
  • 공개 미리보기는 며칠에 걸쳐 전체 저장소로 확대되고, Merge queue 지원은 이후 몇 주 동안 점진적으로 제공됨

작은 변경을 쌓는 PR 구조

  • 큰 변경을 작고 집중된 여러 PR로 나누고, 각 PR을 순서가 있는 변경 계층으로 구성함
  • 첫 변경용 브랜치와 PR을 만든 뒤 그 위에 브랜치와 PR을 추가하며, 각 PR은 바로 아래 계층을 대상으로 삼음
  • 단일 대형 PR을 검토하거나 여러 브랜치를 수동으로 계속 리베이스해야 하는 불편을 줄임
  • Next.js 팀은 큰 기능을 출시하면서도 개별 변경을 작게 유지해 PR 검토가 쉬워졌다고 평가함

스택 생성과 작업 환경

  • CLI 확장 기능은 다음 명령으로 설치함
gh extension install github/gh-stack
  • GitHub.com, GitHub CLI, GitHub 모바일 앱에서 스택을 만들고 관리할 수 있음
  • GitHub Copilot 같은 코딩 에이전트에서는 gh-stack skill을 이용할 수 있음

계층별 독립 검토

  • 스택 안의 PR을 열면 전체 변경이 아닌 해당 계층의 diff만 검토할 수 있음
  • PR 상단의 스택 맵에서 현재 변경이 전체 작업 중 어디에 위치하는지 확인 가능함
  • 팀원들이 서로 다른 계층을 병렬로 검토할 수 있어 이후 작업이 검토 완료까지 막히지 않음
  • 기존 브랜치 보호 규칙과 계층별 검토를 함께 적용해 각 단계의 품질을 관리함
  • TED는 AI 도입으로 개발 생산성이 높아진 뒤 커진 PR이 검토 병목으로 이어졌으며, 변경을 의존성 순서에 따라 작은 논리 단위로 나눠 검토 속도와 정확도를 높였다고 밝힘

전체 또는 일부 스택 병합

  • 준비가 끝난 최신 PR을 병합하면 해당 PR과 그 아래의 모든 미병합 계층을 한 번에 반영함
  • 아래쪽 계층 하나 이상만 골라 스택 일부를 먼저 병합할 수도 있음
    • 위쪽 PR은 열린 상태로 유지됨
    • 병합된 변경에 맞춰 자동으로 리베이스되고 대상 브랜치도 변경됨
  • 기존 브랜치 보호, 필수 검사, 병합 요건은 계속 적용돼 main에 들어가는 변경을 통제함
  • 전체 스택뿐 아니라 한 계층 또는 일부 계층만 선택적으로 병합 가능함

공개 미리보기와 지원 일정

  • Stacked pull requests는 며칠에 걸쳐 모든 저장소에 공개 미리보기로 순차 배포됨
  • Merge queue 지원은 이후 몇 주에 걸쳐 점진적으로 배포됨
  • 자세한 사용법은 stacked pull requests 문서에서 확인할 수 있으며, stacks discussion에서 피드백을 받음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 프리뷰를 한동안 써봤는데, 해결되지 않은 문제가 많은 상태에서 대상을 확대한다는 점이 놀라움
    예를 들어 스택 전체 병합은 여러 상황에서 완전히 망가짐: https://github.com/github/gh-stack/discussions/212
    하나씩 병합할 수는 있지만 스쿼시 병합과 필수 리뷰를 함께 사용하면 스택의 PR마다 재승인을 받아야 해서, 스택형 PR의 가장 큰 이점을 잃게 됨
    gh stack이 수작업을 조금 줄여주지만 여전히 git rebase를 정확히 이해해야 함. 로컬 브랜치가 원격과 동기화되지 않았으면 UI가 안내하는 gh stack rebase도 실패하며, 도구는 그 원인을 알려주지 않음
    반면 스택 UI는 단순하면서도 PR 간 관계를 충분히 보여줘서 마음에 듦. 이미 PR을 쌓아야 할 이유가 있다는 전제에서 작업 흐름만 편하게 만들 뿐, 새로운 기능을 제공하는 도구는 아님

    • 스쿼시 병합 문제를 해결하는 버그 수정들을 순차적으로 배포 중임
      내부의 CPRMC(Create Pull Request Merge Commit)는 충돌 여부부터 승인 내용이 실제 생성될 커밋과 일치하는지까지 검사해 PR의 병합 준비 상태를 판단함
      여러 PR을 스쿼시 병합하려면 연속된 스쿼시 커밋을 계산한 뒤 규칙과 리뷰에 다시 연결해야 함. 첫 PR은 비교적 쉽지만 두 번째부터는 조상 커밋이 스쿼시되어 브랜치에 원형대로 존재하지 않으므로 복잡해지고, 부모가 여러 개인 상황은 훨씬 더 어려워짐
      현재 스택 병합의 99%가 성공하지만 이를 훨씬 높이는 것이 팀의 최우선 과제임
    • 오늘 스택형 PR이 가리키는 브랜치를 삭제하자 추가 안내 없이 계속 merging 상태에 멈추는 버그를 겪음
      PR 시스템의 부분 장애인가 싶어 GitHub 상태 페이지까지 확인했지만 스택형 PR 기능 자체의 버그였음
    • 2021년 이후 업계 전체가 완전히 준비하고 쏘고 조준하는 방식으로 바뀐 듯함
    • 회사에서도 최근 이 기능과 병합 대기열 때문에 문제가 아주 많았음

  • GitHub Stacked PRs 팀에서 이제 누구나 스택을 만들 수 있도록 더 넓게 공개함: https://gh.io/stacks
    특히 UI와 CLI에 관한 피드백을 원하며 PR 사용 경험을 개선할 업데이트도 많이 준비 중임
    Actions와 보호 규칙부터 CLI와 모바일 앱까지 거의 모든 서비스를 아우르는 GitHub 역사상 가장 큰 출시 중 하나라서, 설계 결정과 내부 동작에 관한 질문에도 답할 수 있음

    • 오늘 처음 시험해본 결과는 마음에 듦
      이미 자체 로컬 UI로 스택형 PR의 의존성을 트리로 보고 각 PR의 리뷰·CI 상태를 관리하므로, GitHub 웹 UI에도 트리와 상태 표시가 있으면 좋겠음
      웹 UI에서는 스택 맨 아래 PR만 병합하는 기능이 지원되지 않는 듯한데, 기존 작업 흐름과 코드를 공유할 수 있으니 GitHub 기본 도구에도 들어가길 바람
    • 가까운 시일 내에 포크를 넘나드는 스택형 PR을 지원할 예정인지 궁금함
      공개 저장소에서 유용하려면 중요한 기능으로 보여서 공개 프리뷰보다 먼저 제공되지 않은 점이 의외임
    • Gerrit에서 가장 그리웠던 기능이 바로 이것임
    • 작업 분할 단위로 추가 PR을 선택한 이유가 궁금함
      커밋 단위로 리뷰·적용·수정할 수 있는 제대로 된 UI 대신, 이 방식의 원조인 메일링 리스트의 패치 묶음 작업 흐름을 무시하고 사실상 ‘패치 묶음의 묶음’을 택한 데 별도의 통찰이 있었는지 알고 싶음

  • 수년간 GitHub에 적용된 변경 중 손꼽히게 큼
    세계 최대 규모의 코드 호스팅 플랫폼 중 하나에 스택형 작업 흐름이 도입되면서, 많은 개발자가 존재조차 몰랐던 방식을 접하게 될 수 있음
    스택이 더 좋은 소프트웨어를 만든다는 전제가 맞는다면 실제로 많은 개발자에게 도움이 될 가능성도 큼

  • 잘 정리된 커밋들을 커밋별로 리뷰하는 방식과 비교해 이런 스택형 PR의 이점이 무엇인지 궁금함
    더 큰 문제는 대규모 AI 생성 PR에 별도의 리뷰 방식이 필요하다는 것임. 함수 정의 변경, 호출부, 테스트 순으로 보여주는 것처럼 차이의 표시 순서만으로도 읽기 쉬운 정도가 크게 달라짐
    문해적 프로그래밍이 코드와 산문을 엮듯 차이와 설명을 결합한 문해적 차이 또는 문해적 PR이 필요할 수도 있지만 아직 비슷한 도구를 찾지 못함

    • Phabricator 등에서 스택형 차이를 쓰는 사람에게는 이것이 바로 잘 정리된 커밋을 하나씩 리뷰하는 방식임
      리뷰 단위인 PR 또는 차이가 하나의 제한된 변경으로 유지되므로 논의가 해당 변경에 집중되고, 기능이 커져도 PR 자체는 비대해지지 않음
      또 스택의 각 부분을 서로 다른 대상에게 맡길 수 있음. 외부 팀, 같은 팀 동료, 변경을 사용하는 팀처럼 리뷰어를 나누면 각자가 무엇을 승인하는지 모호하지 않음
      GitHub 리뷰가 변경 ID(change ID) 를 도입해 리베이스 후에도 댓글을 유지하면 더욱 좋겠음
    • 스택의 첫 PR에 커밋을 추가하면 전체 커밋 순서의 중간에 삽입할 수 있음
      이후 PR을 리베이스하고 수정해야 한다는 점은 거대한 단일 PR의 후속 커밋들을 고치는 것과 같지만, 변경 전체에 임시 수정 커밋을 무작위로 붙이는 대신 기반 변경의 커밋을 한데 유지하기 쉬워짐
      기반 변경에 관한 논의도 함께 모이며, 전체 스택을 미리 제시하면 리뷰어가 최종 방향을 파악하면서 작업은 비동기로 계속 진행할 수 있음
    • 핵심은 ‘잘 정리된’ 커밋을 실제로 만드는 사람이 많지 않다는 데 있음
      커밋을 게임 저장 지점처럼 사용하고 fix bug, do work 같은 메시지만 남긴 뒤 git rebase -i로 정리하지 않으므로, 필수 스쿼시 병합을 켜지 않으면 로그가 쓰레기 커밋으로 가득 참
      이런 개발자에게는 PR이 곧 커밋이며, 스택형 PR을 통해 하나의 변경을 구성하는 여러 커밋과 비슷한 구조를 비로소 사용할 수 있게 됨
    • 스택을 사용하면 리뷰 가능한 크기의 차이를 계속 만들면서 긴 변경 작업을 이어갈 수 있음
      병합된 차이는 현재 HEAD 위로 리베이스할 수 있고, 이를 지원하는 팀에서는 보통 브랜치를 직접 관리하지 않고 트렁크에서 작업하며 변경이 들어올 때마다 리베이스함
    • PR에서는 커밋을 하나씩 병합할 수 없지만 스택에서는 가능함
      기능의 앞 4개 부분이 준비됐고 5번째에 문제가 있다면 전체를 막을 필요가 없음

  • 의존성 있는 PR이 선형 이력이 아닌 트리 구조를 이루는 경우는 언제 지원되는지 궁금함
    Google에서 스택형 변경을 사용했을 때 이런 경우가 흔했고, 병렬 코딩 에이전트가 늘어난 지금은 더욱 자주 생길 듯함

    • 사람이 관리하기도 어려운 구조인데, 소프트웨어와 그에 따른 AI가 이런 방식을 장려하도록 만드는 것이 정말 바람직한지 의문임

  • 메뉴 전환 버튼이 팬케이크 더미 이모지(U+1F95E)인 이유가 스택 기능 때문인지 궁금함
    장난스러운 표현 자체는 괜찮지만 무엇을 보고 있는지 강한 의심을 유발하는 UI였음

  • 처음 소식을 들었을 때부터 gh stack CLI를 사용했고 도구 자체는 매우 좋았지만, 프리뷰 승인을 받아 접한 웹 UI는 기대에 크게 못 미쳤음
    승인 전에도 CLI는 작업을 여러 원자적 PR로 나누는 자동화를 쉽게 해줬지만, 푸시하면 서로 연결되지 않은 독립 PR로 표시됐음
    승인 후에도 거의 동일하며, 상단의 작은 탐색 드롭다운에 같은 스택의 다른 PR이 표시되는 것이 전부라서 의미 있는 UI 변화가 없음
    드롭다운에서 CLI 기능 일부를 수행할 수 있지만 웹에서 파일을 편집하는 기능처럼 부수적인 편의에 가깝고, 실제 개발 작업 흐름에서는 CLI나 IDE 플러그인이 중심이 될 것임
    이 정도의 선택적 UI 때문에 왜 오랫동안 일반 공개를 미뤘는지 의문이며, 스택 CLI는 발표 당시부터 이미 일반 공개 상태였음

    • 처음에는 최소한의 기능으로 시작해야 했지만 훨씬 광범위한 PR UI 개편을 진행 중임
      스택을 항상 인식하고 클릭을 많이 하지 않아도 각 계층을 오갈 수 있도록 스택을 지속적으로 보여주는 화면도 포함할 예정임

  • jujutsu는 브랜치를 갱신하면 그 브랜치에서 갈라진 다른 브랜치도 자동으로 리베이스해주는 점이 좋음
    리뷰하기 쉽게 작업을 나눌 때 자주 jj로 전환하며, Git으로 만든 복제본과 같은 작업 디렉터리에서 함께 사용해도 잘 동작함

    • jj absorb도 훌륭함
      변경 내용을 가장 가까운 관련 변경으로 옮겨주므로 여러 PR에 영향을 주는 수정도 쉽게 처리할 수 있음

  • Graphite를 사용한 뒤에는 스택 없는 GitHub로 돌아가기 매우 어려웠음
    GitHub의 지원으로 스택형 PR 작업 흐름이 보편화되고 거대한 PR을 대신할 쉬운 선택지가 생기길 기대함

    • git-spice를 추천함
      사용하기 쉽고 강력한 오픈소스이며, Graphite는 기능에 비해 지나치게 복잡하게 느껴졌음

  • PR 쌓기는 두 상황에서 유용하다고 이해했음
    첫째, 서로 연관된 여러 저장소에 걸쳐 있어 하나의 PR로 합칠 수 없을 때이고, 둘째, 첫 PR을 리뷰하는 동안 같은 브랜치 위에 후속 PR을 쌓아 작업을 파이프라인화할 때임
    하지만 이 기능은 둘 다 충족하지 않고, 단일 PR에 커밋을 쌓는 또 다른 형태처럼 보임
    일반적으로는 원자적이고 의미 있는 커밋을 만들고 리베이스로 리뷰어가 이해하기 좋은 흐름을 구성하며, 리뷰어도 원하면 커밋별로 살펴볼 수 있음
    이 방식에서 놓치고 있는 고유한 이점이 무엇인지 궁금함

답변달기