GitHub 이슈 통합 소개
2020년 5월 6일, Alex Ross, @alexr00 작성
Visual Studio Code 팀은 모든 작업을 추적하기 위해 GitHub 이슈를 사용합니다. 상세한 반복 계획부터 개별 버그까지 모든 것을 GitHub 이슈로 추적합니다. 이슈는 저희 팀과 다른 GitHub 프로젝트에 매우 중요하기 때문에 VS Code에 GitHub 이슈 통합을 추가하고 싶었습니다. 이 추가 기능은 1년 전에 발표했던 GitHub Pull Request 작업에 대한 보완이었습니다. VS Code 버전 1.45부터 이슈와 소스 코드를 더 가깝게 이동하는 이 새로운 지원은 GitHub Pull Requests and Issues 확장 프로그램(이전 이름: GitHub Pull Requests)에서 사용할 수 있습니다.
통합 접근 방식
이슈와 풀 리퀘스트는 종종 함께 이루어지므로, 동일한 GitHub Pull Requests and Issues 확장 프로그램에 포함하는 것은 논리적인 단계였습니다. 이슈와 풀 리퀘스트 모두에 동일한 GitHub API가 필요하기 때문입니다. 저희는 많은 소스 제어 옵션이 있기 때문에 GitHub 기능을 VS Code 코어 에디터에 직접 추가하고 싶지 않았습니다. 대신, 사용자의 열린 리포지토리가 GitHub를 사용하는 것을 감지하면 확장 프로그램을 추천할 것입니다. 저희 자체 확장 프로그램 API와 함께 작업함으로써, API가 확장 프로그램 작성자에게 필요한 기능을 갖추도록 보장하고 다른 리포지토리 제공업체도 유사한 통합을 구현할 수 있도록 합니다.
과도하게 구체적인 워크플로우를 규정하지 않는 것이 중요했습니다. 대신, 이슈를 유연한 방식으로 개발 루프 안으로 가져오는 것이 목표였습니다. 예를 들어, 코드 주석에서 이슈에 대한 더 많은 컨텍스트를 제공하는 것은 그 목표의 일부이지만, VS Code에 전체 이슈 관리를 추가하는 것은 잘 맞지 않습니다. GitHub가 이미 잘 하고 있는 UI를 재창조하고 싶지 않습니다. 저희는 이미 존재하지 않는 연결을 만들고 싶습니다.
코드 컨텍스트의 이슈
소스 코드에서 이슈로 연결하는 것은 저희 워크플로우의 일반적인 부분이며, 특히 이해하기 어려운 로직이 있거나 조치가 필요한 //TODO 주석이 있을 때 그렇습니다. VS Code 리포지토리에서 이슈 참조 검색을 수행하면 언급된 많은 이슈를 볼 수 있습니다. 링크는 더 많은 정보에 대한 포인터를 제공하지만, 실제로 더 많은 것을 배우려면 에디터를 떠나야 합니다. 이제, 호버를 통해 이러한 이슈 컨텍스트를 얻으면 더 많은 것을 배우기 위해 흐름을 끊을 필요가 없습니다.
이슈 호버는 전체 이슈 URL, 이슈 댓글 URL, 번호로 참조된 이슈(#1234), 그리고 owner/repository#1234로 참조된 이슈(예: Microsoft/vscode#1234)에서 작동합니다. 저희는 또한 코드베이스에서 사용자를 자주 참조합니다. VS Code 제안 API에는 제안에 대한 책임이 누구에게 있는지 명확하게 알 수 있도록 하는 많은 개발자 참조가 있습니다.
이슈 컨텍스트는 일반적으로 커밋이 해결하는 이슈를 참조하기 위한 커밋 메시지, 소스 코드 파일 내, 그리고 Markdown(예: 변경 로그)에서 필요합니다. 이 컨텍스트를 쉽게 추가하기 위해 이슈 및 사용자 자동 완성을 추가했습니다. Git 커밋 텍스트 상자에서 githubIssues.issueCompletionFormatScm 설정을 사용하여 이슈 자동 완성을 형식화할 수 있습니다. Markdown 파일에서는 이슈가 Markdown 링크로 자동 완성되며, 다른 파일에서는 이슈가 단순한 이슈 번호(#1234)로 자동 완성됩니다.
가능한 이슈 목록은 githubIssues.queries 설정을 사용하여 구성할 수 있습니다. 따라서 여러 리포지토리에서 작업하는 경우 해당 이슈에 대한 쿼리를 포함할 수 있습니다. 쿼리는 GitHub 검색 구문을 사용합니다. 사용자 목록에는 현재 열려 있는 리포지토리의 협력자가 포함됩니다.
어디서든 이슈 생성
VS Code에서 소스 코드를 작업하는 동안 버그를 발견하면 이슈를 생성하고 해당 영역을 담당하는 사람에게 할당합니다. 또는 버그를 발견한 사람이 소유자이기도 하다면, 나중에 다시 확인하라는 알림으로 //TODO 주석을 남기는 경우가 많습니다. 소스 코드 전체에 //TODO가 흩어져 있으면 여러 기여자가 있을 때 추적하기 어렵지만(물론 우리 모두 그랬다고 말할 수 있지만), 이슈를 만들고 //TODO에서 참조하면 추적 가능합니다. 소스 코드 깊숙이 있을 때 이슈를 만드는 데 드는 장벽과 컨텍스트 손실을 줄이기 위해 이슈를 만드는 몇 가지 새로운 방법이 있습니다.
//TODO 주석에서(githubIssues.createIssueTriggers로 구성 가능) VS Code를 벗어나지 않고 이슈를 생성하고 할당할 수 있습니다.
그리고 선택한 텍스트에서 **GitHub Issues: Create Issue from Selection** 명령을 사용하여 원본 소스 코드로 돌아가는 영구 링크가 있는 이슈를 빠르게 만들 수 있습니다. 코드에 대한 포인터만 필요한 경우 **GitHub Issues: Copy GitHub Permalink** 명령을 사용할 수도 있습니다. 마지막으로, 터미널에 실패 정보가 있으면 클립보드로 출력을 복사하고 **GitHub Issues: Create Issue from Clipboard**를 사용하여 이슈를 만들 수 있습니다.
이슈 작업
일반적인 워크플로우는 이슈를 보고, 작업할 하나를 선택하고, 작업할 브랜치를 만들고, 몇 가지 커밋을 하고, 풀 리퀘스트로 변경 사항을 메인으로 병합하는 것입니다. 새로운 **Issues** 보기에서 정확히 그렇게 할 수 있습니다.
더 많은 워크플로우를 수용하기 위해 구성할 수 있는 여러 옵션이 있습니다. 흐름에 토픽 브랜치 생성이 포함되지 않는다면 githubIssues.useBranchForIssues로 브랜치 생성을 비활성화할 수 있습니다. 브랜치에 대한 다른 명명 규칙이 있다면 githubIssues.issueBranchTitle 설정을 사용할 수 있습니다. **Issues** 보기에서 나열된 이슈는 githubIssues.queries를 사용하여 사용자 지정 쿼리를 사용하도록 구성할 수 있습니다.
더 알고 싶으신가요?
GitHub Satellite의 Sana Ajani, @sana_ajani, Burke Holland, @burkeholland의 GitHub 사용자가 VS Code에 대해 알아야 할 모든 것 발표를 시청할 수 있습니다.
VS Code의 GitHub 통합에 대해 자세히 설명하는 Working with GitHub 토픽을 읽을 수도 있습니다.
앞으로
현재 대부분의 기능은 리포지토리 복제본(포크 제외)에서만 지원되므로, 이를 지원하고 다른 사용 사례에 대한 작업이 더 필요합니다. 이 확장 프로그램에 대한 여러분의 피드백을 받고 싶습니다. 확장 프로그램 리포지토리의 이슈에 자유롭게 제안을 남겨주세요!
행복한 코딩 되세요!
Alex Ross, VS Code 개발자 @alexr00