Git flow 브랜치 전략

김민아·2022년 10월 21일
0
post-thumbnail

Git-flow

Git-flow 브랜치 전략은 2010년 Vincent Driessen의 블로그로부터 시작되었고, 현재 Git 브랜칭 전략 중 유명한 브랜칭 전략이다. Git flow에는 다섯 종류의 브랜치가 존재한다. 항상 존재하는 master(main), develop 브랜치와 일정 기간 동안 유지되는 보조 브랜치들 (feature, release, hotfix)가 있다.

  • master : 제품으로 출시될 수 있는 브랜치
  • develop : 다음 출시 버전을 개발하는 브랜치
  • feature : 기능을 개발하는 브랜치
  • release : 이번 출시 버전을 준비하는 브랜치
  • hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치

그림을 명확히 이해하기 위해서 시간의 흐름대로 차근차근 살펴보는 것이 좋다. mastermain으로 developdev로 작성했다. 대략적인 흐름은 다음과 같다.

  • main에서 dev 브랜치를 생성한다.
  • 새로운 기능이 필요한 경우 dev에서 feature 브랜치를 생성한다.
  • 기능추가가 완료되면 feature에서 dev로 merge된다.
  • 모든 기능이 merge되면 QA를 하기 위해 dev에서 release 브랜치를 생성한다.
  • 여기서 발생한 에러들은 realease에서 수정한다.
  • QA를 통과하면 release 브랜치를 maindev에 merge한다.
  • 마지막으로 출시된 main 브랜치에 버전 태그를 추가한다.

Git flow는 대규모 프로젝트를 제작하여 하나의 소프트웨어 릴리즈 버전을 명확하게 나누는 당시의 개발 환경에 적합했지만 당시와 달리 빠르게 제작하고 배포하는 애자일 팀에게 적용하기는 복잡하게 느껴질 수 있다. 프로젝트 상황에 맞는 git-flow 협의가 필요한 부분이다.

이런 소프트웨어(웹 애플리케이션)는 내가 2010년 작성했던 블로그에서 생각했던 타입의 소프트웨어가 아니다. 당신의 팀이 지속적 배포를 원한다면, Github flow와 같은 간단한 워크플로우 도입을 제안한다. 굳이 애써 git-flow를 우겨넣지 않아도 된다.
_2020년 5월에 추가된 원문의 코멘트


Coz’ Git flow

Git flow에서 파생된 여러 Git flow 중에 대표적으로 Github flow, Gitlab flow가 있다. pre-project를 진행하며 코드스테이츠에서 제안한 git flow는 위 Git flow를 단순화한 Coz’ Git flow이다.

관련해서 간략하게 정리해보면,

핵심 브랜치 maindev 브랜치를 둔다. main은 상용으로 배포할 수 있는 브랜치이며, dev는 다음 버전 배포를 위해 개발 중인 브랜치이다. main 브랜치로 배포하기 전에 확인해야 할 것들은 다음과 같다.

main checklist

  • 대표적인 기능이 완성되었는지
  • 레이아웃과 디자인이 완성되었는지
  • client, server, DB가 공개된 웹에서 정상적으로 통신하는지
  • 최소한의 보안이 구축되었는지
  • 개발버전에서 사용한 secret이나 유저의 비밀번호가 노출이 되는지
  • 인증 토큰, 세션이 꼭 필요한지

dev branch

  • dev는 가능하면 프로젝트 팀원과 FE, BE의 작업을 합쳐서 확인해볼 수 있어야 한다.
  • CI/CD 파이프라인이 구축되어 있다면 dev 브랜치의 코드도 배포를 해두고 확인할 수 있다.

feature 보조 브랜치

  • 기능 개발, 리펙토링, 문서 작업, 단순 오류 수정 등 다양한 작업을 기록하기 위한 브랜치
  • refactor, fix, docs, chore와 같이 세세하게 커밋 메시지나 브랜치 명에 prefix를 달기도 한다.
  • feature 브랜치는 보통 각 개인의 로컬 리포지토리에서 만들고 작업한다.
  • 자주 커밋하고, 자주 원격 Github 리포지토리에 push하여 팀원들과 결과를 공유하는 것이 바람직하다.
  • 일반적으로 feature 브랜치는 머지하고 나서 삭제하지만, 복원해야 할 필요성이 있는 경우는 남겨두기도 한다.

merge 전략

  • rebase-and-merge: 커밋 기록을 남기는 일반적인 방법
  • squash-and-merge: 기능마다 깔끔하게 커밋을 남기기를 원해서 커밋 기록을 정리하는 방법

출처

0개의 댓글