[Git] Git Branch 전략 (Git/GitHub/GitLab Flow)

 

 

 

1. Git Branch 란?

• 독립적인 작업 흐름을 만들기 위해 사용하는 기능
• 브랜치를 활용하면 코드의 기본 흐름(보통 main 또는 master 브랜치)과 분리된 상태에서 개발 진행
• 여러 명의 개발자가 동시에 작업할 때, 각각의 기능 개발, 버그 수정, 릴리즈 준비 등을 독립적인 브랜치에서 진행하여 메인 코드베이스와의 충돌을 줄이고, 안정적인 통합을 가능하게 하는 일련의 규칙이자 관행

 

2. Git Branch 가 필요한 이유?

• 동시 개발 지원: 여러 개발자가 각각의 기능을 독립적 개발 가능
• 코드 안정성 유지: 메인 브랜치('main' or 'master')의 안정성을 유지하면서 새로운 기능 추가
• 효율적인 버전 관리: 새로운 기능 실험, 테스트한 후 안정적인 코드만 병합
• 빠른 오류 수정: 버그 수정이 필요한 경우, 별도의 브랜치에서 해결 후 메인 브랜치에 반영

 

3. 다양한 Git Branch 전략

    Git에서는 여러 가지 브랜치 전략이 존재, 대표적으로 Git Flow, GitHub Flow, GitLab Flow, Trunk-based development, Space Git Flow 등이 있음.

    오늘은 Git Flow, GitHub Flow, GitLab Flow에 대해서 알아볼 예정

 

---

  3-1. Git Flow

• Git Flow는 develop, feature, release, hotfix 등의 여러 브랜치를 활용하는 워크플로우
• 비교적 복잡한 프로젝트의 릴리즈 관리에 적합하도록 설계
• 배포 주기가 잦지 않은 프로젝트에 적합
• 다양한 버전 관리가 필요한 모바일 애플리케이션에 적합
• 안정적인 소프트웨어 개발을 목표로 함 
• feature → develop → release → main으로 병합

• 

  출처 : https://blog.jetbrains.com/space/2023/04/18/space-git-flow/br

 

• Branch 역할 및 규칙
  • main(master) - 프로덕션 배포용 기본 브랜치
    • 가장 안정적인 배포 버전이 관리되는 브랜치
    • 항상 main 브랜치는 배포 가능한 상태
    • 최종 릴리스 코드가 포함된 안정된 브랜치
    • 실제 운영에 반영되어 있는 배포 전 최종 소스 코드가 있는 브랜치
    • (GitHub Actions로 main 브랜치에 push되면 배포 자동화 설정 가능)
  • develop - 실제 개발용 기본 브랜치
    • main 브랜치 배포 전 통합 테스트 수행
    • Git Flow에서 develop은 main과 나란히 존재
    • (main에서 바로 분기, main에 최종 병합)
    • • develop 브랜치에서
        • 새로운 기능 개발할 때 feature 생성, 개발이 끝나면 다시 develop에 PR 보내 병합
        • 릴리스 준비할 때 release 생성, 테스트/QA가 끝나면 main&develop에 병합
  • hotfix/* - 긴급한 버그 수정용 브랜치
    • 배포 후 발생한 크리티컬 한 버그를 긴급하게 수정하는 브랜치
    • 형식: hotfix/버그명, hotfix/이슈번호 ➡️ hotfix/critical-bug, hotfix/22-login-failure
    • (main에서 바로 분기, main&develop에 최종 병합)
  • release/* - 배포 준비용 브랜치
    • 릴리스 후보 버전을 다루는 브랜치
    • 릴리스가 임박했을 때 테스트/QA 단계에서 발생하는 수정 사항을 처리하는 브랜치
    • 형식: release/버전 or release/배포이름 ➡️ release/v0.1.0, release/v1.0.0, release/v2.3-login-feature
    • (develop에서 분기, main&develop 브랜치에 최종 병합)
  • feature/* - 기능 단위 개발용 브랜치
    • 특정 기능 or 새로운 기능을 구현하기 위한 작업용 브랜치
    • 대부분의 경우 feature는 비교적 짧게 유지
    • 작업이 끝나면 곧바로 소스 브랜치로 병합
    • 형식: feature/기능명, feature/이슈번호-기능 ➡️ feature/login-page, feature/add-user-api, feature/refactor-db
    • (develop에서 분기, develop에 PR 보내 병합)
  • docs - 문서 작업용 브랜치
    • 문서 중심 작업
    • 주로 정적 사이트 or README.md, 위키 등
    • 예시: docs/update-readme, docs/add-api-docs
    • (보통은 main, 필요 시 develop에 병합)

 

• 브랜치 분기 정리
  • main 브랜치에서 분기 ➡️ develop, hotfix, docs 등
  • develop 브랜치에서 분기 ➡️ feature, release(릴리스 준비)
  • release 브랜치에서 분기 ➡️ bugfix(release에서 발견된 버그 수정용)
  • feature 브랜치에서 분기 ➡️ sub-feature, spike(실험용), ticket, task(작은 단위의 작업) 등

참고:
용도에 맞게 브랜치를 분리해서 사용
    1. main & develop 브랜치는 중심 브랜치이기 때문에 필수
    2. 각 팀이나 프로젝트마다 조금씩 다르게 활용될 수 있음
    3. branch를 merge 할 때는'--no-ff' 옵션을 붙여서 branch에 대한 기록(“feature 브랜치가 있었다” 등)이 사라지는 것을 방지할 수도 있음 (병합 커밋을 강제로 만들어서 브랜치 병합 이력을 남기고 싶을 때 사용)

 

• 장점
  • 명확한 브랜치 구조로 안정적인 배포 가능
  • 대규모 프로젝트에 적합
  • 기능 개발, 테스트, 배포 단계가 분리되어 협업이 용이함
• 단점
  • 브랜치가 많아 관리가 복잡할 수 있음
  • 작은 프로젝트에서는 불필요하게 복잡할 수 있음

 

---

  3-2. GitHub Flow

• GitHub Flow는 단순한 브랜치 전략, 빠른 배포와 협업을 강조
• 규칙이 있는 브랜치가 main 뿐이고 간단한 만큼 비교적 규모가 작은 프로젝트에서 적합하다.
• 수시로 배포가 일어나서 잦은 배포 주기를 가지는 프로젝트에서 적합하다.
• git에 익숙하지 않은 사람이 있을 때 경험해보기 좋다.

  

  출처 : https://blog.jetbrains.com/space/2023/04/18/space-git-flow/br

 

• Branch 역할 및 규칙
  • main(master) - 프로덕션 배포용 기본 브랜치, 항상 main 브랜치는 배포 가능한 상태, 가장 안정적인 배포 버전이 관리되는 브랜치, 실제 운영에 반영되어 있는 소스 코드가 있는 브랜치, main으로 merge 하기 전 엄격한 테스트 (CI 필수)
  • 새로운 브랜치 - 새로운 기능을 개발할 때마다 임의의 브랜치 생성하여 작업, 브랜치 명과 커밋 메시지는 어떤 일을 하고 있는지 명확하게 작성, (main에서 분기, main에 최종 병합)

GitHub Flow는 main 브랜치만 엄격한 규칙 적용, 나머지 브랜치는 별다른 규칙 x
    1. 기본 브랜치는 main(or master), 별도의 develop 브랜치 x
    2. 작업이 완료되면 pull request(PR)를 생성하여 코드 리뷰 진행, main 브랜치에 병합
    3. 배포는 main 브랜치에서 바로 진행

 

• 장점
  • 간단하고 직관적인 구조
  • 빠른 개발과 배포가 가능
  • 코드 리뷰를 통해 품질 유지 가능
• 단점
  • 안정성을 보장하기 어려움 (테스트 브랜치 x)
  • 대규모 프로젝트에서는 비효율적일 수 있음

 

---

  3-3. GitLab Flow

• GitLab Flow는 Git Flow의 구조적 접근 방식 + GitHub Flow의 단순함을 결합한 전략
• 지속적인 배포(Continuous Deployment)를 고려하여 설계

출처 : https://parkstate.tistory.com/33

 

• Branch 역할 및 규칙
  • main(master) : production 브랜치에 최종 병합, 항상 main 브랜치는 배포 가능한 상태
  • pre-production : production으로 넘어가기 전의 브랜치, 테스트 담당
  • production : Git Flow의 main 브랜치와 역할이 같음, 배포 담당
  • 새로운 브랜치 : GitHub Flow의 새로운 브랜치처럼 사용 

main 브랜치와 production 브랜치를 분리하여 배포를 관리
    1. 기능 개발을 위한 feature 브랜치를 생성하여 작업
    2. environment 브랜치를 활용하여 개발(Develop), 테스트(Test), 스테이징(Staging), 프로덕션(Production) 환경 분리 가능
    3. GitLab CI/CD와 연계하여 자동 배포를 쉽게 구현 가능

 

•  장점
  • 배포 환경을 구분할 수 있어 안정적인 배포 가능
  • GitLab CI/CD와의 연계가 용이하여 자동화된 배포 가능
  • 복잡한 Git Flow보다 단순하면서도 구조적 관리 가능

• 단점
  • 작은 프로젝트에서는 다소 과할 수 있음
  • 환경별 브랜치를 관리해야 하므로 일정 수준의 운영 부담이 있음

 

---

Reference Blog

https://blog.jetbrains.com/space/2023/04/18/space-git-flow/
https://ddingji-dev.tistory.com/4
https://ksh-coding.tistory.com/109#%E2%9C%85%202-1.%20Git%20Flow-1
https://parkstate.tistory.com/33