2. 파트 정하기 및 GIT 브랜치 전략

HUNI·2023년 12월 24일

업무 분담

여러 기능을 병렬적으로 처리하기 위해서는 업무 분담이 필요하다.
나는 USER(회원가입, 로그인)와 BOOKMARK(좋아요 기능) 부분을 맡았고, 팀장님은 POST, CLOTHES, COMMENT(댓글) 부분을 맡았다.


분담한 부분은 API 명세서 첫페이지에 명시해놓았다.


GIT 브랜치 전략

GIT main 브랜치만 사용해 프로젝트를 하면 어떤 상황이 벌어질까. 개인 프로젝트라면 문제 없을 것이다. 이상한 commit 이라도 나만 알아볼 수 있으면 해당 commit 지점으로 롤백할 수 있으니까. 하지만 협업이면 얘기가 달라진다. 여러 기능을 동시에 main 브랜치에서 작업이 이루어지므로 commit 이 뒤죽박죽 될 것이다. 롤백하지 못하면 COMMIT은 의미없는 행위이다.


브랜치 기능이 이 문제를 해결할 수 있다. 브랜치를 통해 독립적인 환경에서 기능을 개발하거나 버그를 수정할 수 있다. 즉, 여러 기능을 여러 개발자가 병렬적으로 처리할 수 있는 것이다.


GIT 브랜치 적용

우리는 GIT 브랜치를 main 과 dev 로 나누었다. 이후, 원하는 기능을 ISSUE로 발행하면 GITHUB에서는 ISSUE 고유번호를 주는데, 그 번호를 브랜치 이름으로 이용했다.

예시) 로그인 기능 ISSUE #9 => dev 브랜치에서 ISSUE-9 브랜치를 새로 만든다.

하지만 구글링을 해 본 결과 ISSUE-(번호) 로 브랜치 이름을 짓는 사례는 드물었다. 주로 feature/{기능} 으로 브랜치를 생성하더라..
ex) feature/backend/donghun/JwtClient


** GIT 브랜치 기능을 효율적으로 관리하기 위해 나온 전략들이 있다. 대표적인 사례로 GIT FLOW, GITHUB FLOW 가 있다.

GIT COMMIT CONVENTION

협업 프로젝트를 할 때 내 마음대로 커밋 메시지를 지을 수는 없다. 커밋 메시지를 정해서 서로의 커밋을 쉽게 확인할 수 있도록 한다.
우리는 AngularJs Commit convention 을 이용했다.

항상 기능 단위로 commit 해야되는 것을 잊지말자!
기능 추가, 버그 수정 은 분리되어야 하는 commit이다.




참고사이트

https://hudi.blog/git-branch-strategy/

profile
어려운 문제에 대해 고민하고 분석하는 과정을 좋아합니다.

0개의 댓글