Github CLI란
microsoft가 github를 인수한 후 Actions, UI개선 등 개발자의 의견을 반영해 여러가지 업데이트를 진행했다. 올해 초에 github cli가 베타를 한다는 뉴스를 보고나서 "또 뭐 만드는구나~" 싶었는데 오늘 리포지토리를 clone하려고 보니 띠용? github cli의 clone 명령어를 지원해주더라.
그래서 한번 사용해보기로 했다. 그래도 키보드 두드리는 걸 업으로 삼고있는데 새로운 기술이 나오면 다루어봐야지 싶었다. 그게 자주 사용하는 github이면 더욱이..
Github CLI 설치 및 로그인
설치
먼저 설치를 하자. 이하의 링크에 접속하자.
github.com/cli/cli/releases/tag/v1.1.0
그 뒤 msi 파일을 받아주면 된다.
windows의 패키지 관리 프로그램인 scoop이나 choco로도 다운로드가 가능했지만 windows 패키지 관리 프로그램이 아직 마이너한 수준이라.. 나중에 choco로 설치했다는 사실을 잊어버리면 삭제할 떄 번거로울 것 같아 msi로 설치했다.
다운로드가 완료되면 디폴트로 설치를 해주면 된다.
그리고 gh 커맨드를 쳐서 위와 같은 도움말이 나오면 설치 완료.
로그인
당연하다지만 github는 회원 서비스이기 때문에 cli를 활용하기 위해서는 로그인을 해야한다.
찾아보니 몇가지 방법이 있었지만, 나는 gh auth login 명령어 이후로 브라우저 경유 로그인했다.
터미널에서 명령어 입력 후 github.com -> login with a web browser를 선택하면 코드를 알려주면서 (파란색 부분) 브라우저를 실행해준다.
그 코드를 복사 한 후 아래의 브라우저에 입력해준다.
그러면 성공
무사히 완료됨을 확인할 수 있다.
Github CLI의 기능
github cli는 인증 및 로그인 등 기본기능을 제외하면 크게 이하의 4개의 기능을 제공한다.
-
gist 기능 이용
-
issue 관리
-
pull request 관리
-
release 관리
- repository 관리
위에서 부터 천천히 살펴보겠다.
ℹ️ 모든 명령어에 R, --repo 옵션으로 다른 리포지토리를 대상으로 실행할 수 있다. |
gist 기능 이용
명령어 |
예 |
옵션 |
create |
gh gist create { filename } gh gist create { filename1 } { filename2 } { filename3 } cat test.py | gh gist create |
-d, --desc {{ str }} : gist 설명 -f, --filename {{ str }} : 파일이름 -p, --public : 공개설정 |
edit |
gh gist edit { gistID } 또는 { gist URL } |
-f, --filename {{ str }} : 파일이름 |
list |
gh gist list |
-L, --limit {{ int }} : 가져올 gist 최대수(int) |
view |
gh gist view { gistID } 또는 { gist URL } |
-f, --filename {{ str }} : 파일이름 |
ℹ️ github gist를 모르시는 분들을 위해 간략하게 설명하자면 블로그 등에 코드를 붙여넣을 때 코드에 css, html 형식을 붙여 보기 쉽게 스타일링을 해주는 github의 도구이다. url은 이쪽으로 gist.github.com |
여기서 다루는 gistID는 gist 페이지의 url에서 / 패스 이하의 문자열을 뜻한다. 즉
gist.github.com/cadimi/abcdefjdkfje 의 경우 abcdefjdkfje가 gistID이다.
Github CLI를 이용해 간단하게 gist를 만들어보자면
먼저 hellp.py라는 임시 파일을 만들어줬다 (hello.py의 오타..ㅠ)
gh gist create hellp.py 명령어를 입력하면 gist 작성 후 url 을 알려준다.
그 url을 클릭하면 gist 페이지로 이동
작성한 gist를 확인할 수 있다.
이외에도 Github CLI의 gist에서는 아래의 커맨드를 제공한다.
신기했던 건 edit으로 수정할 수 있다는 점이었다.
gh gist edit gistID 명령어를 입력하면 아래처럼 메모장이 나온다.
그리고 # Hello! 주석을 붙이고 저장하면?
실제 웹에서도 변경이 저장된 것을 확인할 수 있었다.
issue 관리
명령어 | 예 | 옵션 |
create | gh issue create | -a, --assignee {{ login }} : 할당하기 -b, --body {{ str }} : 내용 -l, --label {{ name }} : 라벨 -m, --milestone {{ name }} : 마일스톤에 추가 -p, --project {{ name }} : 프로젝트에 추가 -t, --title {{ str }} : 타이틀 추가 -w, --web : 브라우저 열기 |
status | gh issue status gh issue status --repo {{ OWNER/REPO }} |
|
list | gh issue list | -a, --assignee : assignee로 필터링 -A, --author : author로 필터링 -l, --label : label로 필터링 -L, --limit : 가져올 이슈 수 -m, --milestone : 마일스톤 번호 or 타이틀로 필터링 - s, --state : state로 필터링(open 등) -w, --web : 브라우저 열기 |
view | gh issue view {{ number }} 또는 {{ url }} | -w, --web : 브라우저 열기 |
close | gh issue close {{ number }} 또는 {{ url }} | |
reopen | gh issue reopen {{ number }} 또는 {{ url }} |
시험삼아 이슈를 하나 만들어봤다.
이렇게 설정하니 브라우저를 열어주는데
만들어 주는 것이 아닌, 내용을 채우둔 상태로 클릭버튼을 눌러야 한다. 간편하게 사용할 거면 --web 옵션은 빼고 사용하는 것이 좋을듯 하다.
빼고 사용하니, 추가적으로 cli 입력할 수 있는 옵션이 나타난다. 여기서 라벨을 추가할 수도 있다. 여기서 이슈의 body는 gist 때 처럼 body 입력을 선택하면 메모장이 나타난다! 그리고 작성 후 저장, 메모장을 닫으면 cli가 메모장이 닫힌 것을 확인하고 다음 프로세스로 진행해준다. 어떻게 동작하는지 기똥차다.
pull request 관리
명령어 | 예 | 옵션 |
checkout | gh pr checkout {{ number }} 또는 {{ url }} 또는 {{ branch }} | --recurse-submodules : 모든 active submodules 업데이트 |
checks | gh pr checks {{ number }} 또는 {{ url }} 또는 {{ branch }} | |
close | gh pr close {{ number }} 또는 {{ url }} 또는 {{ branch }} | -d, --delete-branch : close 이후 로컬/리모트 브런치 삭제 |
create | gh pr create | -a, --assignee {{ login }} : 할당하기 -B, --base {{ branch }} : merge 대상 브랜치 지정 -b, --body {{ str }} : 내용 작성 -d, --draft : 임시작성(draft)으로 마크 -f, --fill : commit의 정보용으로 작성 -H, --head {{ branch }} : pull request를 포함할 브랜치 지정 -l, --label {{ name }} : 라벨 추가 -m, --milestone {{ name }] : 마일스톤에 추가 -p, --project {{ name }} : 프로젝트에 추가 -r, --reviewer {{ login }} : 리뷰어 지정 -t, --title {{ str }} : 타이틀 작성 -w, --web : 브라우저 열기 |
diff | gh pr diff {{ number }} 또는 {{ url }} 또는 {{ branch }} | --color {{ color }} : diff 색 지정 always, never, auto 중 하나 |
list | gh pr list | -a, --assignee {{ str }} : assignee로 필터링 -B, --base {{ str }} : 베이스브런치로 필터링 -l, --label {{ strs }} : 라벨로 필터링 -L, --limit {{ int }} : 가져올 pull request 수 지정 -s, --state {{ str }} : state로 필터링 -w, --web : 브라우저 열기 |
merge | gh pr merge {{ number }} 또는 {{ url }} 또는 {{ branch }} | -d, --delete-branch : merge 후 브랜치 삭제 -m, --merge : 커밋을 베이스브랜치에 merge -r, --rebase : 커밋을 베이스브랜치에 rebase -s, --squash : 커밋을 한개로 통합한 후 merge |
ready | gh pr ready {{ number }} 또는 {{ url }} 또는 {{ branch }} | |
reopen | gh pr reopen {{ number }} 또는 {{ url }} 또는 {{ branch }} | |
review | gh pr reopen {{ number }} 또는 {{ url }} 또는 {{ branch }} | -a, --approve : pull request 승인 -b, --body {{ str }} : 리뷰 작성 -c, --comment : 커맨트 작성 -r, --request-changes : Request changes 요구 |
status | gh pr status | |
view | gh pr view {{ number }} 또는 {{ url }} 또는 {{ branch }} | -w, --web : 브라우저 열기 |
테스트를 위해 파일 수정 후 pull request를 생성하고, diff 로 확인하고, merge 해보기로 했다.
그리고 주석추가 후 commit, push를 했다.
url을 누르면 화면이동
정상적으로 생성됨을 확인할 수 있었다.
# test 주석이 추가됨을 확인할 수 있었다.
다음은 merge. -d 옵션을 넣었더니 브랜치가 삭제되고 자동으로 master브랜치로 변경됐다!
이는 리모트도 마찬가지이다. 리모트 test_branch도 삭제된다.
브라우저에서 확인해보니 merged된 모습
release 관리
명령어 | 예 | 옵션 |
create | gh release create {{ tag }} | -d, --draft : 임시로 릴리즈 저장 -n, --notes {{ str }} : notes 작성 -F, --notes-file {{ file }} : 파일에서 릴리즈 읽기 -p, --prerelease : release를 prerelease로 마크 --target {{ branch }} : 타겟 브랜치 지정 -t, --title {{ str }} : 타이틀 지정 |
delete | gh release delete {{ tag }} | -y, --yes : 확인 작업 패스 |
download | gh release download {{ tag }} | -D, --dir {{ str }} : 파일 다운로드 할 디렉토리 -p, --pattern {{ str array }} : 패턴에 맞는 assets 다운로드 |
list | gh release list | -L, --limit int : 가져올 리스트 수 |
upload | gh release upload {{ tag }} | --clobber : 현재 존재하는 같은 이름 파일 덮어쓰기 |
view | gh release view {{ tag }} | -w, --web : 브라우저 열기 |
파일 하나를 release하고, download, delete 순으로 테스트해보겠다.
그 다음 다운로드를 해보기
브라우저에서 확인
그 다음 Assets을 다운로드
띠용?
다운로드할 Assets이 없단다.. 버젓이 source code.zip 이 있구만..!
구글링 해보니 이런 답변이 나왔다.
즉 default의 source 코드는 의도적으로 올린 assets이 아니기 때문에 다운로드가 안된다. 하지만 web UI에서는 source 코드가 assets으로 사용되고 있기에, 다음 릴리즈에 source 코드도 다운로드 되게끔 기능을 추가한다고 하니 기다리면 될 듯 하다.
삭제는 무사히 잘 되었다. 써있듯이 태그는 남으니 필요시에 수동으로 지워야할듯 하다.
repo 관리
명령어 | 예 | 옵션 |
clone | gh repo clone {{ repo }} | |
create | gh repo create {{ name }} | -y, --confirm : 확인 과정 패스 -d, --description {{ string }} : 설명 --enable-issues : issue 활성화 --enable-wiki : wiki 활성화 -h, --homepage {{ string }} : 리포지토리 홈 페이지 url --internal : 리포지토리 internal로 만들기 --private : 리포지토리 private로 만들기 --public 리포지토리 public로 만들기 -t, --team {{ string }} : 팀 이름 설정 -p, --template {{ string }} : 임시 리포지토리을 기준으로 생성 |
fork | gh repo fork {{ repo }} | --clone {{ true }} or {{ false }} : fork 후 clone --remote {{ true }} or {{ false }} : fork를 remote에 등록 |
view | gh repo view {{ repo }} | -b, --branch {{ str }} : 브랜치 지정 -w, --web : 브라우저 열기 |
repo는 무슨 기능인지 훤히 보여서 딱히 테스트해보지는 않았다. 다만 view만 테스트 해봤는데, view의 경우 리포지토리를 지정하면 readme.md를 보여준다.
마치면서
마이크로소프트가 개발자 편의를 생각하는 행보를 꾸준히 보여주고 있다. 하지만 Github CLI는 써본결과 아직은 잘 활용성이 크게 안다가온다.. 서버 내에서 cli로 리포지토리를 조작하고 싶을 때는 사용할 수 있겠지만 그 외의 상황에서 나는 활용하는 일은 많이 없을 것 같다. github 웹 리포지토리의 UI가 너무 활용성이 높고, 잘 만들어져있어서 굳이 cli로..? 라는 생각이 들기도 한다. 어떻게 되든 개발자 편의를 생각해주는 행보는 반갑다. 계속 이 모습을 보여주었으면 한다.
소스
'그 외 개발관련' 카테고리의 다른 글
powershell 터미널 프로필 현재 디렉토리만 보이게 설정 (0) | 2020.09.26 |
---|---|
X-Frame-Options이란? (에러 it set 'X-Frame-Options' to 'sameorigin') (0) | 2020.09.22 |
크로미움 엣지 알트탭(alt + tab) 시 탭 분할 비활성화 방법 (57) | 2020.08.30 |