Github: When Linking a pull request to an issue - New Idea

3 분 소요

문제 상황

언제부터인지 다음과 같은 키워드를 커밋 메시지에 넣어도 풀 리퀘스트 시에 자동으로 이슈가 닫히지 않는 문제가 있었다.

  • close
  • closes
  • closed
  • fix
  • fixes
  • fixed
  • resolve
  • resolves
  • resolved

원인 분석

그래서 자료를 조사해보니 다음과 같은 결과를 얻을 수 있었다.

Note: The special keywords in a pull request description are interpreted when the pull request targets the repository’s default branch. However, if the PR’s base is any other branch, then these keywords are ignored, no links are created and merging the PR has no effect on the issues. If you want to link a pull request to an issue using a keyword, the PR must be on the default branch.

직역해보면 다음과 같다.

참고: 풀 리퀘스트 구독에서의 특별한 키워드들은 풀 리퀘스트가 레포의 기본 브런치를 타겟으로 하였을 때만 해석되어진다. 그러나, 만약 풀 리퀘스트가 어떤 다른 브런치를 타겟으로 하고 있다면 이러한 키워드들은 무시되어지고, 어떠한 링크들도 생성되지 않을 것이며, 풀 리퀘스트를 병합하는 것이 그 이슈들에 대해서 어떠한 영향도 미치지 못한다. 만약 당신이 키워드를 사용하여 어떤 이슈에 대한 풀 리퀘스트를 연결시키기를 원한다면, PR은 기본 브런치를 타겟으로 해야한다.

위의 설명에서 핵심만 추려보면, 풀 리퀘스트를 통해서 병합을 목표로 하는 브런치가 기본 브런치가 아니라면, 깃헙에서 제공해주는 자동 이슈 닫기 기능이 동작하지 않는다는 의미이다.

그래서 필자는 이것에 대한 나름의 아이디어를 제시해보고자 한다.

특히, 다음의 깃 Workflow를 통해 개발을 진행하고 있다면, 조금 더 도움이 되지 않을까 생각한다.

Figure

해결 방법

위의 깃 Workflow는 대개 default가 되는 main 브런치에서 develop 브런치를 파생시킨 후, 각 이슈에 대한 feature 브런치를 develop 브런치에서 다시 한번 분기시켜 실질적인 개발을 진행하고, 다시 원래의 develop 브런치로 병합한 후, develop 브런치에서 특정 목적(개발 완료, 베타 버전 출시 등)을 위하여 특정한 때에 main 브런치로 병합시키면서 개발을 진행하는 방식이다.

그런데 위에서 기술하였듯 기본적으로 깃헙에서 레포를 생성하면, main 브런치가 default로 설정되기 때문에 위의 Workflow에서는 많은 귀찮음이 수반되어진다.

왜냐하면 실질적으로 개발은 feature 브런치에서 진행하고, 풀 리퀘스트의 타겟 즉, 대상은 develop 브런치이기 때문이다.

그러므로 필자는 풀 리퀘스트의 타겟으로 많은 빈도를 차지하는 develop 브런치를 default 브런치로 변경하여 개발을 진행해보면 어떻겠냐는 아이디어를 제시해본다.

develop 브런치를 default 브런치로 변경하는 방법은 의외로 단순하다.

Github default 브런치 변경

먼저 깃헙에 접속하여 개발을 시작하려 하거나 이미 개발을 진행하고 있는 레포로 이동한다.

(필자는 기본적으로 develop 브런치가 main 브런치로부터 파생되어져 있다고 가정했다.)

Figure

(필자는 위와 같이 test3라는 레포를 새로 생성하여 main 브런치에서 develop 브런치를 파생시켰다.)

레포로 이동하였다면 다음과 같이 Settings로 이동한다.

Figure

Settings로 이동하였다면 왼쪽 메뉴에서 Branches를 클릭한다.

Figure

화면에서 보는 바와 같이 Default branch 아래에 main이 기본적으로 표시되는 것을 확인할 수 있다.

오른쪽의 화살표 모양의 아이콘을 클릭한다.

클릭하여 나온 modal 창에서 main을 클릭하면 다음과 같이 Switch default branch라는 창이 나오게 된다.

Figure

그 후 develop 브런치를 선택하고 Update 버튼을 클릭하면 끝이다.

Figure

경고 창이 나올텐데 I understand ~ 문구가 적혀있는 버튼을 클릭하면 된다.

Figure

그러면 다음과 같이 Default branch가 develop으로 변경된 것을 확인할 수 있다.

Figure

비교 분석

먼저 다음과 같이 from develop to main이라는 이슈를 등록했다.

(이미지에서 확인할 수 있는 것과 같이 이슈 넘버는 #1이다.)

Figure

기존 main이 default로 설정되어 있을 때는 다음과 같이 develop 브런치에서 main 브런치로 풀 리퀘스트를 보내고, 병합한다면,

Figure

이슈가 자동으로 닫히는 것을 확인할 수 있다.

Figure

위에서와 마찬가지로 이번에는 다음과 같이 from feature to develop이라는 이슈를 등록했다.

(이미지에서 확인할 수 있는 것과 같이 이슈 넘버는 #3이다.)

Figure

그러나, 다음과 같이 develop에서 파생된 브런치에서 develop 브런치를 타겟으로 풀 리퀘스트를 요청하고 병합한다면,

Figure

다음과 같이 이슈가 자동으로 닫히지 않는다.

Figure

그런데 default 브런치를 develop 브런치로 설정하고 다시 풀 리퀘스트를 요청하고 병합한다면,

Figure

다음과 같이 이슈가 정상적으로 닫히는 것을 확인할 수 있다.

Figure

결론 및 기대효과

처음에는 단순히 깃헙 내의 오류라고 생각을 하였지만 조사 결과, 기본 브런치에서만 자동 이슈 닫기 기능이 동작한다는 사실을 알 수 있었다.

그러한 사실로부터 feature 브런치에서 develop 브런치로의 풀 리퀘스트의 빈도가 잦기에 develop 브런치를 기본 브런치로 설정하면 어떨까?하는 아이디어를 도출해낼 수 있었고, 이는 Git Workflow를 따르면서도 효율적으로 작업을 할 수 있어 생산성을 높이는 데에도 효과적일 것으로 생각된다.

이렇게 결론 및 기대효과를 끝으로 본 포스팅을 마무리 짓고자 한다.

댓글남기기