구글링 후 개인적인 견해로 작성해 본 것입니다.

깃 컨벤션

메시지 구조

• 보통 제목(Subject), 본문(body), 꼬리말(Footer) 3가지 파트로 나누고 각 파트는 빈줄로 두어서 구분함

규칙

• Subject : 최대 50글자 넘지 않도록 하고 마침표 찍지 않음 (영문으로 표기하는 경우 동사(원형)을 가장 앞에 두고 첫 글자는 대문자로 표기함
• Body : 긴 설명이 필요한 경우에 작성함 (어떻게 했는지가 아니라, 무엇을 왜 했는지를 작성함, 최대 75자를 넘기지 않도록 함)
• Footer : 이슈 ID를 명시하는 경우에 작성하는 것 같은데 사실 Footer는 필요 없어 보인다.(안 사용해도 될 것 같다고 생각합니다.)

결론
→ Subject에서 단번에 인식 가능하도록 메시지를 작성하도록 하되, 설명이 부족하다 느끼면 Body에서 무엇을 왜 했는지 작성하자.

EX)
type(옵션): Subject
(한 줄을 띄워 분리합니다.)
body: 본문

제목(Subject) 작성법

태그 이름	설명
Feat	새로운 기능을 추가할 경우
Fix	버그를 고친 경우
Style	코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
Refactor	코드 리팩토링
Comment	필요한 주석 추가 및 변경
Docs	문서를 수정한 경우
Test	테스트 추가, 테스트 리팩토링
Chore	빌드 테스트 업데이트, 패키지 매니저를 설정하는 경우 - (Gradle 설정)
Rename	파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
Remove	파일 혹은 폴더를 삭제하는 작업만 수행한 경우

• 개인적으로 영어 보다는 한글이 더 직관적이게 느낄 수 있다고 생각이 듭니다.
• 따라서 “구현”, “추가”, “변경”, “수정” 등의 명령조로 마무리를 지어도 좋을 것 같습니다.
• EX) Feat: “get data api 함수 추가”

깃 브랜치 전략

• Git Flow는 Vincent Driessen이 그의 블로그에 2010년에 올린 A successful Git branching model 이라는 글이 인기를 끌며 대중적으로 사용되게된 브랜치 전략이다.
• 2020년에 해당 포스팅 위에 웹 애플리케이션의 경우 일반적으로 롤백되지 않고, 지속적으로 제공되므로 여러 버전의 소포트웨어를 지원할 필요가 없다. → Github Flow 같은 더 단순한 워크플로우를 채택하면 좋다,라고 반성의 글을 작성함
• 현재 우리는 앱 서버이고 배포 후 cloud 서비스에서도 버전 관리할 예정이기에 기존의 Git Flow를 채택하는 것이 좋아보입니다.

Git Flow

Branch

• Master 브랜치
• Develop 브랜치
• Supporting 브랜치
  • Feature 브랜치
  • Release 브랜치
  • Hotfix 브랜치

→ Master 브랜치와 Develop 브랜치 : 개발 프로세스 전반에 걸쳐 항상 유지되는 브랜치
Supporting 브랜치 : 필요할 때마다 생성되고, 역할을 다하면 삭제 됨

Master 브랜치

• 출시 가능한 프로덕션 코드를 모아두는 브랜치
• 프로젝트 시작 시 생성되며, 개발 프로세스 전반에 걸쳐 유지됨
• 배포된 각 버전을 Tag를 이용해 표시함

Develop 브랜치

• 다음 버전 개발을 위한 코드를 모아두는 브랜치
• Main 브랜치에서 처음 생성
• 개발이 완료되면 Main 브랜치로 머지됨
  • Squash And Merge

Release 브랜치

• 소프트웨어 배포를 준비하기 위한 브랜치
• Develop 브랜치에서 생성하며, 소소한 데이터를 수정 및 배포전 사소한 버그를 수정하기 위해 사용
• 배포 준비가 완료되었다면 Main 과 Develop 브랜치에 둘 다 머지 함 → Main 브랜치에는 태그를 이용하여 버전을 표시
  • Develop에 머지할 때 : merge
  • Main에 머지할 때 : Squash And Merge
• 네이밍 예) releas/v1.1

Hotfix 브랜치

• 이미 배포된 버전에 문제가 발생했다면, Hotfix 브랜치를 사용하여 문제 해결
• Main 브랜치에서 생성 → 문제 해결이 완료되면 Main과 Develop 브랜치에 둘 다 머지
  • Develop에 머지할 때 : merge
  • Main에 머지할 때 : Squash And Merge
• Release에는 머지 X
• 네이밍 예) hotfix/1.1.1

Feature 브랜치

• 하나의 기능을 개발하기 위한 브랜치
• Develop 브랜치에서 생성하며, 기능이 개발 완료되면 다시 Develop 브랜치로 머지 됨
  • Develop에 Merge 할 때는 Squash And Merge로 PR을 생성함
• Merge Commit을 생성하여 머지를 해줘야 함

프론트랑 연동할 때는 develop 브랜치가 좋을려나..?

참고

A successful Git branching model

Git 브랜치 전략 (feat. Git Flow, Github Flow)