Github Rules

✨ Issue Management

• 미리 작성해둔 Issue Template을 바탕으로 이슈를 작성한다.

  • ✏️ Description : 이슈에 대한 설명 작성
  • 🗓️ Goal : 이슈를 해결할 기간을 명시
  • ✔️ Progress : 이슈를 세분화하여 체크박스와 함께 진행상황을 확인할 수 있도록 함

• Assignees : 관련된 담당자에게 이슈를 할당

• Labels : 이슈와 관련된 라벨을 붙임(중복선택 가능)

  • 📐 Design : 설계
  • 📜 Documents : 문서 관리
  • ⚙️ Setting : 개발 환경 및 배포 설정
  • 🏠 Build : 새로운 라이브러리 혹은 패키지 설치
  • 🔎 Frontend : 프론트엔드 관련
  • 🔬 Backend : 백엔드 관련
  • 💡 Feature : 기능 추가
  • 🚀 Test : 테스트 코드 작성
  • 🌈 Refactor : 코드 리팩토링
  • ✨ Style : 스타일만 수정
  • 🚨 Bug : 고쳐야 할 버그
  • 🍿 etc : 기타

• Projects : 이슈를 해당되는 Projects Board와 연결

  • Common : 공통사항 관련 스크럼 보드
  • Frontend : 프론트엔드 관련 스크럼 보드
  • Backend : 백엔드 관련 스크럼 보드

• Milestone : 이슈를 해결할 스프린트 기간을 선택

  • Sprint 1 : 첫 번째 스프린트(2021년 8월 2일~2021년 8월 22일)
  • Sprint 2 : 두 번째 스프린트(2021년 8월 23일~2021년 8월 29일)
  • Sprint 3 : 세 번째 스프린트(2021년 8월 30일~2021년 9월 5일)
  • Sprint 4 : 네 번째 스프린트(2021년 9월 6일~2021년 9월 12일)
  • Sprint 5 : 다섯 번째 스프린트(2021년 9월 13일~2021년 9월 19일)
  • Sprint 6 : 여섯 번째 스프린트(2021년 9월 20일~2021년 9월 26일)
  • Sprint 7 : 일곱 번째 스프린트(2021년 9월 27일~2021년 10월 3일)
  • Sprint 8 : 여덟 번째 스프린트(2021년 10월 4일~2021년 10월 10일)
  • Sprint 9 : 아홉 번째 스프린트(2021년 10월 11일~2021년 10월 17일)
  • Sprint 10 : 열 번째 스프린트(2021년 10월 18일~2021년 10월 24일)
  • Sprint 11 : 열한 번째 스프린트(2021년 10월 25일~2021년 10월 31일)
  • Sprint 12 : 열두 번째 스프린트(2021년 11월 1일~2021년 11월 7일)
  • Sprint 13 : 열세 번째 스프린트(2021년 11월 8일~2021년 11월 14일)
  • Sprint 14 : 열네 번째 스프린트(2021년 11월 15일~2021년 11월 21일)
  • Sprint 15 : 열다섯 번째 스프린트(2021년 11월 22일-2021년 11월 28일)

✨ Branch Strategy

• Git Flow 관련 참고 자료
  • GitFlow? 들어도 봤고, 쓰고도 있는데...
• Branch 전략
  • 관리해야 할 브랜치가 많으면 통합이 어렵고 배포를 드물게 하게 되는 단점이 있음
  • 따라서 기본적으로 Git Flow를 따르되 CI/CD를 고려하여 release, hotfix 브랜치는 사용하지 않고 아래 3개의 브랜치를 사용함.
  • feature
    • 기능을 추가하거나 이슈를 해결하기 위한 브랜치
    • 새롭게 브랜치를 생성할 때 다음과 같은 이름으로 생성
      • ex) feature/ISSUE-97
    • 각자가 맡은 기능에 따라 feature 브랜치에서 작업하고 완료되면 develop 브랜치에 merge하고 push함
  • develop
    • 현재 개발이 완료된 상태와 일치하는 브랜치
    • 다음 릴리즈를 위해 언제든지 배포될 수 있는 상태
    • 팀원들의 feature 브랜치가 merge되는 브랜치이며 conflict 발생시 push한 사람이 해결함
    • develop 브랜치에 푸시하면 Travis CI와 AWS CodeDeploy에 의해 CI/CD가 이루어지며 프로젝트가 AWS EC2에 배포됨
    • 개발 서버(AWS EC2)에서 정상적으로 동작하는지 확인하고 이상이 없으면 Pull Request를 작성함
    • Pull Request 후 코드 리뷰를 받으면 main 브랜치에 push
      • 이 때 관련된 모든 작업이 완료되면 해당 feature 브랜치를 삭제하고 해당 이슈 또한 Close 처리
  • main
    • 현재 서비스 중인 제품의 상태와 일치하는 브랜치
    • 브랜치 이름으로 주종 관계를 암시하는 master 대신 main 사용함
    • main 브랜치에 푸시하면 Travis CI에 의해 CI/CD가 이루어지며 백엔드는 Heroku에 배포되고 프론트엔드는 Netlify에 배포됨
    • 운영 서버(Heroku, Netlify) 배포시 이슈가 발생하면 다시 이전 단계로 돌아감

✨ Commit Message Style Guide

• 타입, 이슈번호와 함께 제목을 쓰며, 제목은 한글로 쓴다.(특정 이슈와 연결짓기 어려운 경우 이슈번호는 생략할 수 있다)
• 제목 끝에 마침표를 넣지 않는다.
• 본문을 작성할 경우 어떻게 변경했는지보다 무엇을, 왜 변경했는지에 맞춰 작성한다.
• 제목과 본문은 한줄을 띄워서 분리한다.
• Commit Message Type
  • feat : 새로운 기능 추가
  • fix : 버그 수정
  • docs : 문서 추가, 변경
  • style : (코드의 수정 없이) 스타일만 변경(ex: 들여쓰기 같은 포맷, 세미콜론 추가, 오타 수정, 변수명 변경 등)
  • refactor : 코드 리팩토링
  • test : 테스트 관련 코드 추가, 변경
  • chore : (코드의 수정 없이) 설정을 변경
  • build : 새로운 라이브러리 혹은 패키지 설치
  • revert : 작업 되돌리기
  • perf : 성능 개선
  • etc : 기타
• 예시

feat #10 - 회원정보 불러오기 기능 추가

- 본문 내용1
- 본문 내용2

✨ Pull Request(PR)

• 하루 작업을 마무리한 뒤 feature 브랜치에서 develop 브랜치로 merge하고 push한 뒤 PR을 작성한다.(develop->main)

• 미리 작성해둔 Pull Request Template을 바탕으로 풀 리퀘스트를 작성한다.

  • ❓ Description : 내가 보내는 PR이 무엇인지 설명
  • 🖍️ Changes details : 자세한 변경사항을 작성
  • 📷 Screenshot : 필요시 스크린샷 첨부

• Reviewers : 코드리뷰를 해줄 팀원 등록

• Assignees : PR 작성자 등록

• Labels, Projects, Milestone : 이슈 작성 때와 마찬가지로 해당되는 사항을 등록

• Linked Issues : 관련된 이슈를 연결

• PR이 등록되면 리뷰어는 되도록 빠른 시간 내에 리뷰하고 늦어도 다음날 오전 10시 전까지는 리뷰한다.(PR은 슬랙과 메일로 알림이 옴)

  • Files changed에서 변경사항을 확인하고 Review changes에서 아래 항목을 선택해서 코드 리뷰를 한다.
  • Comment : 승인과 무관하게 일반적인 코멘트를 달 때 선택
  • Approve : merge를 승인
  • Request changes : merge를 거절하며 변경 요청

• 코드 리뷰가 완료되면 PR 작성자는 develop를 main으로 merge하고 push한다.

• 관련 feature가 더 이상 필요하지 않게 되면 관련 feature 브랜치를 삭제한다. 관련 이슈가 완전히 종료되면 이슈 또한 close한다.