처음 프로젝트를 시작했을 땐 branch 관리나 커밋관리 모두 제대로 이루어진 것이 없었다. 그러다보니 어떻게 관리해야 하는지 알지 못해 늘 제멋대로 사용했는데, 최근 다른 분들과 프로젝트를 진행하면서 branch, Commit Convention 등등 GitHub 관리법에 대해서 공부하게 됐다. 그때 사용했던 방법을 좀 정리해봤다.
GitHub 메뉴
git에는 다음과 같은 메뉴들이 존재한다. 여기서 내가 주로 사용해본 기능은 Code, Issues, Pull requests 이다.
code에는 말 그대로 작성한 코드들이 들어가고, branch가 존재하는 공간이다.
issues에는 프로젝트의 작업을 작성하는 곳이다. 모든 작업을 이슈로 만들고 등록한 이슈를 기반으로 프로젝트를 관리한다. 이슈를 등록하면 이슈 번호가 생긴다.
Pull requests는 작업 브랜치의 내용을 main 브랜치에 병합하기 전 다른 참가자들과 공유하고 리뷰를 요청할 수 있는 메뉴다. 리뷰가 끝난 코드는 병합하여 다른 참가자들 또한 내려받을 수 있다.
Git Branch
branch는 각각의 저장공간, 폴더같은 개념이라고 생각하면 된다. 모두가 한 공간을 공유하면 각자 작업한 내용들이 충돌될 수도 있기 때문에 branch를 나누는 것이 매우 중요하다.
변수명을 작성할 때 암묵적으로 정해진 규칙이 있는 것처럼, branch에도 어느정도 통용되는 규칙이 있다.
모범예시
Main(Master)
배포할 수 있는 브랜치.
즉 최종적인 상태를 의미하는 공간으로 최상위 브랜치다.
Develop
다음 출시 버전을 개발하는 브랜치.
main에서 분기되어 기능 개발을 위한 브랜치들의 병합을 위해 사용된다. 이 브랜치에서 기능을 병합하고 버그를 수정하여 배포 가능한 상태가 되면 main으로 병합한다.
Feature
기능을 개발하는 브랜치.
새로운 기능이나 버그 수정이 필요할 때마다 develop 브랜치에서 분기된다. 여기서의 작업은 공유할 필요가 없기 때문에 주로 자신의 로컬 저장소에서 관리한다.
명명규칙: feature/기능요약 (ex. feature.login-page)
Release
이번 출시 버전을 준비하는 브랜치.
feature 브랜치에서 기능 개발 후 develop 브랜치에서 병합을 하는 과정을 반복하여, 최종적인 버그 수정이나 문서 추가 등 실질적으로 release하기 직전에 하는 단계를 위한 브랜치
명명규칙: release/X.X.X or release-X.X.X
Hotfix
출시 버전에서 발생한 버그를 수정하는 브랜치.
갑작스럽게 수정해야하는 경우에 main에서 수정하지 않고 Hotfix 브랜치로 분기하고 수정 후 main으로 병합한다. main에서 다시 배포 후에는 develop 브랜치에도 병합해준다.
물론 나는 아직까지 위의 브랜치들을 모두 사용해보진 않았다. 적당히 master, develop, feature 이 정도의 브랜치만을 사용해봤다. ㅎㅎ
+) 추가로, 기능 브랜치를 작성할 때 이슈번호를 붙이기도 한다. 이슈와 함께 브랜치를 쉽게 관리하기 위해서이다. ex. feat#[11]/login-page
