[Git] Git Flow란, 서버 환경, 브랜치 종류

협업할 때 브랜치들을 효율적으로 관리하기 위한 브랜치 관리 전략

1. Git Flow 장점

• 문제가 발생했을 때 쉽고 빠르게 추적할 수 있다.
• 기능 단위로 브랜치를 따서 다른 사람의 개발에 영향을 받지 않고 독립적인 개발 환경을 만들어준다.

2. 서버 환경 종류

• Production
  • 운영 서버
  • 실제 서비스를 운영하는 서버
• Staging
  • 검증 서버
  • 실제 운영 환경과 거의 동일한 환경을 만들어서 배포 전에 기능을 검증하는 서버
• Dev
  • 개발 서버
  • Local 서버에서 개발자들이 기능 단위로 개발한 코드를 합친 서버
• Local
  • 로컬 서버
  • 본인 PC 환경

3. 브랜치 종류

• master와 develop 브랜치는 필수 브랜치, 나머지 브랜치는 유지 보수를 목적으로 하는 선택적인 브랜치
• master
  • 실제 운영 환경(Production)에 배포하는 브랜치
  • tag을 통해 버전을 기록한다.
    • major 배포 - x.1
    • minor 배포 - 1.x
• hotfixes
  • 운영 환경(Production)에서 발생한 버그를 수정하는 브랜치
  • master 브랜치에서 따와 버그 수정 후 master, develop 브랜치에 merge
• release
  
  • 운영 환경(Production)에 배포하기 전에 검증하는 브랜치
  • 버그 발생 시 수정 후 develop 브랜치에 merge
• develop
  • 다음 배포할 기능들을 관리하는 브랜치
  • feature 브랜치에서 개발한 코드를 병합하는 역할
• feature
  • 각 기능 별로 개발하는 브랜치
  • develop 브랜치에서 따온 브랜치로 작업 완료 후 develop 브랜치에 merge
  • 네이밍 규칙
    • 위 브랜치 이름 사용 불가능
      • ex) master, develop, release, hotfix, ...
    • feature/기능요약 형식 추천
      • ex) feature/login
    • 이슈 추적하는 경우 feature/{issueNumber}-{featureName}
      • ex) feature/1-init-projcet

Production 환경 - master 브랜치
Staging 환경 - release 브랜치
Dev 환경 - develop 브랜치
Local 환경 - feature 브랜치

4. Git Flow

• 처음 시작은 master 브랜치
• master 브랜치를 따서 develop 브랜치 생성
• major 배포
  • develop 브랜치에서 기능 별로 feature 브랜치 생성
    • 이번 배포에 나갈 major feature 브랜치
    • 다음 배포에 나갈 feature 브랜치
  • feature 브랜치에서 개발이 끝나면 develop 브랜치에 병합
  • 모든 기능을 합친 후 release 브랜치에서 기능 검증(QA)
    • 검증하다가 버그 발생하면 수정 후 develop 브랜치에 merge
    •  feature 브랜치에서도 개발할 때 필요한 수정 사항이면 수정된 develop 브랜치 pull
  • 검증 완료 후 master 브랜치에 major 배포

• minor 배포
  • master 브랜치에서 발생한 버그를 빠르게 수정하기 위한 hotfix 브랜치 생성
  • 버그 수정 후 master 브랜치와 develop 브랜치에 merge

Git Flow

5. 실전 예시

• release 브랜치에서 검증하다가 버그가 발생하면 release 브랜치에서 수정하고 바로 develop 브랜치에도 merge하면 과정이 복잡해지니까 검증 완료 후 release 브랜치를 master 브랜치에 머지하고 거기서 develop 브랜치와 싱크를 맞춘다.
  • 이론적으로는 develop 브랜치의 내용이 항상 최신이어야 한다.
  • 실무에서는 다음 버전 기능에서 이번 기능 검증할 때 수정한 내용이 필요하면 Cherry-pick을 사용해서 원하는 커밋만 땡겨서 적용시킨다.
• 만일 다른 사람들은 다 개발하고 배포하고 있는데 내가 개발한 내용은 6개월 뒤 배포이고 feature 브랜치가 100개 이상일 때 브랜치 전략은?
  • 내가 개발한 내용은 6개월 뒤에 배포해야하기 때문에 develop 브랜치에는 들어가면 안된다. 왜냐하면 develop 브랜치는 다른 사람이 계속 개발한 기능을 추가하고 배포하기 때문이다.
    • 만일 develop 브랜치에 내가 개발한 내용을 계속 추가했다가 빼야하는 상황이 온다면 revert를 해야해서 번거롭다.
  • 내가 개발한 feature 브랜치는 develop 브랜치에 바로 merge 할 수 없으니까 PR을 생성해놓고 merge 버튼만 누르기 전으로 만들어 놓으면 나중에 PR을 100번 이상 해야해서 번거롭다.
  • 이를 해결하는 방법
    • 트리처럼 develop 브랜치에서 프로젝트 브랜치(일종의 피처인데 그보다 좀 더 넓음)를 따서 이것을 베이스로 기능별로 feature 브랜치를 여러 개 따서 개발하여 프로젝트 브랜치에 마음대로 merge 할 수 있다.
    • 그러면 develop 브랜치에는 배포할 시기에 프로젝트 브랜치를 한번만 머지하면 된다.

결과적으로 실무에서 사용하는 깃 플로우는 이론적인 것과 약간 다를 수도 있다. 하지만 이론적인 깃 플로우를 베이스로 회사마다 조금씩 바뀌기 때문에 기본적인 깃 플로우에 대한 흐름을 아는 것이 중요할 것 같다.!