git flow 자세히 알아보자

원칙

• master 브랜치는 항상 배포가능한 상태여야 한다.
• 새로운 프로젝트는 master 브랜치에서 분기된 브랜치에서 진행.
• 로컬에 commit 한 내역은 주기적으로, 최대한 자주 원격 저장소에 push.
• 코드를 병합할 준비가 되었으면 PR.
• 1인 이상의 리뷰어가 승인을 하면 master에 병합.
• 병합된 브랜치는 1번 원칙에 따라 즉시 배포.

브랜치 종류

• master(master_itg) : 항상 배포 가능한 상태

• feature

• hotfix
  

• release
  - 웹 어플리케이션에서는 운영하지 않음.
  - open api, mobile application 등 버전 관리가 필요한 경우에만 운영.
  

네이밍 방식

• {접두사-메인브랜치}/{브랜치명}
• 기능을 간단하게 나타내기
  • feature/mainpage-card-section
  • feature/campaign-rolling-banner
  • hotfix/admin-user-repayments

Merge 방식

• master branch에 merge 할 때는 Squash and merge 방식을 사용
  - (on master branch) git merge —squash
  - (on feature branch) git rebase -i
• master branch가 아닌 브랜치에 merge 할 때에는 Rebase and merge 방식을 사용.
  • feature, hotfix 등 브랜치는 commit 내역의 변경사항을 자세하게 추적하기 위해 유일한 history 상 모든 commit을 유지한다.

커밋 메세지

• commit message 제목에는 타입을 명시
  • (예시) fix: fix foo to enable bar
  • feature : 새로운 기능을 반영했을 때
  • fix : hotfix, bugfix 등 버그를 수정했을 때
  • refactor : 기존 기능 refactoring 작업을 했을 때(쿼리 최적화, 클래스명 변경 등)
  • docs : 문서를 추가했을 때
  • style : 코드 스타일을 변경했을 때
  • test : 테스트 코드를 추가했을 때
  • ops : devops 관련 기능을 추가했을 때
  • remove : 파일 또는 패키지를 삭제했을 때
• commit message body는 맥락을 모르는 개발자도 이해할 수 있게끔 반영된 내용을 서술한다.
• (선택) commit message footer는 관련된 notion ticket id를 명시.
  • 스프린트/스크럼 진행사항과 개발 사항을 추적하기 위함.

참고자료

https://nvie.com/posts/a-successful-git-branching-model/
https://githubflow.github.io/