깃허브 사용 규칙

느슨한 Git Flow

• develop 브랜치에 커밋이 푸시되면 Development 개발 환경에 자동으로 배포돼요.
• 초기 개발 단계에서는 꼭 Release 하지 않더라도 Production 환경에 배포하기 위하여 main 브랜치로 커밋을 푸시할 수 있어요.
• release-*, hotfix-*를 현재 사용하고 있지 않아요.

브랜치 네이밍 규칙

type/name

• 커밋 컨벤션의 타입과 동일하게, 아래의 타입 중 하나를 반드시 사용해야 해요.

타입	설명
feat	새로운 기능
fix	버그 수정
refactor	리팩토링
perf	성능(ex. SEO, 렌더링 최적화)에 영향을 준 리팩토링
design	CSS 또는 UI 변경
style	코드 형식 변경 (세미콜론, 줄바꿈 등)
build	config 파일 변경, dependency 설치 또는 삭제
ci	Github Actions 류 파일의 수정
docs	문서 변경
chore	위 타입에 모두 해당하지 않는 커밋 + move/rename/remove

Pull Request

• 하나의 PR은 하나의 이슈만을 해결하는 것을 기본으로 해요.
• 코드 수정이 한 줄인 PR은 좋지만, 코드 수정이 1만 줄인 PR은 전혀 좋지 않아요. 항상 코드 리뷰하기 좋도록 PR을 작성해주세요.
• PR을 머지할 때, Rebase and Merge를 사용해주세요.

이슈 자동화

Github Project

칸반 보드 형식의 Github Project를 이용하여 일하고 있어요. https://github.com/orgs/42Statistics/projects/3

New - Backlog - Ready - In progress - In review - Done의 단계로 이루어져 있어요.

• New : 단순 아이디어
• Backlog : 이슈 전 단계
• Ready : 이슈 카드
• In progress : 현재 진행 중인 카드
• In review : 현재 진행 중인 PR
• Done : 끝난 카드, PR

사용법

Github Actions를 이용하여 카드를 생성하거나 옮기는 일을 자동화하고 있어요. .github/workflows/project-automations.yml

• 새로운 아이디어나 불명확한 버그가 있다면 New에 카드를 마음껏 올려주세요.
• New에 있는 카드 중 실제 할만한 일이 있다면 Backlog로 직접 옮긴 뒤 세부 내용, 정확한 이슈명, 중요도 및 크기 등을 입력해주세요.
• Backlog에 있는 내용이 꽤 정확해졌다면, Convert to Issue를 클릭 해 이슈로 전환해주세요.
  • 42Stat-Frontend, 42Stat-Backend에 이슈가 올라가면 자동으로 Ready 영역으로 카드가 이동합니다.
  • 각 레포에 직접 이슈를 등록했다면 카드가 Ready에 생성됩니다.
• Ready에 있는 일 중 실제 진행할 일이 있다면 In progress로 직접 옮겨주세요.
  • 가급적 In progress에 담당자, 중요도 및 크기를 채워주세요.
• PR을 올리면 In review에 자동으로 등록됩니다.
  • 반드시 해결되는 이슈를 함께 링크해주세요.
  • 하나의 PR은 하나의 이슈만을 해결하는 것을 원칙으로 합니다.
• PR이 머지되면 PR과 링크된 이슈가 자동으로 Done에 옮겨집니다.