[미라클 TIL 6일차] Github으로 협업하는 방법
TIL 24. 01. 09
Github으로 협업하기
내일배움캠프 React 최종 프로젝트를 시작하면서 버전 관리와 일정 관리, 이슈 트래킹, 회의 기록 등 프로젝트 전반에 대한 관리가 필요했다. 이를 위해 노션을 많이 활용하지만 Github에서 제공하는 풍부한 기능들을 사용하여 하나의 플랫폼에서 관리하고 싶었다. 보다 체계적인 협업 환경을 구축하고 개발 생산성을 높이기 위해 github을 활용한 방법을 정리해보았다.
각 기능들을 활용하는 방법과 깃 브랜치 전략에 대해서는 자세히 다루지 않는다. 대신 참고 자료를 첨부하였다.
1. Organization 생성 및 팀원 초대
Organization은 쉽게 말해 단체 계정이다. 개인 계정을 사용해 저장소를 만들면 해당 저장소는 소유자 한 명에게 의존하게 된다. 즉 계정의 소유자만이 관리 권한을 갖는다.
Organization을 사용하면 팀 멤버의 역할과 권한을 관리할 수 있다. 이는 팀원들이 저장소에 대해 공동 접근 권한을 가지며, 팀의 목표에 따라 작업을 조직화 할 수 있게 한다. 팀원들의 권한을 설정해 접근 가능한 저장소와 특정 작업에 대한 권한을 제한할 수도 있다.
이러한 이유로 Organizaion을 활용해 팀 프로젝트를 진행하였다. 다음 글을 참고하여 Organization을 생성하고 팀원들을 초대한다.
2. 협업 시나리오
협업은 다음과 같은 시나리오로 진행한다.
1. Issue 생성
2. 각자 로컬에서 작업
3. Pull Request
4. 코드 리뷰
5. 병합
▶ 구체적인 개발 프로세스
-
Issue 생성
- Issue 템플릿 사용
- Assignees, Labels, Projects 지정
-
Issue 제목에 명시한 브랜치명으로 develop에서 분기하여 브랜치 생성
git checkout -b feat/review- 로컬의 develop 브랜치는 항상 최신화
git pull origin dev
- 로컬의 develop 브랜치는 항상 최신화
-
작업 브랜치에서 소스코드 수정
-
작업 브랜치에서 변경사항을 커밋
- 커밋 메시지 컨벤션에 따라 작성
- 작업 브랜치 최신화
- 변경 사항이 없는 경우:
git pull origin dev - 변경 사항이 있는 경우
git add, commitgit stash(아직 완료하지 않은 일을 커밋하기 껄끄러울 때 사용)- a와 b 중 선택. 이후에
git pull origin dev
- 변경 사항이 없는 경우:
-
작업 브랜치를 origin에 push
git push origin feat/review -
dev 브랜치에 PR
- PR 템플릿 사용
- Reviewer, Assignees, Labels 지정
-
reviewer들의 리뷰가 승인되면 본인이 merge (merge한 브랜치는 삭제)
-
최종 테스트 후 main 브랜치에 merge
- main 브랜치에서 버그가 발생한다면 hotfix 브랜치 생성
- 버그 수정이 끝나면 dev과 main 브랜치에 각각 merge
3. Issue와 PR을 이용해 협업하기
3-1. Issue
이슈(Issue)란 프로젝트 작업 단위이다. 개발, 오류, 건의 등 프로젝트에서 발생한 문제들을 이슈로 생성하여 추적하고 관리한다. 이슈를 생성하고 담당자를 지정하고, 토론을 진행할 수 있다.
따라서 기능 개발을 시작하기 전 이슈를 생성하는 것이 가장 우선 순위이다. 작업할 내용을 명시하고 팀원들과 공유하는 목적으로 사용한다.
하지만 팀원들 모두 작성하는 방식이 다르기 때문에 이슈 템플릿을 사용하여 일관된 양식으로 작성할 수 있도록 한다.
이슈를 생성할 때는 이슈 템플릿에 맞게 작성한 후 1. 담당자(assignees)를 지정하고 2. Labels을 사용해 작업 유형을 구분한다. 그리고 3. Projects를 지정하면 Projects에서 이슈들을 한 눈에 확인할 수 있다. 4. Milestone은 진행 상황을 추적하기 위해 사용한다.
(+) Labels
프로젝트에서 발생하는 다양한 이슈들을 라벨을 통해 적절한 카테고리로 분류할 수 있다. 버그, 기능 개발, 문서 작성 등으로 분류하여 팀원들이 어떤 종류의 작업을 진행하는지 쉽게 파악할 수 있어 유용하다.
3-2 Pull Request
각자 브랜치에서 작업한 내용을 프로젝트에 반영하고자 할 때, 다른 사람들의 조언을 받고자 할 때 사용하는 것이 Pull Request(이하 PR)이다. 코드의 품질을 높이고 프로젝트를 안정적으로 관리할 수 있는 Github의 중요한 기능이다.
변경 사항에 대한 설명과 관련 커밋들을 포함하여 리뷰어들이 변경 사항에 대한 이해가 쉽고 변경 사항을 리뷰하고 코멘트를 남길 수 있다.
이슈를 기반으로 작업하고 자신의 작업 브랜치에 푸시한다. develop 브랜치에 병합하기 위해 정의된 템플릿을 활용해 PR 생성하고 팀원들의 코드 리뷰를 받아 코드를 개선하고 승인이 완료되면 자신이 직접 병합한다.
main과 develop 브랜치는 2명 이상 승인을 받아야 병합할 수 있도록 브랜치 보호 규칙을 설정해 두었다. 실수로 인해 중요한 브랜치에 코드를 푸시하는 상황을 막고 코드 리뷰를 활성화하기 위한 목적이다.
4. Projects: 작업 관리 및 추적
Project는 프로젝트의 작업 관리와 추적을 위한 기능이다. 이슈들과 PR을 한 눈에 볼 수 있다. PR을 생성할 때도 Projects에 추가할 수 있지만 이슈를 추가 생성하여 관리하는 방식으로 결정했다.
기존에 사용하던 방식은 보드 형식이었으나 이번에는 테이블 형식의 레이아웃을 사용해보았다. 보드 형식은 이슈가 비교적 많이 보이지 않아 스크롤해서 확인했는데 은근히 불편했다.
노션에도 동일한 기능이 있지만 이슈를 기반으로 github에서 전반적으로 관리할 수 있다는 장점이 있어 사용하였다. 또한, 이전 팀 프로젝트에서는 매 작업을 수행할 때마다 이슈를 생성했었는데 어떤 작업이 있는지 파악하기 어려웠었다.
최종 프로젝트인 만큼 정확히 역할을 분담하고 진행 상황, 작업 내용을 분명히 명시하기 위해 초기에 이슈를 생성하여 Projects에 추가하였다.
5. Milestone: 일정 관리
이슈를 생성할 때 Milestone 역시 지정했었다. Milestone은 프로젝트의 일정을 관리하고 추적하기 위해 사용한다.
특정 기간 동안의 작업 진행 상황을 한눈에 확인할 수 있어 기간 내의 목표를 설정하고 목표에 대한 진행 정도를 파악하고자 도입하였다.
6. Wiki: 문서화
개발하며 여러 플랫폼에서 작성한 문서를 확인하기 위해 여러 창을 띄워 확인하는 경우가 많다. 코딩 컨벤션과 깃 전략 등 자주 확인하는 내용은 가급적 한 곳에 저장하여 참고하는 것이 편하다.
Wiki는 Github 저장소에서 간단한 문서를 작성하고 관리할 수 있다. Github에서 개발 문서를 참고하고 README 외에 추가적인 개발 기록을 위해 Wiki를 사용했다.
잘 작성된 개발 문서는 커뮤니케이션을 줄이고 일관성 있게 코드를 작성할 수 있으므로 개발 효율성이 높아진다.
7. Slack과 Github 연동
팀원분이 알려주셔서 slack과 github을 연동할 수 있음을 알게 되었다. PR 알림이 메일로 와서 늘 확인하기가 어려웠다. 그래서 이번 기회에 slack과 연동하여 활동에 대한 알림을 받고자 사용해보았다.
Slack과 연동을 통해 PR 생성과 리뷰어의 코멘트 등 이벤트가 발생하면 실시간으로 알림을 발송한다. 이는 프로젝트를 더욱 효과적으로 관리하고 신속하게 처리할 수 있도록 도와준다. 방법은 아래의 글을 참고.
연동 후에 이슈를 생성하였더니 바로 Slack으로 알림이 왔다.
후기
프로젝트의 기한은 정해져 있고 “어떻게 하면 개발 생산성을 늘릴 수 있을까”를 생각하면 “Git과 Github을 잘 사용하면 되지 않을까?” 라는 생각으로 도달한다.
최종 프로젝트를 시작하며 기존에 사용하던 방식에서 불편한 점들을 개선하고 보다 효율적으로 Github을 사용할 수 있는 방법을 찾아보았고 적용하려 한다. 이슈 트래킹, 일정 관리, 문서와 프로젝트 전반을 Github에서 제공하는 기능들로 관리하며 협업에 능한 개발자 역량을 향상시키는 프로젝트가 되지 않을까.
댓글남기기