Outsider's Dev Story

Stay Hungry. Stay Foolish. Don't Be Satisfied.

오픈소스 컨트리뷰톤 2020 참가 후기

작년 컨트리뷰톤에 참가하고 어느새 1년이 지났다.

컨트리뷰톤 2020 공지

다시 컨트리뷰톤 2020이 열리는 걸 알았을 때는 고민을 많이 했다. 작년 경험이 좋기는 했지만, 올해는 작년과 달리 회사 업무가 바빠서 시간을 충분히 낼 수 있을지 걱정되었기 때문이다. 컨트리뷰톤을 하면 6주간은 꽤 시간을 써야 했고 작년에 해본 경험이 있어서 어느 정도 노력이 필요한지도 알았기 때문이다. 프로젝트 신청 마지막 날까지도 고민하다가 항상 내가 그렇듯이 일단 일을 벌이고 보자는 생각으로 작년과 똑같이 mocha로 신청했다.

26개 컨트리뷰톤 참가 프로젝트

작년보다 규모가 커져서 26개의 프로젝트(작년엔 20개)로 시작이 되었다.

참가자 선정

내가 생각하는 컨트리뷰톤의 목표는 작년과 달라지지 않아서 단순히 오픈소스 프로젝트에 기여를 경험하기보다는 오픈소스를 하고 싶은 생각은 많은데 어떻게 해야 할지 모르고 도움을 받을 사람이 없어서 못 하는 사람들에게 오픈소스 프로젝트가 어떻게 운영되는지 알려주어 오픈소스를 이해하고 컨트리뷰톤이 끝나도 여유가 된다면 오픈소스에 관심 가지면서 기여할 수 있도록 하는 것이었다.

이런 목표 아래 참가자를 선정했는데 올해는 프로젝트가 더 많아서인지 나도 바쁘다는 핑계로 따로 홍보하거나 하지 못해서인지 작년보다 적은 31명의 신청자가 있었고 작년에는 12명을 선정했는데 실제로 해보니 12명을 지원해주기가 혼자 쉽지 않아서 좀 더 현실적으로 올해는 10명만 선정했다.

작년의 경험이 있어도 참가자 선정은 역시 어려웠다. 경험이 많은 정윤원 님은 여러 가지 기준으로 참가자를 분류한 후에 선정하시던데 나는 그렇게까지는 못했고 참가지원서를 하나씩 읽어보면서 내가 생각하는 조건에 부합하고 끝까지 할 수 있을 것처럼 열정(간절함?)이 있어 보이는 참가자를 열심히 선정했다. 하지만 개별로 만나본 것도 아니고 간단한 자기소개, 지원동기, 프로젝트 개발 경험만으로는 분별력이 높지 않아서 선정하기가 쉽지 않았다. 이력서랑 비슷하게 지원서도 모두가 다 오픈소스를 하고 싶고 열심히 할 거라고 쓰기 때문이다.

작년 Armeria처럼 프로젝트 소개에 mocha 프로젝트를 클론 받아서 환경 설정하고 테스트를 돌려본 경험을 지원서에 써달라는 요청을 했다.

물론 이 요청은 이걸 성공적으로 잘한 사람만 뽑겠다는 것은 아니었고 그 과정에서 익숙도 혹은 문제가 생겼을 때 어떻게 대처하는지, 그리고 지원할 때의 시간을 쓸 정도로 얼마나 관심 있는지를 엿보기 위함이었다. 몇 가지 잘못 생각한 것은 프로젝트 설명에 적어놓은 이 안내를 모두가 따른 건 아니라서 이것만 조건으로 고를 수 없었다는 점이었다. 몇몇 사람은 이 부분이 큰 도움이 되었지만 몇몇은 그렇지 않았다. 그리고 이미 오픈소스 기여에 대해 주변에서 도움을 받을 수 있다고 생각되는 사람은 오히려 뽑지 않았는데 다음에는 프로젝트 설명에 이런 부분도 잘 명시해야겠다는 생각이 들었다. 아주 명확한 기준은 아니었지만, 작년에는 정말 처음 해보는 사람 위주로 뽑으려고 했다면 서로 도움을 주는 것도 꽤 도움이 되는 것 같아서 이번에는 개발 경험이 좀 있는 사람도 약간 섞었다.

컨트리뷰톤 진행

컨트리뷰톤은 8월 1일부터 9월 14일까지 6주간 진행이 되었다. 참가자는 7월 중순에 선정되었는데 회사 일이 바빠서 7월 말 발대식을 하기 전까지는 따로 참가자들과 커뮤니케이션을 하지 못했다. 지나서 생각하면 이때 시간을 더 잘 썼으면 좋았겠다 하는 생각이 들었다.

mocha 발대식 모임

발대식은 올해부터 새로 생긴 오픈소스 소프트웨어 통합지원센터의 Open UP에서 진행이 되었다. 작년에는 발대식도 모든 프로젝트가 모여서 발대식을 했는데 올해는 코로나 이슈로 프로젝트별로 따로 모여서 아무래도 조촐한 느낌이었다. 주최 측에서 예전 컨트리뷰톤에 참가하셨던 멘토들의 컨트리뷰톤 안내에 대한 영상을 2개나 만들어 주어서 행사 자체에 대한 설명이나 동기부여는 여기서 많이 해결되었고 프로젝트에 대해 설명만 했다.

작년의 경험이 있어서 온라인으로만 진행해야지 하는 생각은 하지 않았지만, 초기에 직접 이슈도 찾아보고 문제 해결도 해보는 시간이 필요하다고 생각했기 때문에 정기 미팅은 매주 화요일 저녁 10시에 온라인으로 진행했다. 이 정기 미팅은 컨트리뷰톤이 끝날 때까지 계속 진행했고 한 번에 1시간 반에서 2시간 정도를 진행한 것 같다. 일부러 고생을 시키는 것은 아니지만 직접 해보고 고민하는 시간이 필요하다고 생각하기 때문에 첫 3주는 온라인으로 진행하면서 진행했다. 회사가 바쁜 건 사실이었지만 바빠서 미뤄둔 건 아니었다.

작년처럼 오픈소스의 역사와 거대 담론을 설명하고 이해시켜야지 하는 무모한 생각은 하지 않고 첫 주부터 프로젝트 설명하고 구조와 사용되는 도구들, 어떻게 기여를 할 수 있고 분위기는 어떤지, 이슈는 어떻게 찾아야 하는지, 나랑 어떻게 작업할지 등을 설명하고 주차가 진행되면서 테스트 코드 돌리는 방법이나 로그 보는 법 등을 필요에 따라 설명했다. 처음에는 프로젝트 설명하다 보니 내가 할 말이 많아서 2시간 내내 거의 나 혼자 얘기했지만 3주 정도 지나서부터는 현재 보고 있는 이슈나 작업하는 내용을 돌아가면서 설명하고 거기에 맞춰서 이해 안 된다는 추가 설명하는 방식으로 진행을 했다. 대부분 참석하셨지만, 혹시 참석 못 하는 사람을 위해서 매번 회의는 녹화해서 파일로 공유했다.

참가하신 분들이 시작부터 적극적으로 다양한 Slack 채널도 만들고 mocha를 알아야 하니 사용해 보고 오라는 요청에 별도의 Git 저장소에서 여러 가지 테스트를 만들어 보면서 학습하셨는데 이때 초반에 좀 더 적극적으로 지원했어야 했나 하는 아쉬움도 약간 든다. 이때는 나도 아직 컨트리뷰톤에 몰입하지 못했고 회사 일이 바쁘다 보니 일일이 다 챙기지는 못했다.

스프린트 모임과 코로나 2차 웨이브

절반이 지나는 4주 차부터 오프라인 코딩 스프린트 모임을 진행하면서 속도를 높일 계획이었으나 8월 중순에 코로나 2차 웨이브가 터졌고 오프라인 모임을 할지 말지 고민하다가 오프라인과 온라인을 섞어서 내가 토즈를 예약하고 괜찮으신 분들은 나오고 나오기 어려운 분들은 온라인으로 같이 작업하도록 했다. 1시부터 6시까지 토/일을 모두 예약해 놓고 진행했는데 코로나 때문에 각각 오프라인에 2분, 4분 정도가 참여했고 온라인으로 2~3분이 참석을 하셨다. 확실히 오프라인으로 진행하니까 문제 파악도 쉽고 같이 봐 드리는 게 좋은 점이 많았다.

코로나 이슈가 점점 심각해 지고 있어서 회의에서 오프라인 모임을 어떻게 할지 논의했는데 그래도 오프라인 모임이 있는 게 좋다는 의견이 많아서 그 전주처럼 온라인/오프라인을 섞어서 매주 일요일에 모이기로 했지만 코로나가 2.5단계로 격상되면서 모일 장소가 없어졌기에 온라인 스프린트 모임으로 모두 전환해 버렸다. 체인점이 아닌 카페라면 모일 수도 있었겠지만, 정부에서 모이지 말라고 하는 상황에 모이기도 애매했다.

어떻게 할 수가 없는 상황이라서 약속한 주말 1시~7시 정도까지 작업 시작할 때 공유하고 중간에 질문받거나 작업한 거 공유하고 필요하면 화상채팅을 열어서 도와주는 방식으로 진행했는데 온라인이다 보니 집중력은 좀 떨어진 것 같다. 그래도 마지막까지 잘 따라와 주셔서 마지막 주에는 토/일 모두 스프린트 모임을 하면서 컨트리뷰톤을 마쳤고 지난 26일 최종 발표회까지 끝냈다.

컨트리뷰톤 결과

10분을 선정했지만, 마지막까지 완주하신 분은 7분이었다.

  • 참가자 모두가 1개 이상의 PR을 올리셨고
  • 전체 PR은 19개로 작년과 비슷했다.
  • mocha 외에 프로젝트에도 2개의 PR이 있었는데 단순히 mocha 기여만이 아닌 오픈소스 생태계에 이해라는 목표에 부합하기 때문에 난 이 2개가 아주 소중했다.

    • impro에 올린 PR은 mocha의 문서 문제를 수정하면서 원인을 따라다가 보니 알게 된 문제를 수정한 것이었다. 정확히는 mocha의 의존 라이브러리가 사용하는 의존 라이브러리에서 발생한 문제로 이를 통해 mocha 문제를 해결한 건 아니지만 문제를 발견했으므로 이쪽도 고쳤다.
    • nuxtjs.org에 올린 PR은 다른 작업 하시다가 사이트가 깨지는 것을 보고 그냥 지나치지 않고 PR까지 올려서 수정한 PR이다.
  • 8.1.2 릴리스가 되면서 참가자 중 4분이 Author에 이름을 등록했다.

컨트리뷰톤 최종 수상팀 발표에 mocha는 장려상

시작할 때 항상 상을 받는 게 목표가 아닌 점을 강조하지만, 작년과 마찬가지로 장려상을 받게 되었다. 주객전도가 되는 게 싫을 뿐이지 노력하고 결과도 있는 게 싫은 건 아니니까... 끝나고 참가자분들이 후기에도 좋은 경험을 많이 얘기해 주셔서 나도 기분이 좋았다.

느낀 점

7분이셨지만 역시 mocha 프로젝트에서 적당한 이슈를 계속 찾아서 작업할 수 있게 공급하는 게 제일 어렵긴 했다. 알려진 문제 중 쉬운 것은 금방 해결되기도 하고 몰랐던 이슈를 찾아보려면 시간도 많이 필요하고 난이도까지 알려면 더 많은 시간이 걸려서 더 어려웠다.(힘들게 찾아서 알려드렸는데 금세 해결하면 나는 다시 쫓기는 기분이 들어서.. ㅠ)

가장 아쉬운 건 역시 코로나로 인한 상황이었던 것 같다. 6주간 고생하고 최종발표회 때 다 같이 모여서 mocha의 발표도 보고 다른 프로젝트의 발표도 보면서 배우고 느끼는 게 많을 텐데 이번에는 상황상 심사하는 멘토들만 모이고 발표자만 온라인으로 진행했기 때문에 다른 프로젝트는 커녕 자신이 참가한 프로젝트의 발표도 못 들었기에 컨트리뷰톤이 끝나는 느낌을 깔끔하게 받지 못했을 것 같아서 아쉽다. 다 같이 "짝짝짝 고생하셨습니다."하고 끝냈어야 했는데...

결과를 보면 다들 열심히 해주셔서 결과는 나왔지만, 작년과 비교하면 오프라인으로 만나지 못해서 친밀도 면에서 큰 차이가 나게 느껴진다. 실제로 얼굴을 모두 본 것은 발대식 한 번이었고 다른 분들은 오프라인 모임 2번 모였을 때 나오신 분이다. 화상회의도 카메라를 끄고 참여하시다 보니 몇몇 분은 내가 얼굴을 제대로 외우지 못했다. 작년에는 컨트리뷰톤이 끝나고 개인적인 인간관계도 맺어졌다는 느낌이 있었다면 이번에는 그 부분에서는 부족함이 많이 느껴진다. 이럴 줄 알았으면 발대식한 날 저녁이라도 같이 먹을 걸 그랬다.(그때가 제일 많이 모인 날일 줄은 몰랐다.) 가장 큰 차이가 2019년 참가자분들은 "아싸님"이라고 나를 부르지만, 올해 참가자분들은 "멘토님"이라고 부른다.(이런 호칭 부담스러운데...) 중반이 지나면서 내가 몰입도가 막 올라와서 오프라인 모임을 열심히 진행하려던 찰나에 온라인으로 모두 전환해서 참가자분들이 몰입도를 계속 유지하기 어려웠을 것도 같고...

내 성향이기도 한데 뭔가 하겠다는 분들은 최선을 다해 도와드리지만 그렇지 않은 사람에게는 특별한 액션을 취하지 않는 게 이번에도 고스란히 드러났다. 3분이 컨트리뷰톤 과정 중 이탈했는데 이탈을 막기 위한 액션을 아무것도 하지 않았다. 기본적으로 컨트리뷰톤이 참가자들이 하는 행사이고 나는 그걸 지원해주는 사람이라는 생각을 하고 있긴 하고 내 여력으로 보아도 그 정도까지 챙기기는 어렵다는 생각은 하고 있었지만 끝나고 보니 행사의 취지를 생각했을 때 다른 일로 안 하게 했다면 모를까 뭘 해야 할지 몰라서 뒤처지고 있다면 좀 더 참여할 수 있게 북돋아 주는 행동을 해야 했지 않나 싶긴 하다. 물론 자잘하게 Git에 대한 추가 설명이나 node.js 프로젝트에 대한 설명을 초반에 좀 더 했었으면 좋았겠다 하는 생각도 든다.

나에겐 mocha 메인테이너의 몰입을 계속 유지하는 방법의 하나인데 올해도 즐거운 경험을 했다.

2020/09/29 22:29 2020/09/29 22:29

GitHub 공식 CLI gh

GitHub의 공식 CLI 1.0 버전이 릴리스되었다.

GitHub CLI는 깃헙을 CLI로 쉽게 사용할 수 있는 CLI 도구이고 이전에는 hub라는 CLI를 제공하고 있었는데 문서에 따르면 hub를 이용할까 고민하다가 장기적인 설계 관점과 git의 별칭으로 사용되는 부분을 제외하기 위해서 새로 만들었고 기존에 hub에 익숙한 사람들의 사용패턴을 바꾸고 싶지도 않았다고 한다. GitHub CLI는 gh 명령어를 사용하는데 gh를 만들었다고 hub를 없애거나 하진 않을 것이라고 한다.

나는 기존에 ghi를 비슷한 용도로 쓰고 있었는데(그래서 hub로 넘어가지 못했다.) 더는 관리되지 않고 gh가 잘 나온 것 같아서 이번 기회에 gh로 갈아탔다.

설치 및 설정

문서에 OS별 설치 방법이 나와 있고 macOS에서는 brew install gh로 간단히 설치할 수 있다.

$ gh --version
gh version 1.0.0 (2020-09-16)
https://github.com/cli/cli/releases/tag/v1.0.0

ghGo 언어로 작성되었다.

내 GitHub를 CLI에서 사용하는 도구이므로 GitHub의 권한이 필요한데 gh auth login으로 인증을 받을 수 있다.

터미널에서 gh 로그인

GitHub.com인지 엔터프라이즈인지를 선택하고 브라우저로 로그인하기를 선택하고(이미 API 키가 있으면 API를 입력하는 방법을 선택할 수도 있다.) 엔터키를 누르면 브라우저가 열린다.

열린 웹브라우저에서 로그인 코드 입력

앞에서 CLI에 보인 코드를 브라우저에서 입력하고 "Continue"를 누르면

GitHub CLI 권한 허용

사용되는 권한이 표시되는데 GitHub을 다 사용해야 하므로 대부분의 권한이 들어있다. "Authorize github"를 누르면 된다.

터미널에서 프로토콜을 선택하고 로그인을 완료

브라우저에서 권한 부여가 완료되면 자동으로 로그인 과정이 다음 과정으로 넘어간다. 사용할 git 프로토콜만 지정하면 되는데 나는 HTTPS 보다는 SSH를 선호하므로 SSH를 선택했다.

$ gh auth status
github.com
  ✓ Logged in to github.com as outsideris (~/.config/gh/hosts.yml)
  ✓ Git operations for github.com configured to use ssh protocol.

로그인 상태를 확인하려면 gh auth status를 이용하면 된다. gh auth -h로 인증 관련 명령어의 자세한 내용을 볼 수 있다.

$ gh auth -h
Manage gh's authentication state.

USAGE
  gh auth <command> [flags]

CORE COMMANDS
  login:      Authenticate with a GitHub host
  logout:     Log out of a GitHub host
  refresh:    Refresh stored authentication credentials
  status:     View authentication status

INHERITED FLAGS
  --help   Show help for command

LEARN MORE
  Use 'gh <command> <subcommand> --help' for more information about a command.
  Read the manual at https://cli.github.com/manual


저장소 관리

새로운 git 저장소를 만들려면 gh repo create [<name>]를 사용하면 된다.

$ gh repo create cli-example
? Visibility Public
? This will create 'cli-example' in your current directory. Continue?  Yes
✓ Created repository outsideris/cli-example on GitHub
? Create a local project directory for outsideris/cli-example? Yes
Initialized empty Git repository in /Users/outsider/temp/cli-example/.git/
✓ Initialized repository in './cli-example/'

공개/비공개 저장소를 선택하고 로컬에도 클론 받은 디렉터리를 만들 것인지를 선택하면 로컬뿐 아니라 GitHub에도 저장소가 만들어진다. 새로운 프로젝트를 만들 때 디렉터리를 생성하고 git init을 한 뒤에 원격 저장소에 푸시할 필요 없이 한 번에 생성할 수 있어서 편하다. --description string 플래그로 저장소 설명을 추가하거나 --enable-issues/--enable-wiki로 이슈/위키의 활성화 여부 등을 지정할 수도 있다.

GitHub의 프로젝트를 클론 받으려면 gh repo clone <repository>를 사용하면 된다. https://github.com/cli/cli의 저장소가 있다면 앞의 뒤의 경로 부분인 cli/cli만 지정해도 클론 받을 수 있다.

$ gh repo clone cli/cli
Cloning into 'cli'...
remote: Enumerating objects: 50, done.
remote: Counting objects: 100% (50/50), done.
remote: Compressing objects: 100% (33/33), done.
remote: Total 14070 (delta 25), reused 34 (delta 17), pack-reused 14020
Receiving objects: 100% (14070/14070), 32.57 MiB | 7.97 MiB/s, done.
Resolving deltas: 100% (9379/9379), done.

보통 GitHub 프로젝트를 작업하려면 github.com에서 해당 저장소를 포크한 뒤에 로컬에서 클론을 받고 원 저장소도 리모트 저장소로 추가해야 하는데 이런 작업도 gh repo fork로 간단히 할 수 있다.

$ cd cli

$ gh repo fork
- Forking cli/cli...
✓ Created fork outsideris/cli
? Would you like to add a remote for the fork? Yes
✓ Renamed origin remote to upstream
✓ Added remote origin

$ git remote -v
origin  git@github.com:outsideris/cli.git (fetch)
origin  git@github.com:outsideris/cli.git (push)
upstream  git@github.com:cli/cli.git (fetch)
upstream  git@github.com:cli/cli.git (push)

앞에서 cli/cli를 클론 받은 디렉터리에 들어가서 gh repo fork를 실행하면 github.com에 포크한 저장소도 만들어 주고 현재의 git 프로젝트에 리모트로도 추가해준다. 일반적인 관례대로 포크한 저장소는 origin으로 원 저장소는 upstream으로 변경해줘서 편하다.

gh repo view --web을 입력하면 바로 웹브라우저에서 해당 저장소를 열어서 볼 수 있다.

$ gh repo view --web
Opening github.com/cli/cli in your browser


이슈 관리

작업하다가 이슈를 다시 확인하고 싶거나 다른 이슈를 찾아보고 싶을 때도 gh issue list로 바로 확인해 볼 수 있다.

$ gh issue list

Showing 30 of 309 open issues in cli/cli

#2001  gh pr create when branch is ...  (enhancement)                    about 8 hours ago
#2000  Support different default OW...  (enhancement)                    about 4 hours ago

--assignee, --author, --label, --state로 이슈를 필터링해서 볼 수 있고 --web을 지정하면 바로 웹브라우저로 열어서 볼 수 있다.

gh issue view {<number> | <url>}로 특정 이슈를 자세히 볼 수도 있다.

$ gh issue view 2000
Support different default OWNER in `gh repo clone REPO`
Open • Moser-ss opened about 13 hours ago • 1 comment

Labels: enhancement


  ### Describe the feature or problem you’d like to solve

  The feature to have the authenticated user as default OWNER when clone the
  repo is very neat, but for some people that could not be enough. For example
  for people that work a lot inside of a specific organization could be nice
  to set a different default owner

  ### Proposed solution

  using the gh config we could set a default owner, like gh config owner acme

  Then every time we use the gh repo clone we don't need to specify the owner



View this issue on GitHub: https://github.com/cli/cli/issues/2000

gh issue create, gh issue close, gh issue reopen 등으로 이슈를 CLI에서 바로 관리할 수도 있는데 내 패턴에서는 이런 부분은 특별한 때 말고는 웹에서 하는 게 더 편한 것 같긴 하다.

gh issue status를 더 자주 쓸 것 같은데 이슈 상태 보기를 하면 나에게 할당된 이슈, 멘션 된 이슈, 내가 오픈한 이슈를 모아서 볼 수 있다.

$ gh issue status

Relevant issues in mochajs/mocha

Issues assigned to you
  There are no issues assigned to you

Issues mentioning you
  #4421  Separately run each async t...  (needs-mcve, unconfirmed-bug)   about 8 hours ago
  #4182  Xunit reporter Failure node...  (reporter)                      about 3 months ago

Issues opened by you
  #4415  Print wrong count concurren...  (confirmed-bug, parallel)       about 1 month ago
  #4047  Unhandled exception of`--fi...  (confirmed-bug, good-first-...  about 4 months ago


Pull Request 관리

Pull Request도 이슈처럼 관리할 수 있다.

$ gh pr list

Showing 23 of 23 open pull requests in cli/cli

#2005  Small readability and code organization ...  small-refactors
#2004  issue create: Add --self-assign flag         marclop:f/add-self-assign-flag-to-issue-...
#2003  Refactor gist create to reuse existing s...  cristiand391:refactor-gist-create
#1994  Don't override user provided title and b...  msfjarvis:pr-create-fill-priority

gh pr close, gh pr merge, gh pr ready, gh pr reopen 등으로 Pull Request의 상태를 관리할 수 있고 gh pr status로 나와 관련된 Pull Request의 상태도 볼 수 있다.

터미널에서 내가 관여된 PR  목록이 출력

Pull Request 생성하기

PR을 올리는 과정을 생각해 보면 브랜치를 따서 작업이 완료되면 원격 저장소에 푸시를 하고 github.com에 가서 알림으로 올라온 PR을 눌러서 제목과 내용을 작성해서 PR을 생성하게 된다. gh pr create도 편리한 기능으로 로컬에서 바로 Pull Request를 생성할 수 있다.

gh pr create로 Pull Request의 내용을 입력 후 생성

위처럼 브랜치에서 실행하면 푸시할 타겟 저정소와 제목/내용을 입력한 뒤에 바로 submit할지 더 작성할 내용이 있어서(예를 들면 이미지?) 브라우저에서 이어서 작업할 지등을 선택할 수 있다. Submit을 선택하면 바로 Pull Request까지 생성되는 것을 알 수 있다. 터미널에서 작업하다가 브라우저를 왔다갔다 할 필요없이 간단히 PR을 올릴 수 있다.

특정 Pull Request 체크아웃하기

gh에서 가장 맘에 드는 기능이다. 지금까지는 GitHub의 Pull Request를 로컬로 가져오기에서 설명했던 대로 git에 alias를 설정해서 git pr 1234처럼 사용하면서 특정 Pull Request를 로컬에서 받아오도록 사용했다.

정확히 이 기능을 해주는 명령어인데 보통 저장소의 메인테이너일 때 유용하다. 올라온 Pull Request를 리뷰할 때 로컬에서 소스 코드를 가져와서 테스트해보고 싶을 때가 있는데 이때 gh pr checkout {<number> | <url> | <branch>}로 특정 PR을 바로 가져올 수 있다.

~/projects/cli on trunk@1b029c76
$ gh pr checkout 2003
remote: Enumerating objects: 16, done.
remote: Counting objects: 100% (16/16), done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 16 (delta 11), reused 16 (delta 11), pack-reused 0
Unpacking objects: 100% (16/16), done.
From github.com:cli/cli
 * [new ref]         refs/pull/2003/head -> refactor-gist-create
Switched to branch 'refactor-gist-create'

~/projects/cli on refactor-gist-create@b71e6494

2003 PR을 가져오고 싶으면 gh pr checkout 2003처럼 사용하면 되는데 해당 Pull Request를 가져와서 브랜치 변경을 해주어서 바로 로컬에서 테스트해볼 수 있다.


기능을 둘러보니 만족스러워서 코딩하면서 자주 사용하게 될 것 같다.

2020/09/28 21:46 2020/09/28 21:46