Git 브랜치 전략 및 커밋 메시지 규칙 #19

Closed JuyeoungJun closed 3 years ago

In GitLab by @gm2202981 on May 27, 2021, 11:38

기본 구조

git flow란?
- develop 브랜치에서 개발을 진행하고 master 브랜치에서 배포
- 개별 기능(feature) 브랜치로 분기하여 기능별 개발 진행
- 개발된 기능은 develop에 merge
- 배포 과정에서 발생한 버그는 hotfix 브랜치에서 수정하여 develop에 merge
- release 브랜치에서 배포 전 최종적으로 버그를 수정하고 master 브랜치에서 배포.
장점
- 오랫동안 쓰여온 잘 정의된 표준.
단점
- default값이 main인 기본 브랜치를 develop으로 변경해야 하는 수고(?)
- hotfix 및 release 브랜치까지 나누는 건 조직에 따라 지나치게 과도할 수 있으며, 지속적 배포(CD)에 어울리지 않음
본 프로젝트에선 기본적인 git flow 구조를 따르되 release 브랜치는 생략하고 master 브랜치에서 바로 배포
fix 브랜치에서 버그 수정

브랜치 작명 규칙

feature 브랜치명 : feature/기능
fix 브랜치명 : fix/issue_번호

참고자료

커밋 메시지 규칙

제목은 50자를 넘기지 않고, 마침표를 넣지 않는다
과거 시제를 사용하지 않고, 명령어로 작성
구조
```
타입: 제목
```

본문(optional!)

꼬리말(optional!)

    - 타입엔 하단에 정리해둔 메시지 타입 중 하나를 선택하여 입력
    - 제목엔 해당 변경사항을 간략히 정리하여 작성
    - 본문은 선택사항. 제목 외에 추가적으로 정보를 전달하고 싶을 경우 작성.
    - 꼬리말 또한 선택사항이며, 연관된 이슈 ID를 입력

- 메시지 타입

feat : 새로운 기능에 대한 커밋 fix : 버그 수정에 대한 커밋 chore : 그 외 자잘한 수정에 대한 커밋 ci : CI관련 설정 수정에 대한 커밋 docs : 문서 수정에 대한 커밋 style : 코드 스타일 혹은 포맷 등에 관한 커밋 refactor : 코드 리팩토링에 대한 커밋 test : 테스트 코드 수정에 대한 커밋


- 커밋 메시지 예시:

docs: API 문서 수정

2021.05.27 사용자 시나리오 및 DB 설계에 따른 API 상세 스펙 문서화

Resolves: #15 See also: #13, #16



## 참고자료
- https://webruden.tistory.com/486

In GitLab by @gm2202981 on May 27, 2021, 11:41

changed the description

In GitLab by @gm2202981 on May 27, 2021, 13:24

changed the description

In GitLab by @gm2202981 on May 27, 2021, 13:25

changed the description

In GitLab by @gm2202981 on Jun 4, 2021, 10:47

changed the description

JuyeoungJun / cron-monitoring