Git Flow 브랜치 가이드

김소희·2023년 6월 12일

브랜칭 전략이란 효율적인 코드 관리를 위해 브랜치의 종류와 역할을 구분해 사용하는 방법을 말합니다.
Git이 널리 쓰이면서 여러 가지 전략이 등장했는데, 그중 가장 유명한 것이 바로 Git Flow인데, Git Flow는 대규모 개발 프로젝트에서 소프트웨어의 릴리즈 버전을 명확하게 구분하고, 동시에 여러 버전을 배포해야 하는 환경에 적합합니다.

프로젝트에 Git Flow 전략을 채택한 이유

개발에 초점을 둔 초기 프로젝트로 배포 주기가 잦지 않은 상황을 고려했습니다. 규모에 비해 브랜치가 많아 관리 부담은 있지만, 시행착오를 통해 우리 팀에 맞는 전략으로 발전시킬 수 있으며, 잦은 Pull Request와 Merge 충돌 경험을 통해 Git 스킬을 향상시킬 수 있기 때문에 Git Flow 전략을 채택했습니다.

Git Flow 전략의 장점

  • 버전 관리를 위한 release 브랜치를 따로 관리하기 때문에, 특정 버전에 대한 유지보수 기간이 길고 여러 버전을 동시에 관리해야 할 때 유용합니다
  • 운영 환경(Production) 배포 브랜치와 개발 환경(Develop) 배포 브랜치를 명시적으로 분리해서, 운영 환경에 어떤 코드베이스가 배포되어 있는지 한눈에 확인할 수 있습니다
  • 아직 테스트가 완료되지 않은 feature가 운영 환경에 배포되는 것을 방지할 수 있습니다

Git Flow 워크플로우

Git Flow 다이어그램

  1. 개발자는 develop 브랜치로부터 본인이 신규 개발할 기능을 위한 feature 브랜치를 생성합니다
  2. feature 브랜치에서 기능을 완성하면 develop 브랜치에 merge를 진행합니다
  3. feature 브랜치들이 모두 develop 브랜치에 merge 되었다면 QA를 위해 release 브랜치를 생성합니다
  4. release 브랜치를 통해 오류가 확인된다면 release 브랜치 내에서 수정을 진행합니다
  5. QA와 테스트를 모두 통과했다면, 배포를 위해 release 브랜치를 main 브랜치로 merge하며, 만일 release 브랜치 내부에서 오류 수정이 진행되었을 경우 동기화를 위해 develop 브랜치에도 merge를 진행합니다
  6. 만일 배포된 라이브 서버(main)에서 버그가 발생한다면, hotfix 브랜치를 생성하여 버그 픽스를 진행합니다
  7. 종료된 버그 픽스를 main과 develop 양쪽에 merge하여 동기화시킵니다

브랜치 구조

이름설명예시
main사용자에게 언제든 배포할 수 있는 브랜치main
develop다음 버전 배포를 위한 개발 중인 브랜치로 통합 브랜치의 역할을 합니다develop
feature기능 개발, 리팩토링, 문서 작업, 단순 오류 수정 등 다양한 작업을 기록하기 위한 브랜치feature/member_join
release다음 버전 출시를 준비하는 브랜치로 develop 브랜치를 release 브랜치로 옮긴 후 QA, 테스트를 진행하고 main 브랜치로 합칩니다release/1.2
hotfix배포 후 발생한 버그를 긴급하게 수정할 필요가 있을 때 main 브랜치에서 분리하는 브랜치hotfix/comment_error

배포 가능한 상태에 대한 규칙

  • 핵심적인 기능이 완성되었다
  • 기존 기획했던 레이아웃이나 전체적인 디자인이 얼추 완성되었다
  • 클라이언트, 서버, 데이터베이스가 공개된 웹에서 정상적으로 통신할 수 있다
  • 최소한의 보안이 마련되었다

브랜치 네이밍 규칙

브랜치명은 반드시 소문자 + 언더바(_) 로만 작성합니다.
⚠️ 대문자, 한글, 띄어쓰기, 특수문자 사용 금지 (운영체제별 충돌 방지)

예시

  • feature/user_login
  • Feature/UserLogin, feature/유저가입

브랜치 작업 단위

한 브랜치에는 하나의 명확한 기능이나 이슈만 포함시킵니다. 여러 기능을 동시에 구현하지 않습니다.

예시

  • feature/user_login
  • feature/user_login_and_profile_edit

브랜치명 예시

작업 내용브랜치명
자격증 리스트 페이지 개발feature/certification_list_page
일정 불러오기 API 버그 수정fix/schedule_api_nullpointer
JSP 템플릿 리팩터링refactor/jsp_layout
README 업데이트docs/readme_update
1차 배포 버전release/v1_0_0

금기사항

  • 코드리뷰 없이 독자적으로 main 브랜치 변경
  • PR 없이 main, develop 브랜치에 merge
  • 사용하지 않는 브랜치 삭제하지 않는 행위

참고자료

Vincent Driessen의 Git branching model
IT Lab의 티스토리

profile
개발자 소희의 노트

0개의 댓글