고민
- kakao.ai를 인수인계 받은 후 처음 보는 git 운용법에 익숙해지는 것이 늦었음.
- 너무 잦은 기획/디자인 변경과 상시 배포에 혼란을 겪음
- 인수인계자의 방법을 연구해 나름의 컨벤션을 재정립하기로 함
커밋 컨벤션
[update] - : 기획적 목적에서의 배포를 위한 기능 구현 커밋
[test] - : 개발적 측면에서의 테스트용 커밋
[delete] - : directory 삭제
[fix] - : freezing 된 코드에 대한 커밋
[hotfix] - : 버그 수정을 위한 긴급 배포용 커밋
배포 방식
배포예정 월일 기준으로 브랜치를 만듦 : update_MM_DD_release 와 같은 네이밍 컨벤션 사용.
update_MM_DD_release 브랜치는 develop 브랜치에서 나와 develop 브랜치로 들어간다.
update_MM_DD_release 에서 개발이 끝나면 기획자 검수를 위해 해당 브랜치 기준으로 개발 서버에 배포.
1차 QA후 무한 [update] 반복… [fix] 된 코드를 develop에 머지하고 최종 QA
최종 QA 후 develop의 코드를 master에 머지 하고 스테이지 서버에 배포
실배포 이후 [hotfix] 발생시 master에서 [hotfix] 브랜치를 따서 수정 후 master, develop에 머지
코드 히스토리를 찾아야 할 떄는
- 해당 배포 년월일의 브랜치로 이동한다.
- 커밋 컨벤션을 참고하면서 목적에 맞는 로그를 찾는다.
- [fix] 커밋만 골라서 보면 더 빠르게 히스토리 정리가 가능하다.
추후 계획
- 리액트 코드리뷰 전략이 짜여지면 pull request를 이용한 방식을 차용할 생각
- 피드백이 필요한 코드가 있거나 머지 직전인 경우 pull request를 열어 코드리뷰를 받는다.
- 현재 프로젝트 상황처럼 hotfix가 잦거나 디자인 변경같은 버그 가능성이 낮은 배포가 잦으면 pull request를 강제하는 것이 좋지 않을 것.
-> 필요한 상황에서만이나 주기적으로 코드리뷰를 받도록 규칙을 정해야 한다.