들어가며
프로젝트를 진행하다 보면 협업 절차와 가이드라인을 만드는 게 정말로 중요하다. 만약에 컨벤션이나 브랜치 전략 등 어떠한 기준과 업무 방식에 대한 전략도 없이 프로젝트를 진행하게 되다면 그 프로젝트의 성과는 당연히 나쁠 수밖에 없다. Git을 활용하여 협업을 진행한 내용을 정리해보고자 글을 작성하였다.
협업 가이드 제작
Git으로 프로젝트 협업을 진행해본 적이 없거나 AWS 배포 경험이 없는 사람들과 프로젝트를 진행해본 적이 있는가? 협업을 경험한 사람과 그렇지 않은 사람과의 수준 차이는 어마어마하다. 정해진 업무 절차에 따라 개발을 하는 것과 달리 단순히 기능 개발과 완성에만 집중하면서 개발을 한다면 사실상 프로젝트를 통해 얻을 수 있는 건 아무것도 없다고 보는 게 맞다.
나는 처음에 프로젝트를 진행할 때 협업 가이드를 만들어서 팀원들과 공유하였다. 프로젝트의 실시간 관리와 이슈 트래킹을 위해 협업 가이드 제작은 필수였다. 아래 이미지는 내가 프로젝트를 진행하면서 만든 협업 가이드이다.
기본적으로 6개의 가이드를 만들어서 ‘One Team, One Goal’의 원칙을 지키면서 프로젝트를 진행하였다.
그라운드 룰
팀원들이 프로젝트 진행일정을 준수할 수 있도록 그라운드 룰을 만들었다.
이슈 컨벤션
이슈 유형별로 컨벤션과 템플릿을 만들어서 업무 내용과 개발 진행 상황을 공유했다.
Git Commit Convention
커밋 컨벤션을 만들어 소스 코드에 대한 내용을 팀원들이 명시적으로 공유할 수 있도록 하였다.
Pull Request Convention
코드 리뷰를 위한 풀 리퀘스트 컨벤션과 템플릿을 만들어서 팀원들이 작업한 내용에 대한 리뷰와 코멘트를 작성할 수 있도록 하였다.
Git Branch 전략
•
브랜치 규칙과 Git Flow를 활용하여 효율적인 브랜치 관리를 하였다.
•
브랜치 네이밍 규칙을 만들어서 일관된 브랜치명으로 브랜치 관리를 하였다.
◦
예시 1) DunGeonTalk(dgt) → DungeonTalk 약칭-이슈번호 → 이슈유형/dgt-123
◦
예시 2) 이슈유형/#이슈번호 → feature/#123
•
브랜치 Merge 이후에 작업한 브랜치가 쌓이는 것을 방지하기 위해 Merge 후 자동 삭제하여 브랜치가 쌓이는 것을 방지하였다.
GitHub Project
•
실시간으로 이슈 트래킹과 업무 내역을 관리하기 위해 GitHub 프로젝트를 활용하였다.
•
워크플로우를 통해 PR 머지 후 이슈의 상태를 자동으로 변경하는 등의 업무 자동화를 진행하였다.
•
담당자, 진행 상태, 우선순위 등을 설정하여 각각의 이슈에 대한 세부적인 관리를 하였다.
•
칸반 보드와 리스트 형태로 이슈 유형과 업무 내용을 시각화하였다.
GitHub Wiki
•
GitHub Wiki를 활용하여 팀 위키를 생성하였다.
•
공유 문서 페이지를 생성함으로써 프로젝트 진행 과정에서 겪은 이슈나 시행착오를 문서화하였다.
기타 컨벤션
Git 협업을 진행하며 느낀 점
과거엔 Git으로 협업을 어떻게 진행해야 할지 잘 몰라서 Notion을 통해 협업을 진행하였다. 하지만 정작 Git을 활용한 이슈 생성과 PR 생성, Merge 등의 이벤트를 Notion과 연동해서 진행하는 데 어려움을 겪었기 때문에 Notion 팀 위키와 Git을 별도로 운영하며 프로젝트를 진행했다. 하지만 GitHub Wiki와 GitHub Project의 활용 방법을 알게 된 이후부터 Git을 활용한 협업을 유연하게 진행할 수 있었기에 협업 효율 향상에 많은 도움이 되었다. 내가 알고 있는 범위 이상으로 Git을 활용하는 방법이 굉장히 많은 것으로 알고 있다. 앞으로도 Git을 활용한 협업 플로우에 대한 연구를 좀 더 해보면서 협업의 효율을 높이는 방향으로 개발을 하고 싶다.