GitHub Rule

캡스톤디자인
2025년 02월 13일
6분
thumbnail.png
GitHub Rule 2025: Capstone Design

1. 브랜치 전략 (Branch Strategy)

1.1 주요 브랜치

  • master: 프로덕션(배포)용으로 사용되는 최종 안정 브랜치 (주 1회)
  • develop: 개발이 완료된 기능들을 합치고, QA를 거친 뒤 최종적으로 master 브랜치로 병합되는 브랜치

1.2 보조 브랜치

  • feature/: 새로운 기능 개발이나 개선 작업에 사용
    예) feature/cmyk-32, feature/cmyk-24
  • hotfix/: 프로덕션에서 발견된 긴급 버그 수정에 사용
    예) hotfix/issue-32, hotfix/issue-24

1.3 브랜치 생성 및 종료

  1. 작업 전 develop 브랜치에서 새로운 feature/ 브랜치를 생성
  2. 작업 완료 후 PR(Pull Request)을 열고 reviewer를 지정
  3. reviwer는 code reivew가 완료된 브랜치를 develop 브랜치로 머지
  4. 긴급 수정 사항 발생 시, master에서 hotfix/ 브랜치를 생성 후 수정 완료 시 master과 develop 두 브랜치에 모두 병합

2. 커밋 규칙 (Commit Convention)

2.1 Commit message 구조

헤더는 필수이며 범위, 본문, 바닥글은 선택사항
<type>(<scope>): <subject> - 헤더
# 개행
<body> - 본문
# 개행
<footer> - 바닥글

<type>은 커밋 유형을 나타내며 아래 중 하나여야 한다.

feat: 새로운 기능 추가
fix: 기능 수정
bugfix: 버그 수정
comment: 주석 추가
docs: 문서 수정(README.md 등)
style: 스타일 수정(디자인 수정, 코드 포맷팅, 세미콜론 누락 등)
refactor: 코드 리팩토링(기능 수정 없이 구조만 개선)
test: 테스트 코드 추가 또는 수정
chore: 빌드 업무, 패키지 매니저 수정 등
perf: 성능 개선

2.2 Commit message 규칙

제목 Header

  1. 제목과 본문을 빈 행으로 구분한다.
  2. 제목은 50글자 이내로 제한
  3. 제목의 첫 글자는 대문자로 작성
  4. 제목 끝에 마침표 넣지 않기
  5. 제목은 명령문으로 사용하며 과거형을 사용하지 않는다
feat: Add user login feature

본문 Body

  1. 선택 사항
  2. 본문의 각 행은 72글자 내로 제한
  3. 본문은 어떻게보다 무엇을, 왜에 맞춰 작성하기
- Created new LoginScreen for user authentication
- Implemented Firebase Auth for credential management
- Added error handling for invalid credentials
  1. 선택사항
  2. 이슈를 추적하기 위한 ID를 추가할 때 사용
    해결 - 해결한 이슈 ID
    관련 - 해당 커밋에 관련된 이슈 ID
    참고 - 참고할만한 이슈 ID
해결: #123
관련: #321
참고: #222

커밋 예시

feat: Add user login feature <- 요약된 설명
 
- Created new LoginScreen for user authentication <- 비교적 자세한 설명
- Implemented Firebase Auth for credential management
- Added error handling for invalid credentials
 
해결: #123 <- 해결된 이슈

3. Pull Request 규칙

3.1 리뷰어 지정 (Reviewer Assignment)

junni01kim -> 6-keem -> KJH0506 -> HS-JNYLee

  1. 지정된 코드 리뷰어가 리뷰 진행
  2. 기능 개발 시, 해당 코드에 관계가 있는 사람 혹은 해당 모듈(화면/UI/비즈니스 로직)에 대한 이해도가 높은 사람 리뷰어로 지정
  3. 긴급 수정(hotfix/ 등)의 경우, 리뷰가 지연되지 않도록 가능한 한 빨리 리뷰어를 배정하고 리뷰가 완료되는 대로 머지
  4. 리뷰어가 제안하는 수정 사항이 있으면, PR 작성자는 반드시 검토 후 반영 여부를 결정하고, 필요한 경우 재리뷰 요청

3.2 PR 양식 (Pull Request Template)

PR을 생성할 때, 반드시 PR 템플릿을 사용하여 아래 항목을 명시

예시 템플릿

<h3>JIRA Task 🔖</h3>
 
- **Ticket**: [티켓번호](링크)
- **Branch** : feature/cmyk-**
 
<h3>작업 내용 📌</h3>
 
- 이번 PR에서 **무엇**을 구현/수정했는지 요약
- 주요 변경 사항을 간단히 기술
 
<h3>작업 배경 🔎</h3>
 
- 해당 작업을 진행하게 된 **이유**나 문제 상황
- 관련 이슈나 요구 사항(기능 개선, 버그 수정, 성능 향상 등)
 
<h3>변경 전후 비교 🖥️</h3>
 
- 변경 전 동작/구조와 변경 후 동작/구조 비교
- UI 변경이 있는 경우, 스크린샷 첨부
- 핵심 코드나 로직 설명
 
<h3>테스트 방법 🧑🏻‍🔬</h3>
 
- 리뷰어가 확인해야 할 테스트 시나리오, 시뮬레이션 방법
- 예상되는 결과(기대값)와 실제 결과 비교
- 테스트 환경(에뮬레이터, 실제 디바이스, OS 버전 등)
 
<h3>참고 사항 📂</h3>
 
- 관련 이슈 번호: `Closes #123`
- 참고 문서, 레퍼런스 링크
- 기타 특이 사항, 향후 개선 사항