협업을 위한 GitHub 사용법

GitHub는 Git 원격 저장소를 제공하는 웹 서비스이다. 이 글에서는 그중 협업 관점에서 GitHub를 사용해 왔던 방법을 살펴본다. 

 

Home

Repository에 처음 들어가면 기본적으로 README.md가 노출된다. 우측 패널을 보면 소개와 함께 연관된 링크를 삽입할 수 있다. 그중 Releases라는 메뉴가 있다.

릴리즈 노트는 직접 작성해도 되지만, 자동 생성을 원할 경우 PR 제목을 기반으로 만들어 준다. 기본적으로는 해당 버전의 소스코드를 제공하지만, 추가 파일을 첨부하여 각 버전 별 APK(안드로이드 설치 파일)를 제공하기도 한다. 간혹 빌드 관련 파일이 Git의 추적을 받고 있는 Repository를 볼 수 있는데, 별도로 보관하는 것이 좋다. Git의 모든 파일 기록은 삭제하더라도 .git 디렉토리에 blob 파일로 누적되기 때문에 빌드 파일은 별도로 제공하는 것이 보안 뿐만 아니라 용량 측면에서도 유리하다.

 

Issue

Issue는 위와 같이 구성된다. 이슈 내용은 각 팀에서 템플릿을 만들어 관리할 수 있으며, .github 디렉토리 내 정해진 이름으로 파일을 만들기만 하면 된다. 우측 패널을 통해 담당자(Assignees), 라벨, 마일스톤을 지정한다. 마일스톤을 지정할 경우 해당 마일스톤의 진행률을 확인할 수 있다.

한 가지 흥미로운 점은 Develoment인데, 연관된 PR을 연결할 수 있다. 이는 Issue보다 PR쪽에서 연결해 주는 편이 좋다. Projects는 GitHub에서 제공하는 Project Management 도구이며, Repository와는 다대다 관계이다. 즉, Project는 Repository가 아닌 Organization에 종속된다.

 

Pull Request

GitHub을 이용한 협업의 꽃(?)은 PR이다. Push를 하는데 왜 Push Request가 아니라 Pull Request인가 하는 논란이 있었지만, Repository 관리자 입장에서는 PR을 Pull 해야 하기 때문에 Pull Request라는 이야기가 있다. 참고로 GitLab에서는 Merge Request라는 이름으로 같은 기능을 제공한다고 한다.

마찬가지로 Issue와 비슷한 항목들을 지정할 수 있다. PR 내용에 대한 템플릿 역시 같은 방법으로 만들 수 있다. 개인적으로 PR 템플릿은 복잡하게 만들지는 않았다. 스크린샷을 적절한 크기로 첨부할 수 있도록 하기 위해 HTML의 img 태그를 포함하여 몇 가지 장치만 해 두었다.

이 화면에서 다른 기능들은 쉽게 추측이 가능하므로 Issue와 연관된 Development만 살펴보도록 하자. 여기는 연결된 Issue를 보여준다. 여기에 연결된 Issue는 PR이 Merge 되었을 때 자동으로 Closed 상태로 변경해줄 수 있다. 마우스로도 연결이 가능하지만, Issue 내용에 "- close #ISSUE_NUMBER"를 포함하면 자동으로 연결된다. 자세한 내용은 링크를 확인하자.

 

코드 리뷰 탭으로 들어오면 위 화면이 기본(Unified)적으로 보일 것이다.

개인적으로는 split이 더 보기 편하여 이 설정으로 리뷰를 진행한다.

코드 라인을 드래그하여 위와 같이 댓글을 추가할 수 있다. Add single comment를 누르면 댓글이 곧바로 추가된다.

하지만 Start a review 버튼을 누르면 바로 댓글이 달리지 않고 Pending(대기) 상태가 된다.

대기 중인 댓글은 리뷰를 마쳤을 때 일괄적으로 등록된다. 리뷰어는 코드 리뷰를 남길 때 찬성(Approve)하거나 수정을 요청(Request changes)할 수 있다. 또한 그것과는 무관하게 단순 의견을 남길 수도 있다. Repository 설정을 통해 2명 이상의 Approve를 받아야 merge가 가능하도록 설정하는 등의 옵션을 추가할 수 있다.

 

GitHub Actions를 이용하면 자동으로 테스트 결과 보고서 혹은 린터를 통한 코드 분석 결과를 댓글로 달아주도록 설정할 수도 있다. 이 내용은 각 프레임워크 별로 (yml)설정 방법이 다르다. 안드로이드의 경우 이 글을 통해 설정 과정을 남겨놨다.

 

Projects

GitHub에서 제공하는 projects 기능은 Jira나 Asana 같이 프로젝트를 관리할 수 있는 툴을 제공한다. 옵션에 따라 칸반 보드 형태로도 볼 수 있고, 스프린트 단위로 나눌 수도 있다. 기본적으로는 Issue나 PR 단위로 관리가 가능하지만, 연결된 Issue 없이도 목록을 만들 수 있다. 옵션에 따라 칸반 보드 형태로도 볼 수 있다. 이번 글에서 자세히 다루려는 내용은 아니므로 이정도만 언급하고 넘어가자.

 

결론

이 글을 통해 GitHub에서 자주 사용하는 협업 관련 기능들을 훑어봤다. 각각의 기능에 대해 설명하지 않았거나, 아직 알지 못하는 기능들도 많다. GitHub만으로도 매우 많은 기능이 제공되며, 각 기능을 자세히 설명하면 글 하나로 담아낼 수 없을 것이다. 

개인적으로는 각 Issue와 PR에 마일스톤을 달아두었지만, 마일스톤으로 분류해서 얻은 혜택보다는 유지 비용이 더 컸다고 생각한다. 따라서 이 글에서 소개한 기능도 모두 사용할 필요는 없으며, 각 팀의 규칙에 맞게 필요한 기능을 이용해야 한다.

 

여담

GitHub를 더 많이 검색되기 때문에 글 제목은 깃허브가 아닌 GitHub로 작명했다. 참고로 "GitHub 협업"이라는 키워드는 거의 검색되지 않는다고 한다.