Git, Github, GitLab 브랜치 전략에 대해 정리한다.
개인 Github를 관리하면서 master에 커밋하는 정도록 git을 사용하기 시작했다. 그리고 취업후 처음으로 진행했던 웹 사이드 프로젝트에서 Git flow/Pull Request 를 사용하게 되었고 현재 진행중인 앱 사이드프로젝트에서 SHIP/SHOW/ASK 를 알게되었다.
실무에서는 git을 사용하지 않고 있었기때문에 스스로 git flow가 git를 사용하면 보편적으로 사용하는 방식으로 인식하고 있었는데, 최근 업무중에도 git을 사용하면서 프로젝트별 특성에 따라 다양한 방식으로 브랜치 전략을 가져가야 한다는 생각을 하게 되었다.
Git Flow
- Main 출시 가능 브랜치
- Develop 개발 브랜치
- Feature, Release, HotFix 역할별 브랜치
하나의 기능이 개발되면 Feature 브랜치에 커밋을 하고 Develop 브랜치에 머지한다. 개발이 완료되면 Develop 브랜체에서 Main 브랜치에 커밋된다.
배포를 위해 Release 브랜치를 생성하고, QA 중 발생한 문제들을 Release 브랜치에 커밋하고 테스트 완료후, 각각 Main, Develop 브랜치에 머지한다.
배포된 서비스에 문제가 생기면 HotFix 브랜치를 생성하여 해결한다.
Git Flow는 보편적으로 사용되고 있지만, 웹서비스보다 앱서비스에 적절한 전략이다. 앱서비스는 버전별로 배포가 되지만, 웹 서비스는 수시로 배포가능하기 때문이다.
Github Flow
- 트렁크 기반 개발의 일종
- Main 언제 배포하든 문제가 없어야 한다. 모든 커밋은 빌드가 되고, 테스트에 통과해야한다.
- Feature 기능개발, 버그 수정 모두 진행한다. 기능이 완성되지 않아도 Push한다. 개발하던 중 PR를 생성해 토론하고, 코드리뷰를 한다.
- 리뷰가 끝나고 승인이 되면, Main에 Topic 브랜치가 머지된다.
- Feature 브랜치는 자동화된 CI빌드를 통과해야 한다.
소규모 애자일 팀, 단일 릴리즈 버전이 존재하는 제품, 웹 서비스에 적절하고, 하루에 변경 사항을 빠르고 빈번하게 병합/배포할수 있는 구조이다.
GitLab Flow
- Production gitflow의 Main과 같은 역할. 배포만 담당한다.
- Main 브랜치는 Production으로 머지 된다.
- pre-production Production으로 가기 전에 테스트를 진행한다.
- 권한이 있는 사람만 Main에서 Production으로 병합이 가능하다.
- 개발자가 Merge Request를 올리면 권한있는 사람과 리뷰를 진행한다.
현재 실무에서 GitLab를 사용하고 있다. 현재 브랜치 생성의 경우, 각 개발자마다 브랜치를 가지고, develop에 병합하는 방식으로 진행하고 있다. 병합후 브랜치는 삭제하지 않고, develop 브랜치 코드를 pull해서 한 브랜치를 계속 사용하는 방식이다.
처음에는 이 방법이 생소하고 브랜치를 삭제하지 않고 계속 사용해도 괜찮은 것인지 의문이 들었지만, 일정이 급하고 코드 품질보다 진척률이 중요한 프로젝트에서는 적절한 방식처럼 느껴졌다.
웹과 앱, 프로젝트 특성에 따라 다양한 브랜치 전략을 가져갈수 있다.
다양한 브랜치 전략을 확인하면서, 조금씩 그 특성에 맞게 적용해봐야 한다.
출처:
https://hudi.blog/git-branch-strategy/
https://tech.mfort.co.kr/blog/2022-08-05-trunk-based-development/
