깃허브를 사용한 경험이 다들 많아서, 깃컨벤션 메시지가 이전 프로젝트보다 더 많아졌다. 깃 컨벤션 메시지를 지켜서 작성하면, 이후에 누가 어떤 작업을 했는지 확인할 수 있고, 불가피하게, 깃 커밋을 특정 버전으로 돌려야할때도 한번에 찾아서 돌릴 수 있어 좋다.
저번 프로젝트때, 머지하면서, 필요한 코드를 지워버리고, 거기다가 계속 작업을 하다가, 문제가 생기면서 코드를 돌린적이 있었는데, 커밋 메시지 찾아서, 그때 버전으로 돌려 사용하면 되서 편했다.
이번 토이프로젝트에서는 git flow 전략을 사용하기로 했다.
❓ 왜 깃플로우를 사용하는게 더 좋을까?
이번 프로젝트는 빠르게 배포하고, 추가 기능같은 경우, 버전을 나누어 배포하자는 생각을 가지고 있기 때문에, 주기적인 배포, 테스트, hotflix를 수행한다면 gitflow가 더 좋다고 생각했다.
Feat : 새로운 기능을 추가할 경우
Fix : 버그를 고친 경우
Hotfix : 급하게 치명적인 버그를 고쳐야하는 경우
Design : CSS 등 사용자 UI 디자인 변경
Style : 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
Modify : 단순한 코드 수정
Delete : 삭제한 코드 설명
Remove : 파일을 삭제하는 작업만 수행한 경우
Comment: 필요한 주석 추가 및 변경
Docs : 문서를 수정한 경우
Test : 테스트 추가, 테스트 리팩토링(프로덕션 코드 변경 X)
Chore : 빌드 태스트 업데이트, 패키지 매니저를 설정하는 경우(프로덕션 코드 변경 X)
Refactor : 코드 리팩토링 경우
Rename : 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
Merge : to ← from (#1)
Merge : 변경된 내용 작성
Tag : 커밋 내용에 대한 설명
커밋 내용에 대한 설명은 간결하면서도 그 설명만 보고도 어떠한 커밋인지 추측할 수 있을 정도로 작성