Repository navigation
FE_Git Convention
✅
- 커밋 유형은 영어 대문자로 작성한다
| 커밋 유형 | 의미 |
|---|---|
| Feat | 새로운 기능 추가 |
| Fix | 버그 수정 |
| Docs | 문서 수정 |
| Style | 코드 formatting, 세미콜론 누락, 코드 자체의 변경이 없는 경우 |
| Refactor | 코드 리팩토링 |
| Test | 테스트 코드, 리팩토링 테스트 코드 추가 |
| Chore | 패키지 매니저 수정, 그 외 기타 수정 ex) .gitignore |
| Design | CSS 등 사용자 UI 디자인 변경 |
| Comment | 필요한 주석 추가 및 변경 |
| Rename | 파일 또는 폴더 명을 수정하거나 옮기는 작업만인 경우 |
| Remove | 파일을 삭제하는 작업만 수행한 경우 |
| !BREAKING CHANGE | 커다란 API 변경의 경우 |
| !HOTFIX | 급하게 치명적인 버그를 고쳐야 하는 경우 |
- 커밋 유형 이후 제목과 본문은 한글로 작성하여 내용이 잘 전달될 수 있도록 할 것
- 본문에는 변경한 내용과 이유 설명 (어떻게보다는 무엇 & 왜를 설명)
- 변경 내용 1
- 변경 내용 2
- 변경 내용 3
# 🌿 브랜치 전략 & 네이밍 컨벤션
✅
-
main브랜치는 배포용(branch protection 적용) 으로 직접 커밋하거나 푸시하지 않는다. (Lock) - 모든 개발은
develop브랜치를 기준으로 이루어진다. - 기능 단위로
develop에서 브랜치를 파생하여 작업하고, 작업 완료 후develop브랜치에 병합한다. - 병합 전에는 Pull Request(PR) 를 통해 코드 리뷰 과정을 거친다.
- 브랜치 이름은 영문 소문자로 작성하고, 슬래시(
/)를 이용해 유형/기능 형태로 명시한다.
| 브랜치 유형 | 접두어 예시 | 설명 |
|---|---|---|
| 기능 개발 | feature/ |
새로운 기능을 개발할 때 사용 |
| 버그 수정 | fix/ |
버그를 수정할 때 사용 |
| 문서 수정 | docs/ |
문서 관련 작업 시 사용 |
| 리팩토링 | refactor/ |
코드 구조 개선 시 사용 |
| 디자인 변경 | design/ |
UI, 스타일 변경 작업 시 사용 |
| 테스트 코드 | test/ |
테스트 관련 코드 작성 시 사용 |
| 기타 작업 | chore/ |
설정 파일, 빌드 등 기타 작업 |
예시:
feature/mainPage: 메인 페이지 기능 개발fix/loginError: 로그인 오류 수정refactor/navbar: 내비게이션 리팩토링
-
develop브랜치로부터 기능 브랜치를 생성 - 브랜치에서 개발 작업 수행
- 작업 완료 후,
develop브랜치에 Pull Request 생성 - 코드 리뷰 및 테스트 완료 후
develop브랜치에 병합 - 주요 배포 시점에
develop브랜치를main브랜치에 병합 (배포 태그 포함)
-
main브랜치에는 직접 푸시 금지 (보호 설정 필수) - 브랜치 이름은 간결하고 명확하게 작성
- 커밋 메시지는 커밋 메시지 컨벤션에 따를 것
- 여러 작업을 한 브랜치에 몰아서 작업하지 말고, 기능별로 분리할 것
# 기능 브랜치 생성
git checkout develop
git checkout -b feature/signupPage
# 작업 완료 후
git add .
git commit -m "Feat: 회원가입 페이지 UI 구성"
# 원격에 기능 브랜치 push
git push origin feature/signupPage
# develop 브랜치에 PR 생성
# 코드리뷰 후 merge✅
- 모든 작업(기능 개발, 버그 수정, 문서 작업 등)은 반드시 이슈(issue)로 등록하여 관리한다.
- 이슈는 작업의 목적, 범위, 예상 결과를 명확히 작성한다.
- 이슈는 작업 유형에 따라 label(예: feature, bug, docs 등)을 지정한다.
- GitHub(또는 사용하는 Git 플랫폼)에서 New Issue 버튼을 클릭한다.
- 제목은 간결하게, 내용에는 작업 목적 및 상세 설명을 작성한다.
- 적절한 label을 선택하고, 필요하다면 assignee(담당자)를 지정한다.
여기서 오른쪽 하단에 create a branch 클릭
branch source는 develop으로 설정 후 생성
git fetch origin
git checkout feature/mainPage해당 명령어 터미널에 복붙 후 브랜치 사용
- 작업 완료 후, develop 브랜치로 Pull Request를 생성한다.
- PR 제목 또는 설명에
Closes #이슈번호또는Fixes #이슈번호를 명시하여 PR이 병합되면 이슈가 자동으로 닫히도록 한다.- 예시:
- PR 제목:
Feat: 회원가입 페이지 UI 구현 (Closes #12) - PR 설명:
이 PR은 회원가입 페이지 UI를 구현합니다. Closes #12
- PR 제목:
- 예시:
- 코드 리뷰 및 테스트 완료 후 develop 브랜치에 병합한다.
- 이슈 생성
- 브랜치 생성 및 작업
- PR 생성 및 이슈 연결
- 코드 리뷰 및 병합
- 이슈 자동 종료
-
이슈 생성 (예: 회원가입 페이지 개발, 이슈 번호 #12) 및 브랜치 생성
git fetch origin git checkout feature/signIn -
작업 후 커밋
git add . git commit -m "Feat: 회원가입 페이지 UI 구성" -
원격 저장소에 브랜치 push
git push origin feature/signupPage -
PR 생성 (ex. Feat: 회원가입 페이지 UI 구성 (Closes #12))
-
코드 리뷰 및 develop 브랜치에 merge
-
PR merge 시 이슈 #12 자동 종료
- 모든 작업은 반드시 이슈를 통해 관리한다.
- 브랜치 이름에 이슈 번호를 포함하여 추적 가능성을 높인다.
- PR 생성 시 반드시 관련 이슈를 연결한다.
- 여러 작업을 한 이슈/브랜치에 몰아서 처리하지 않는다.
- 작업 단위별로 이슈와 브랜치를 분리할 것.
✅
- 배포 버전을 명확하게 기록하기 위해
- 코드 변경 히스토리를 버전별로 추적하기 위해
- 이전 버전으로 쉽게 롤백하기 위해
- 보통 SemVer;시맨틱 버전을 따름
- 예시:
-
v1.0.0: 첫 정식 릴리스 -
v1.1.0: 기능 추가 -
v1.1.1: 버그 수정
-
v<주버전>.<부버전>.<패치버전>
git tag -a v1.0.0 -m "배포 버전 1.0.0"git checkout main
git pull origin main
# develop 병합
git merge develop
# 태그 생성
git tag -a v1.0.0 -m "배포 버전 1.0.0"
# 브랜치+태그 푸시
git push origin main --tags
# 태그만 푸시할 경우
git push origin --tags