티스토리 뷰
제대로 된 협업을 처음 해보는 쌉초보 개발자입니당 ㅎㅎ
사실 만 1년차였던 작년에는 규모가 상대적으로 작은 프로젝트만 했었다보니
체계적으로 깃을 써본 적이 없었는데
이번 프로젝트의 라이브러리 작업을 하면서
처음으로 릴리즈를 연달아 세 번이나 해봄 ㅎㅎ
미래의 내가 잊어버릴 것을 대비해서 정리를 해보자면 (이 방법이 공통된 컨벤션인지는 잘 모르겠음.. ㅎㅎ)
- 개발은 각자의 feature 브랜치에서 한다.
- 피쳐 브랜치 네이밍 컨벤션은 feature/개발자의 이니셜/브랜치 이름 (나의 경우 feature/kk/어쩌구저쩌구)
- maven local로 publish하고 작업을 했었다면, 버전넘버를 기존 버전으로 다시 되돌린다.
- 작업이 끝난 피쳐 브랜치에서 Pull Request를 열어 develop 브랜치로 merge한다.
- 처음 PR을 생성할 땐 리뷰어를 추가하지 않고 오픈한다. (병합 충돌이 없는지, 파이프라인을 통과하는지 확인 후에 리뷰어를 추가)
- 최소 2명의 리뷰어들의 승인을 받아야 PR을 완료할 수 있다. (작업자 본인이 직접 자기 브랜치를 develop으로 merge하면 안됨)
- develop 브랜치로 merge가 완료되었다면 develop에서 release 브랜치를 만든다.
- 릴리즈 브랜치 네이밍 컨벤션은 release/새로운 버전 넘버 (예를 들어 기존 프로젝트 버전이 0.4.0이었다면, release/0.4.1)
- 일반적으로 릴리즈 브랜치는 생성한 사람이 처음부터 끝까지 모두 컨트롤한다.
- 릴리즈 브랜치에서 버전 넘버를 올린 뒤 푸쉬를 하고, release에서 master로의 merge를 위한 PR을 오픈한다.
- develop 때와 마찬가지로 2명 이상의 리뷰어가 승인해야 PR을 완료할 수 있다.
- PR 완료 후 release에서 develop으로 다시 PR을 오픈한다. (버전넘버를 릴리즈에서 올렸으니 develop과 master가 서로 다르므로)
- 마찬가지로 2명 이상의 리뷰어에게 승인을 받아야한다.
- release에서 develop으로의 merge가 끝나고나면 release 브랜치는 없애버린다.
결국 릴리즈 한 번에 총 3번의 PR을 열게되는 셈이에요.
1. feature → develop
2. release → master
3. release → develop
마스터 브랜치로 merge하는 게 이번이 처음이었어서
굉장히 떨리고 두근두근했음!! ㅎㅎ
그리고 리뷰어가 되어주셨던 시니어 개발자분들은
제가 쓴 코드를 찬찬히 살펴보시고
문제가 없다고 생각하시면 바로 승인을 해주시거나,
수정할 부분이 있으면 해당 라인의 코드를 콕 찝어서 이 부분은 어떻게 수정하면 되겠다 라는 코멘트를 남길 수 있고
내가 남긴 이 코멘트 부분만 네가 수정한다면 나는 이 merge 찬성일세!!
이렇게 조건부 승인을 해줄 수도 있었어요.
프로젝트가 파이프라인을 통과하는지
2명의 리뷰어에게 승인을 받았는지 (조건부였다면 해당 부분이 해결되었는지)
merge conflict가 없는지
이렇게 세 가지 섹션에서 모두 체크마크가 뜨면 PR을 완료할 수 있게 버튼이 활성화되더라고요.
신기방기쓰-