회사 git을 분석하는데 있어 git branch 전략으로 git-flow를 사용하는 것을 알 수 있었다
Git Branch 전략
Git Branch 전략이란 프로젝트에서 git을 운영하는 과정에서 프로젝트 입장에서 보다 효율적인 코드 및 형상 관리를 위해 전략적으로 브랜치를 이용하는 것을 말한다.
간단하게 프로젝트의 상황과 목적에 맞춰 개발 소스를 관리하는 전략적인 방법
종류
Branch 전략으로는 gitflow``', github flow, gitlab flow``` 등이 존재하고 각 전략에 대해 간략하게 설명 후에 회사 프로젝트와 비교하며 진행할 예정이다.
Git-flow
master : 기준이 되는 브랜치로 제품 배포하는 브랜치
develop : 개발 브랜치, 각자 작업한 기능 Merge하는 브랜치
feature : 단위 기능 개발 브랜치로 develop에 Merge되는 브랜치
release : 배포를 위해 master 브랜치로 보내기 전에 먼저 QA(품질검사) 위한 브랜치
hotfix : master 브랜치로 배포를 했는데 버그가 생겼을 때 긴급 수정하는 브랜치
GitHub-flow
Git-flow가 복잡하다 느껴 이를 간략화 시킨 브랜치 전략
hotfix, feature 구분하지 않으며 CI, 배포가 자동화되어 수시로 패보가 일어나는 프로젝트에 유용
vs Git-flow
master 브랜치는 어떤 때든 배포가 가능한 상태로 운영
브랜치는 항상 master로부터 만든다
develop,feature브랜치 존재하지 않는다- Merge하기 전에 충분한 단위 테스트를 거쳐야 되며 제품 테스트는 로컬에서 하는 것이 아닌 브랜치를 push하고 Jenkins로 테스트
GitLab-flow
Git-flow와 GitHub-flow의 절충안
master, pre-production, production 3개의 브랜치로 운영
master : 에서 개발이 이루어지며 개발이 이루어진 작업들은 pre-production에서 테스트 되고 테스트가 성공한다면 production에서 배포된다
단위 기능들은 master 브랜치로부터 형성
1. 간단하게 master 브랜치에서 단위 기능 브랜치들이 뻗어나가며 master는 단위 기능들의 Merge 상태
2. production 브랜치는 배포 브랜치이며 production 브랜치에 가기 전에 pre-production 브랜치에서 테스트
회사 전략과 비교
물론 전략이라는게 특정 한 가지와 일치해야되는 것이 아니고 유조리 있게 갈 수 있는 것이지만 현 시점(23.05.25) 회사 브랜치의 경우 Git-flow나 GitLab-flow라고 볼 수 있다고 생각한다
크게 master, develop, feature로 구분되어 있으며 3차 사업의 경우 단위 기능 개발을 위해 feature-dev라는 브랜치를 구분지어 사용한다
feature하위에 특정 단위 기능 브랜치들을 추가해 개발 진행한다
이 때master는 운영, 배포
develop은 3차 사업 전용 브랜치로 사용하며 개발로 단위 기능인feature들의 Merge 브랜치이다
develop을 개발 서버로 배포하고 개발 서버에서 정상적이다 간주하면 master에 올라가 운영 서버로 배포 된다
ref
브랜치 전략 참고 : https://velog.io/@kw2577/Git-branch-%EC%A0%84%EB%9E%B5
