처음 해보는 github 프로젝트 관리
항해 99 합류 전 사전스터디에서 토이 프로젝트를 하면서 github 프로젝트의 관리를 맡게 되었다. 사실 내 목표는 “충돌만 나지 않게 관리하자 제발!” 이었으나, 여차저차 잘 관리해서 프로젝트를 마무리까지 할 수 있었다.
github 관리의 흐름에 대해서 오늘 글에서 정리하고자 한다.
1. 이슈 생성
이슈는 다양하게 생성할 수 있지만, 우선 우리 프로젝트에서는 feature(기능 개발), bug(버그)로 두 가지만 상정하고 이슈템플릿을 만들었다. 이슈 템플릿 양식은 다음과 같다.
1.1. 템플릿 이름과 설명
1.1.1. feature
- issue : Feature ✅
- Feature 작업 상황을 입력해주세요!
1.1.2. bug
- issue : Bug ❌
- 처리 해야 할 버그를 알려주세요!
1.2. 템플릿 양식
1
2
3
4
5
6
7
8
9
10
## Description
설명을 작성해주세요!
## Todos
- [ ] todo
- [ ] todo
## ETC
1.3. 이슈 생성 규칙
이슈 생성 규칙은, 꼭 앞에 feature 또는 bug를 붙이는 거였다.
예시:
- feature/index
- feature/login
- feature/add
이렇게 한 다음, 작업 브랜치 명과 동일하도록 하였다.
2. 브랜치 생성
각자 작업할 브랜치를 생성하도록 하였다. 작업 브랜치는, 각자의 이름으로 할 수도, 기능으로 할 수도 있었으나 후자를 선택했다. 후자가 일반적인 방법이기도 하고, 꼭 그 기능을 한 사람이 한다는 보장이 없어서 확장성 측면에서도 나아 보였다.
브랜치명은 이슈명과 동일하도록 하였다.
예시:
- feature/index
- feature/login
- feature/add
3. main 브랜치에서 직접 작업 및 push 금지
“main 브랜치에서는 오류가 발생하지 않아야 한다” 라는 규칙을 만들었다. 따라서, 오류가 발생한다면 해당 브랜치에서 해결 후 PR을 해서 main 브랜치로 Merge시키는 방향으로 잡았다.
이를 위해 github Branch protection rule을 설정하였다.
Protect matching branches 의 Require a pull request before merging, Require review from Code Owners에 체크해주었다.
약속 뿐만 아니라, 실제로 직접 push가 되지 않도록 막아둔 것이다.
4. 작업 흐름
매일 작업에 순서가 필요했다. 항상 각자의 브랜치는 전날 main 브랜치로 최신화가 되어 있어야 했다.
그래서 이런 흐름이 되도록 하였다.
- 작업 종료시 PR 요청
- 리뷰어(이 프로젝트에서는 본인)이 해당 브랜치에서 pull을 해본 뒤 오류가 없다면 main 브랜치에 merge, 오류나 개선점이 필요하다면 작업자에게 문의
- 다음 날 작업 시작 전 main 브랜치에서 pull을 한 다음, 작업자 본인 브랜치에 main 브랜치를 merge해서 항상 작업 브랜치를 최신화
5. 아쉬운 점
PR을 단순히 main 브랜치에 merge하는 용도가 아닌, 팀원간 코드리뷰를 위해 사용할 수도 있었으나, 시간이 촉박하였고, 첫 관리이다보니 여기까지는 해보지 못한 점이 아쉬웠다.