팀 프로젝트 협업하기

공유용으로 작성. Organization을 사용하려면 github 블로그에 작성한 글 참고 TIL 23-10-24

목차

• 깃 전략 수립
  • 커밋
  • Issue
  • Projects
  • PR
  • Wiki
  • 브랜치 전략

깃 전략 수립

github으로 협업하며 프로젝트 전반을 관리하기 위해 제공하는 기능들을 사용한다. 순서대로 기록해보았다.

커밋

커밋 메시지도 각자 작성하는 방식이 다르다. 특정 커밋을 보고 어떤 내용인지 충분히 추측 가능해야 한다. 그래야 가독성이 높아지고 개발 속도가 빨라지며 코드에 대한 리뷰도 수월해진다. 따라서, 공통적인 커밋 메시지 규칙을 정한다.

커밋 유형: 작업 내용 (#이슈 넘버)

type: subject (#issue_number)

커밋 유형

• feat : 새로운 기능 추가
• fix : 버그 수정
• docs : 문서 수정
• style : 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우
• refactor : 코드 리펙토링
• test : 테스트 코드, 리펙토링 테스트 코드 추가
• chore : 빌드 업무 수정, 패키지 매니저 수정

규칙

• type은 소문자로 작성
• 제목 끝에 마침표 넣지 않기
• 명사형으로 작성

Issue

이슈(Issue)란 프로젝트 작업 단위이다. 개발, 오류, 건의 등 프로젝트에서 발생한 문제들을 이슈로 생성하여 관리한다. 커밋 메시지에 이슈 번호를 포함하면 이슈에 대한 커밋 내역들을 해당 페이지에서 확인할 수 있다. 작업을 시작하기 전 이슈를 생성하는 것이 가장 먼저 하는 일이다. 작업할 일을 명시하는 작업.

이슈 템플릿을 사용하면 일관된 양식으로 작성할 수 있다. 템플릿을 등록하면 이슈를 기능 구현과 버그 수정으로 구분하여 선택할 수 있다.

이슈를 생성할 때는 담당자(assignees)를 지정하고 Labels을 사용해 작업 유형을 구분한다. 그리고 Projects를 지정하면 프로젝트에서 이슈들을 한 눈에 확인할 수 있다. 제목은 다음과 같이 작성한다. [작업유형/기능명] 내용 작업유형은 커밋 메시지 컨벤션을 따른다.

Github Issue Templates으로 Issue 쉽고 체계적이게 작성해보기

Issue 작성법

1. 템플릿에 맞게 Issue 내용 작성
2. 담당자(Assignee)를 지정
3. 라벨 달기
4. 프로젝트 지정

Projects

잠시 살펴봤지만 Projects는 프로젝트의 작업 내용과 진행 사항을 볼 수 있는 페이지다. 이슈들과 PR(Pull Request)를 한 눈에 볼 수 있다. PR을 생성할 때도 Projects에 추가할 수 있다. Projects를 사용하면 작업을 추적하고 프로젝트를 직관적으로 관리할 수 있다.

• To Do: 해야할 작업
• In Progress: 진행 중인 작업
• Done: 완료된 작업

노션에도 동일한 기능이 있지만 github에서 전반적으로 관리할 수 있다는 장점이 있어 사용한다. 템플릿은 변경할 수 있지만 칸반 보드 형식이 자주 사용되므로 Board를 사용한다.

PR

이슈를 기반으로 작업을 수행한 뒤 PR을 생성한다. 마찬가지로 정의된 템플릿을 활용해 PR을 생성하고 git-flow 개발 프로세스에 따라 개발한다. 커밋과 PR은 최대한 작은 단위로 쪼개는 것이 좋다.

규칙

• 제목은 이슈 제목과 동일하게 하고 이슈 번호 붙이기
  • [feature/search] 검색 기능 구현 (#1)
• Reviewers, Assignees, Labels, Projects, Linked issues 지정
• 검토가 끝나면 본인이 직접 PR을 merge하고 브랜치 삭제

▶ git 연습 레포에서 이미 생성된 PR을 가지고 왔다.

develop 브랜치와 main 브랜치는 브랜치 보호 규칙을 설정해 3명 이상 approve가 있어야 merge할 수 있도록 할 예정이다.

Wiki

문서를 공유하기 위해 github의 Wiki를 사용한다. 팀 소개와 프로젝트 내용, 개발 관련 문서 등 모두 Wiki에서 관리한다. 비슷한 유형의 문서끼리 분류하고 가독성을 높이기 위해 사이드바를 이용해 Wiki 문서를 표시할 수 있다.

브랜치 전략

브랜치 전략이란 여러 개발자가 협업하는 환경에서 git 저장소를 효과적으로 활용하기 위한 workflow이다. git-flow라는 브랜치 전략을 사용한다.

git-flow: 5가지의 브랜치를 이용해 운영하는 브랜치 전략

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그

• main: 배포 가능한 브랜치
• develop: 개발한 기능이 모여있는 브랜치
• feature: 기능을 개발하는 브랜치 (develop 에서 분기)
• release: QA(품질검사)를 하기위한 브랜치 (출시 준비)
• hotfix: main 브랜치에 발생한 버그를 긴급수정하는 브랜치

실제 적용은 main, develop, feature, hotfix 네 개의 브랜치만 사용할 듯하다.

브랜치 네이밍 컨벤션

• main
• develop
• feature/{feature_name}
• hotfix/{issue_number}

git-flow 개발 프로세스

1. develop 브랜치에서 새로운 기능 개발 브랜치 생성 feature/{feature_name}

2. 개발 후 feature/{feature_name} 브랜치에 push

3. develop 브랜치에 pull requests

4. reviewer들의 리뷰가 승인되면 본인이 merge (merge한 브랜치는 삭제)

5. 최종 테스트 후 main 브랜치에 merge

   5.1. main 브랜치에서 버그가 발생한다면 hotfix 브랜치 생성

   5.2. 버그 수정이 끝나면 develop과 main 브랜치에 각각 merge