git-flow를 사용하는 나를 되돌아본다.
feature branch에만 박혀서 기능을 생산하고 upstream에 변경사항이 있을 때, 잠깐잠깐 main branch로 왔다갔다하는 모습은 마치 나의 모습과 닮아있었다.
우아한 형제들의 git-flow 전략에서 feature branch는 JIRA와 연동하여 Ticket 단위로 commit, branch를 처리한다는 글은 나의 가치관을 흔들어놨다.
"앗...! feature는 커밋이 끝나면 사라잘 수도 있구나..."
물론, 절대적인 방식은 정해져있지 않겠지만, 나의 방식에 의문점을 가지고 있던 시점에서 git branch 관리 전략에 대해 더 고민할 유인을 제공하기엔 충분했다.
마침, 사부님과 간단한 프로젝트를 할 기회가 생겨서 git branch convention을 여쭤보았고 새로운 방식을 알게 되었다.
사부님 : 펭구스님! 현재 제가 속한 팀에선 아래와 같은 컨벤션을 사용합니다!
git checkout -b feature/{이름}/{작업할 내용}
예를들어, BE에서 넘어오는 사진(PinCard)을 렌더링할 Board를 제작하는 경우, 아래와 같은 branch를 생성한다는 뜻이다.
git checkout -b feature/pengooseDev/pinBoard
프로젝트 적용
- 기능명세서 작성
- 기능명세서 하나당 하나의 Jira Ticket 생성
- ticket 할당
- ticket의 state를 in progress로 변경!
- branch 생성
- 구현(commit / push)
- PR 생성
- 코드리뷰 (PR이 close될 경우, 다시 6번으로!)
- merge
- branch 삭제
- ticket state를 Done으로 변경!
새롭게 배운 내용들을 토대로 위의 프로세스를 이번 프로젝트에 적용시켜보아야겠다!! 🥳
