Git 브랜치 전략

팀 단위 프로젝트에서, 본인이 개발한 기능이 아닌 경우 추적이 힘든 경우가 잦다.
다른 팀원이 무엇을 개발하는지, 진행 상황은 어떤지, 코드는 어떻게 작성하고 있는지 확인하기 위해,
우리 팀은 issue 기반 git 브랜치 전략을 사용하기로 하였다.

git flow 방식을 기반으로,
master -> develop -> feat/{파트}/{프로젝트명}-{이슈번호}
형식으로 컨벤션을 정의하였다.

순서대로 따라가보자.

1.

template을 만들기 위한 .gitlab 디렉토리를 생성한다.

2.

issue 템플릿과 merge request(pull request) 템플릿을 만들 것이다.
각각의 디렉토리를 생성하자.

3.

간략하게, 이와 같이 템플릿을 작성한다.

4.

merge request 시, close #이슈번호 입력을 통해 연결된 issue를 자동 closed 시켜줄 것이다.

📌중요! 해당 기능은 mr의 대상이 되는 브랜치가 default branch여야만 동작한다.

5.

issue에 등록했던 일을 끝내어 커밋을 할 때마다, 템플릿에 따라 생성된 체크박스를 체크하자.

6.

📌중요! issue 트래커를 commit 메시지 말미에 반드시 붙이도록 하자.

예를 들어, 5번 단계의 사진 최상단을 보면 issue 번호가 2번임을 알 수 있다.
커밋 메시지 말미에 #2를 붙인 뒤 커밋을 하면, mention되었음을 알리며 해당 commit 로그가 찍힌다.
당연히, 파란색 부분을 누르면 코드가 변경된 부분을 확인할 수 있다.

7.

이제 issue에 할당한 기능의 개발이 끝났으니, mr을 통해 브랜치를 병합하자.
4번 단계에서 템플릿을 설명할 때 언급했던 것을 기억하는가?

위 사진의 close #2는, merged 됨과 동시에 issue를 자동으로 close해준다.
물론, 상기한 주의사항을 잊으면 곤란하다.
자동 issue close는 반드시 mr의 대상이 되는 브랜치가 default branch여야만 동작한다.