Task: 깃허브 gh 명령어 사용 방법

[fkdl0048]

Task: 깃허브 gh 명령어 사용 방법

• https://github.com/fkdl0048/Algorithm

알고리즘 이슈화 자동화에서 라벨, 마일스톤 할당 귀찮아서 명령어로 처리 -> 자주 사용할 것 같아서 기록

알고리즘 풀이 자동화

• 작성 이슈

알고리즘을 풀이하며 그 과정을 기록하고, 나름대로 자동화를 여러 방식으로 해봤지만 가장 좋았던 방식을 기록한다.

첫 번째 자동화

• 알고리즘 레포

일단, 나는 대부분의 문제를 풀이할 때, 해당 문제를 이슈화하여 풀이한다. LeetCode 이게 좋은 점은, 이슈화여 내가 어디까지 풀고 있는지, 이를 TODO까지 연동하여 하루에 풀 문제를 미리 계획할 수 있다는 점이 매우 좋은 점이다.

매일 TODO를 작성하기에 하루를 시작하며 미리 풀 문제를 정해놓고 친척도를 계산하여 주에 평균정도를 내볼 수 있다.

이런 느낌

따라서 문제를 이슈에 올리고 이를 PR로 만들어서 코드베이스에 병합하는 방법을 사용했다. 하지만, 역시 금방 귀찮아지기 시작했고, 매번 복잡한 과정이 생기니 그냥 이슈 본문에 풀이를 올려서 Closed하는 방식으로 바꿨다.

두 번째 자동화

이렇게 풀이하다 보니 물론 이슈로 쿼리할 수 있다는 장점은 있지만, 코드베이스 자체에 친적이 없으니 뭔가 성과가 빠지는 느낌이 들었다. 그래서 생각한 방식이 Github Action을 이용하여 Closed된 이슈를 자동으로 Main에 넣어주는 방식이었다.

이 과정은 블로그 글에 자세하게 작성했으니 참고하면 될 것 같다.

정말 편하다.

세 번째 자동화

이 과정에서도 다음의 귀찮은 문제가 생기는데, 만약 100개의 문제를 미리 이슈화한다고 가정한다면 현재 라벨을 기준으로 action이 폴더를 분류하여 저장하기 때문에 내가 문제마다 하나씩 라벨을 붙여야 한다는 단점이 생긴다. 그렇다고 문제마다 해당 라벨을 자동화하기엔 기준점이 없었기 때문에 어느정도 수작업이 있는 자동화가 필요했다.

이글을 작성한 요지이기도 한 gh라는 cli를 이용하여 이를 자동화하는 방법을 찾았다. github자체도 cli를 지원하기에 대부분의 작업을 cli로 처리할 수 있었다.

for i in {298..395}; do gh issue edit $i --add-label "Programmers" --milestone "Programmers" --repo fkdl0048/Algorithm; done

이런 느낌.. 무려 90개가 넘는 라벨을 붙여야 했지만 자동으로 처리..

느낀점은 자동화는 매우 유용하지만 그 정도나 현실적으로 어려운 문제는 항상 나온다는 점 어느정도 타협점을 찾아야 한다는 것이다. 트레이드 오프의 일종이기도 하지만, 편한건 역시 편하다..