[GIT] 브랜치 전략 및 커밋 컨벤션

Git 브랜치 전략

브랜치명	설명	예시
main	운영 환경	main
develop	개발 환경 main에서 나와서 main으로 Squash&Merge	develop
feat/#{이슈번호}	이슈 단위 기능 개발 브랜치 develop에서 나와서 develop으로 Rebase&Merge	feat/#12
hotfix/#{이슈번호}	긴급 수정 브랜치로 main 과 develop 둘 다 PR을 보낸다. main에서 나와서 main으로 Squash&Merge	hotfix/#12

Git 브랜치 합병(merge)

feat/#{이슈번호} → develop : Rebase And Merge
develop → main : Squash And Merge

• local에서 remote에 PR 날리기 전에 develop 브랜치 rebase 한 번하기
  • local의 develop 브랜치에서 pull → local의 feat 브랜치에서 git rebase develop
• [feat → develop] PR을 merge할 때 rebase and merge
• PR에서 conflict났을 때 local에서 develop 브랜치 rebase해서 충돌 해결하고 push
• [develop → main] PR을 merge할 때 squash and merge

Git 커밋 메시지 컨벤션

타입	설명
feat	새로운 기능 구현
fix	버그 수정 (기능을 잘못 구현한 경우)
refactor	코드 리팩토링 (기능은 그대로인데, 코드 개선, 폴더 변경, 변수명/함수명 수정)
build	build.gradle, package.json와 같은 의존성 설정 파일
docs	문서 작업
chore	.gitignore, yml, eslint, prettier와 같은 설정 파일
test	테스트코드"만" 추가, 수정했을 때
style	주석 수정, 사용하지 않는 import 제거나 순서 변경, 개행 관련
design	css와 같은 스타일링
init	프로젝트 첫 세팅

build, chore 구분 이유: 의존성 추가 같은 주요 변동 사항은 따로 구분해서 표시하기로 결정

롤백 대응

• revert를 통해 문제되는 커밋을 되돌린다.
  • reset은 해당 커밋이 삭제되어 트래킹이 안되고 force push 해야 하는 위험성이 있어 revert를 사용한다.