Git 브랜치 전략

Git 브랜치 전략

Git 브랜치 전략은 소프트웨어 개발 프로젝트에서 코드의 버전 관리를 효율적으로 수행하기 위한 방법론이다. 여러 가지 브랜치 전략이 있으며, 각각의 전략은 프로젝트의 규모, 팀의 작업 방식, 릴리스 주기 등에 따라 다르게 적용될 수 있다. 가장 일반적으로 사용되는 Git 브랜치 전략에는 다음과 같은 것들이 있다. 😉

Git Flow

Git Flow는 기능 개발, 릴리스 준비, 유지 보수를 위한 여러 종류의 브랜치를 사용한다.

• Master: 제품의 공식 릴리스 버전에 해당하는 코드를 관리한다. 여기에 커밋되는 코드는 새로운 릴리스 준비가 완료된 상태여야 한다.
• Develop: 다음 릴리스를 준비하는 개발 작업이 진행되는 브랜치이다. 기능 브랜치들이 여기로 병합된다.
• Feature branches: 새로운 기능 개발이나 버그 수정 등의 작업을 위해 develop 브랜치로부터 분기하여 생성한다. 작업이 완료되면 develop 브랜치로 병합된다.
• Release branches: 릴리스 준비를 위해 develop 브랜치로부터 생성된다. 릴리스를 위한 최종 버그 수정, 문서 업데이트 등의 작업을 수행한다. 준비가 완료되면 master로 병합되고, 태그를 붙여 릴리스 버전을 명시한다.

• Hotfix branches: master 브랜치에서 발생한 긴급한 버그를 수정하기 위해 생성된다. 수정이 완료되면 master와 develop 브랜치 양쪽으로 병합된다.

• 장점
  • 명확한 역할 분담: 각 브랜치의 역할이 명확하여 대규모 팀에서 작업을 조직하기 쉽다.
  • 안정적인 릴리스 관리: 릴리스와 핫픽스 브랜치를 통해 배포 과정을 체계적으로 관리할 수 있다.
• 단점
  • 복잡성: 많은 종류의 브랜치를 관리해야 하므로 소규모나 빠른 배포가 필요한 환경에서는 비효율적일 수 있다.
  • 학습 곡선: 새로운 개발자가 전략을 이해하고 적용하기까지 시간이 필요하다.
• 사용 예시
  • 대규모 소프트웨어 프로젝트: 정기적인 릴리스 주기를 가지고 있는 대규모 프로젝트에서 안정적인 버전 관리와 릴리스 준비 과정을 체계적으로 진행할 수 있다.

GitHub Flow

GitHub Flow는 Git Flow보다 단순하며, 빠른 배포를 지원하는 전략이다.

• Master: 언제나 배포 가능한 상태의 코드를 유지한다.

• Feature branches: 새 기능 개발이나 버그 수정을 위해 master로부터 분기한다. 작업이 완료되면 리뷰를 거쳐 master에 병합되고, 즉시 배포된다.

• 장점
  • 단순성: 브랜치 전략이 단순하여 빠르게 배우고 적용할 수 있다.
  • 지속적인 배포: master 브랜치가 항상 배포 가능한 상태를 유지하므로, 지속적인 통합(CI)과 배포(CD)에 적합하다.
• 단점
  • 한정된 릴리스 관리: 별도의 릴리스 브랜치가 없어 대규모 프로젝트에서 세부적인 릴리스 관리가 어려울 수 있다.
• 사용 예시
  • 스타트업 또는 소규모 팀: 빠른 기능 개발과 지속적인 배포가 요구되는 환경에서 효과적이다.

GitLab Flow

GitLab Flow는 Git Flow와 GitHub Flow의 장점을 결합한 전략으로, 환경에 따른 브랜치 관리를 강조한다.

• Master: 항상 최신 상태로 유지되며, 언제든지 배포 가능해야 한다.
• Pre-production/Production branches: 실제 배포 환경에 따라 여러 브랜치를 운영한다. master에서 변경 사항을 병합하여 테스트하고, 문제가 없으면 실제 배포 환경의 브랜치로 병합한다.

• 장점
  • 환경 기반 브랜치 관리: 개발, 스테이징, 프로덕션 등 다양한 환경에 대한 브랜치를 따로 관리할 수 있어, 각 환경에 맞는 배포 프로세스를 구성하기 용이하다.
  • 유연성: GitHub Flow의 단순성과 Git Flow의 체계성을 조합하여, 다양한 프로젝트 규모와 요구사항에 맞출 수 있다.
• 단점
  • 설정 복잡성: 여러 환경에 대한 브랜치를 관리하므로 초기 설정이 복잡할 수 있다.
  • 브랜치 관리: 여러 환경 브랜치 간의 병합 규칙을 명확하게 정의하고 관리해야 한다.
• 사용 예시
  • 중대형 프로젝트: 개발, 테스트, 배포 환경이 명확히 구분된 프로젝트에서 각 환경에 맞는 코드 관리와 배포를 원활하게 수행할 수 있다.

Github vs Gitlab ❗️

Github이랑 Gitlab 전략이 다소 비슷해 보인다. 정확히 어떤 차이점이 존재하는 걸까? 🧐

Gitlab은 Master, Pre-production, Production branches 3가지에 브랜치를 사용한다고 되어있지만, 실무에서는 보통 개발(Development), 스테이징(Staging), 프로덕션(Production)과 같은 여러 배포 환경을 기준으로 브랜치를 만들고 따로 관리하는 방식을 사용한다.

이를 다시 정리하면 아래와 같다.

• GitLab Flow의 환경 기반 브랜치 관리 방식
  • Master 브랜치: 모든 개발 작업의 기반이 되는 브랜치이다. master 브랜치는 항상 최신 상태로 유지되며, 코드의 안정성이 보장된 상태여야 한다.
  • Development 브랜치(Dev): 신규 개발 작업이나 기능 추가 작업이 이루어지는 브랜치이다. 일반적으로 master 브랜치로부터 분기되며, 개발이 완료된 후 master 브랜치로 병합된다.
  • Staging 브랜치(Stag): 실제 프로덕션 환경과 유사한 테스트 환경에서 코드를 테스트하기 위한 브랜치이다. master에서 분기되며, 스테이징 환경에서 충분한 테스트와 검증을 거친 코드는 프로덕션 환경으로 배포되기 전의 최종 검증 단계를 의미한다.
  • Production 브랜치(Prod): 실제 사용자에게 서비스되는 환경의 코드를 관리하는 브랜치이다. master 또는 staging 브랜치에서 충분히 검증된 코드가 production 브랜치로 병합되어 실제 서비스에 반영된다.