[카카오 테크 캠퍼스 1기] 3단계 Garden (Project Rule)

우리 팀은 아래와 같은 협업 도구를 이용하였다. 

가벼운 소통이나 회의는 슬랙에서, 코드 관리는 깃허브에서, 회의 내용 및 주간 일정 정리는 노션에서 이루어졌다. 

 

그 중에서도 깃허브에서의 충돌이나 혼란을 피하고자 아래와 같은 프로젝트 룰을 설정하였다. 

 

Branch

---

Branch Hierarchy

**master**                               : 최종
 ├─ **dev**                              : 오류 해결
 │  └─ **weekly**                        : 주차별 코드 종합
 │     ├─ feature/1-branch-**account**   : 계정 관련 기능
 │     ├─ feature/2-branch-**watching**  : 와칭 관련 기능
 │     ├─ feature/3-branch-**mentoring** : 멘토링 관련 기능
 │     └─ feature/4-branch-**chatting**  : 채팅 관련 기능
 └─ **review**                           : 현업 멘토 리뷰

 

PR은 위와 같은 플로우로 이루어졌다. 

각자의 기능에 따라 브런치를 갖고 이를 모두 위클리에서 합친다. 

위클리에서 dev로(오류 해결), dev에서 master(최종)으로 PR을 보낸다. 

최종 PR은 멘토님의 리뷰를 받기 위해 review (리뷰)브런치로 보낸다. 

나는 (테크리더 == 깃허브 담당) 상위 브랜치로의 풀 리퀘스트(PR)를 담당하였다. 이 과정에서 지난주에 보낸 PR이 아직 병합되지 않은 상태였는데, 이번 주에 새로운 PR을 보내면서 내용이 섞이는 문제를 겪었었다. 이 문제는 PR을 Revert하는 방법으로 해결 할 수 있었다. 

 

Branch Protection Rule

• Require a pull request before merging
  • branch에 직접 push ❎, PR로만 merge 가능
  • 승인 인원 : 2명 (본인 제외)
  • 적용 브랜치 : master, dev, weekly, review(1명)
• Do not allow bypassing the above settings
  • 관리자 권한을 가진 유저들도 룰을 지켜야 merge 가능

처음에는 weekly에는 브런치 룰을 걸지 않았었는데 진행하다보니 모든 코드들이 합쳐지는 곳이 위클리기 때문에 

가장 위험하다고 생각이 들었고, 다른 팀원 2명이 모두 확인 후 승인 해줘야 머지가 가능케 했다. 

 

 

Issue

---

Issue 생성

• 코드 변경이 발생되는 모든 행동에 대해 Issue 생성
• 문제 해결을 위한 논의가 필요할 때 Issue 생성

Issue Label

• Type
• Feature 기능 Improvement 개선 Bug 오류 Discussion논의
• Priority
  • Normal일반 Urgent 긴급
• Status
  • Available 진행가능 In Progress 진행중 Completed 진행완료
  • Pending 보류중 Abandoned 포기

Issue Template

• Default ( type : Feature , Improvement , Bug )

  Title {이슈 요약(대상 + 행동 like 페이지 구현)} 
  
  Content 
  ## Description 
  {이슈 설명} 
  ## TO-DO 
  - [ ]  {할 일} 
  ## ETC 
  {기타 내용}

 

• Discussion ( type : Discussion )

  Title {이슈 대상} 관련 논의 
  
  Content 
  ## Problem 
  {문제 상황} 
  ## Goal 
  {해결 목표}
  ## Related Issue 
  #{이슈 번호}

 

Pull Request

---

Pull Request 수행

• 이슈와 연관지어, 1주에 1회 이상 PR 수행

Pull Request Template

// Title
{PR 요약(대상 + 행동 like 페이지 구현)}

// Content
## Summary

{PR 설명}

## Details

#이슈번호 TO-DO

• {해당 이슈에서 수행한 TO-DO}

- {PR 설명}

## Issue

- Related #이슈번호
- Close #이슈번호

Review PR

• 제목 : 전남대_18조_Garden_0주차
• 라벨 : Request Review
• PR후 슬랙에서 멘토님 태깅

 

 

PR과 이슈는 생각보다 많이, 자주 생성하게 된다. 그럴때마다 형식을 확인하면서 맞추기도 번거롭고, 이를 간혹 까먹을 수도 있고,  보고 맞추더라도 작성 내용이 형식이 어긋날 수 있다. 

이러한 이유들로 나는(테크리더 == 깃허브 담당)  PR이나 이슈 생성 시 템플릿이 자동 생성되도록 설정하였다.

 

• PR 의 경우 

.github 폴더 하위에 pull_request_template.md 파일을 생성하고, 해당 템플릿을 작성한다. 

 

• 이슈의 경우 

깃허브 setting에서 이슈 템플릿 커스텀이 가능하다. 

해당 내용을 원하는 템플릿으로 작성하고 commit 하면 .github 폴더 하위에 ISSUE_TEMPLATE 폴더가 생성된것을 확인할 수 있다. 

 

 

Commit

---

Commit 수행

• Issue 내 TO-DO 해결 시 Commit 수행
• TO-DO가 아니더라도, 하단 type으로 구분 지을 수 있는 행동에 대해 Commit 수행

Commit Template

• Template

{type}: {subject} 
{body} 
{footer}

• Definition
  • type
    • feat 기능 fix 코드 수정 docs 문서/주석 chore 패키지/배포 style 포맷팅 refactor 리팩토링  test 테스트
    • footer에 BREAKING CHANGE가 존재할 경우 ➡️ type 뒤에 느낌표를 붙여 문제가 있음을 명시
  • subject
    • commit 내용에 대한 요약
    • 50자 제한, 명사형 종결 예) 구현, 작성, 수정, 제거
  • body
    • commit 내용 설명
    • 한 줄 72자 제한, ~ㅁ 어미 종결 예) 추가함, 고침, 제거함
    • How보다 What(+Why)에 초점을 맞춰 작성 예) 이런 이유로 무엇을 구현했음
  • footer(있을 때)
    • 관련 이슈 ※ 이슈 해결은 PR에서 처리 예) Related #1
    • commit함으로써 다른 기능에 영향을 줄 수 있는 문제 예) BREAKING CHANGE: API 명칭을 바꿈

 

어떻게 보다는 이 코드를 왜 ? 이렇게 작성했는지, 변경했는지 에 중점을 두도록 하였다.