[Git] Git Branch 전략

Git Branch 전략에 대하여 공부한 내용을 공유하려 합니다. 개인적으로 최근까지 Git-Flow의 브랜치 전략만이 표준이며 꼭 따라야 한다는 고정 관념이 있었습니다. 실제 프로젝트를 진행함에 있어 상황에 맞게 조금씩 변형하며 개발을 했었으나 그 기준은 Git-Flow였습니다. 

 

2010년  nvie라는 닉네임을 가진 개발자가 Git-Flow 전략을 세웠는데, 아래 글은 2020년에 그가 발표한 글입니다.

따라서, Git Branch 전략은 완벽한 정답이 없으며 상황에 맞게 선택/변형하여 적용하면 될 것으로 생각됩니다. 

 

1. Git-Flow

git-flow는 버전관리가 필요한 앱, 솔루션 등의 적합한 워크플로우입니다. 

가장 널리 알려진 브랜치전략으로, 타 브랜치전략에 비해 러닝커브가 높습니다. 기본적으로 master 브랜치가 최종 배포 브랜치가 되며, 신규 개발 건은 develop 브랜치에서 각 기능별 소단위의 feature 브랜치에서 개발 후 다시 develop 브랜치로 merge합니다. 이후 배포할 커밋들을 release 브랜치에서 검증 후 master 브랜치로 merge하여 배포합니다. 배포 후 급히 수정될 이슈는 master에서 hotfix 브랜치를 생성하여 수정 후 배포하며, develop은 최신 상태를 유지합니다.

 

2. Github-Flow

Git 브랜치 전략 중 가장 간단한 워크플로우 이며, 버전관리가 필요없으며 수시로 자동배포 되는 웹 어플리케이션 서비스에 적합합니다. 

Master(main) 브랜치로 push한다면 즉시 배포되는 최종 브랜치이며, 그 외 브랜치는 hotfix, feature, develop등의 구분이 없습니다. 따라서 Master에서 개발/수정 목적으로 브랜치를 생성한다면 그 용도와 목적에 맞게 브랜치명을 명확히 해야 합니다. 또한 피드백이 필요한 경우 Master에 merge하기 전에 Pull Request를 생성하여 팀원에게 리뷰를 받고 완료 되었을 때 merge를 진행합니다. 

 

3. GitLab-Flow

GitLab-Flow는 Github-Flow를 기반으로 릴리즈 버전과 Master의 분리 운영이 필요한 경우, 배포 기간에 따른 통합이슈 등의 상황 대응하기 위한 워크플로우입니다.

개발/수정 이슈발생 시 Master를 기준으로 브랜치를 생성하는 것은 Github-Flow와 동일하지만 Production 배포 전 1차적으로 Pre-Production(Stage)를 생성하여 QA 이후 Production으로 최종 배포합니다. 

 

 

PS. 세가지 브랜치 전략에 대하여 간단히 설명하였습니다. 중요한 것은 이 방법들은 무조건적인 정답이 아니며, 현재 개발 중인 환경과 상황에 맞게 각 브랜치 전략들을 참고하여 전략을 세우는 것이 중요합니다. 

 

 

참고사이트
https://brownbears.tistory.com/603

https://blog.hwahae.co.kr/all/tech/tech-tech/9507

https://brownbears.tistory.com/605

https://community.intersystems.com/post/continuous-delivery-your-intersystems-solution-using-gitlab-part-i-git