Git Flow 브랜칭 전략

1. 초기 커밋: README.md, .gitignore 등의 설정 파일들을 main 브랜치에 커밋
2. main 브랜치에서 develop 브랜치를 분기하고, 개발에 필요한 템플릿 코드 등을 develop 에 커밋
3. 기능 단위로 develop 브랜치에서 feature/<기능명> 브랜치를 분기하고 작업 진행
   • ex. feature/add-user-profile
4. 기능 개발이 완료되면 해당 feature 브랜치를 develop 에 병합
   • 병합 이후 develop 브랜치에서 버그가 확인되면 develop 브랜치에서 바로 수정
   • develop 브랜치에서 발견된 버그의 규모가 크다면 feature/<기능명> 브랜치로 분기하여 작업 진행후 다시 develop 에 병합
     • 실제 Git Flow 모델에서도 "버그 수정도 새로운 feature 로 간주할 수 있다" 는 유연한 문장이 있음
     • ex. feature/fix-XYZ
5. 배포 준비가 되면 develop 브랜치에서 release/<버전> 브랜치를 분기
   • ex. release/2.1.0
6. release 브랜치에서 QA 및 테스트를 진행하고, 필요한 수정이 있다면 이 브랜치에서 직접 수행
7. 테스트가 완료되면 release 브랜치를 main 에 병합하고, 태그 (tag) 를 생성
   • ex. v2.1.0
8. 이후 동일한 내용을 develop 브랜치에도 병합하여 다음 개발 주기와 동기화
9. 운영 중 버그 발생 시, main 브랜치에서 hotfix/<버전> 브랜치를 분기하여 수정 후 main 에 병합 및 태그 (tag) 생성 후 develop 에 병합
   • ex. v2.1.3
   • <버전> 은 해당 hotfix 가 적용된 후 main 이 가지게 될 “새로운 버전” 을 의미
   • ex. hotfix/2.1.3
   • 따로 release 브랜치를 거치지 않음

 

• 태그에는 v2.1.0 과 같이 앞에 v 를 붙이는게 일반적이지만 브랜치 이름에는 release/2.1.0 과 같이 v 를 생략하는것이 권장됨
• main 에 병합이 발생하는 경우라면 어느 경우라도 (release 브랜치에서 병합을 하는 경우든 hotfix 브랜치에서 병합을 하는 경우든) 태그를 반드시 붙일 것
  • 엄밀히 말하면 병합이 발생하던 커밋이 발생하던 릴리스 단위인 경우 태그를 붙이는 것
  • release 또는 hotfix 브랜치를 main 에 병합한 후 생성된 해당 커밋에 태그를 붙임
• Git Flow 모델에서 main 브랜치는 merge-only 브랜치로 모든 커밋은 develop, feature/*, release/*, hotfix/* 브랜치를 통해서만 발생
  • 단, Git Flow 운영을 시작하기 전 단계에 한해 예외로 main 브랜치에서 직접 커밋 허용
    • Git 저장소 초기화 시 보통 main 에서 커밋을 먼저 함 (README.md, .gitignore 등)
    • 이 시점에는 develop, feature/*, release/*, hotfix/* 등 어떤 브랜치도 없음
    • 해당 경우에는 태그를 생략하는것이 정석 (릴리스 가능한 상태가 아니기 때문)
    • 이후 모든 커밋은 develop, feature/*, release/*, hotfix/* 브랜치를 통해서만 발생
• release 혹은 hotfix 에서 main 과 develop 에 병합할 때 main 에 먼저 병합한 후 develop 에 병합할 것
  • main 은 실제 배포된 코드의 기록이므로 반드시 먼저 병합되어야 하며, 이후에 변경 사항을 develop 에 병합하여 개발 흐름과 동기화
  • 순서를 뒤집을 경우 develop 병합 중에 충돌이 생겨서 수정 내용이 바뀌면, main 과 develop 의 코드가 달라지는 위험이 있으며 이는 Git Flow 의 원칙에 위반