코드스테이츠

6.12 Git flow

스우티 2023. 6. 12. 16:23

Git flow

Git flow는 2010년 Vincent Driessen의 블로그 글로부터 시작되었고, 이후 많은 개발자의 사랑을 받아온 Git 브랜칭 전략입니다. Git flow는 대규모 개발 프로젝트를 제작하여 하나의 소프트웨어의 릴리스 버전을 명확하게 나누고, 다양한 버전을 배포해야 하는 당시의 개발 환경과는 적합했지만, 빠르게 제작하고 배포하고 고객의 피드백을 받는 애자일한 개발 팀에 적용하기는 다소 복잡했습니다. 원문에도 아래와 같은 조언이 담겨있습니다.

Web apps are typically continuously delivered, not rolled back, and you don't have to support multiple versions of the software running in the wild. 웹 애플리케이션은 대개 보통 지속적으로 배포되고, 배포를 되돌 일 일이 없다. 또한 여러 버전을 배포하지 않아도 된다.

This is not the class of software that I had in mind when I wrote the blog post 10 years ago. If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.

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

If, however, you are building software that is explicitly versioned, or if you need to support multiple versions of your software in the wild, then git-flow may still be as good of a fit to your team as it has been to people in the last 10 years. In that case, please read on. 만약 당신의 소프트웨어가 엄격한 버저닝이 필요하고, 여러 버전을 배포해야 하는 경우에는 Git-flow는 당신의 팀에 잘 맞을 수 있고, 계속 읽어주길 바란다.

위 설명처럼, 주어지는 개발 현장의 상황에 맞게 Git flow를 정하는 게 중요합니다. 당장 복잡한 Git flow가 필요 없는데, 애써서 Git flow를 복잡하게 만들 필요는 없습니다. 물론, 꼭 필요하다면 아래 Git flow를 써보는 것도 좋을 겁니다. 상황에 맞게 팀원 간 논의가 필요한 부분입니다.


Coz’ Git flow

이에 “원조" Git flow에서 파생된 여러 Git flow가 있는데, 대표적인 Git flow는 Github flow, Gitlab flow가 있습니다. 코드스테이츠에서는 위 Git flow를 단순화한 Coz’ Git flow를 제안합니다. Pre-Project에서는 가능하면 Coz` Git flow에 맞게 진행해 보고, 향후 Main-Project에서는 팀원 간 상의를 통해 적절한 Git flow를 정하시기 바랍니다.


핵심 브랜치

Coz’ Git flow는 중요 브랜치 두 개를 가지고 있습니다. main 브랜치와 dev 브랜치입니다.


main 브랜치

사용자에게 언제든 제품으로 출시할 수 있는 브랜치

main 브랜치는 사용자에게 언제든 배포할 수 있는 브랜치입니다. 회사에 따라서 master, prod, production 등 다양하게 불립니다. “언제든 배포할 수 있다"의 의미는 회사 별로, 팀 별로 다를 수 있습니다. 다만, 최소한의 기준을 세워볼 수 있습니다.

  • 대표적인 기능이 완성되었다.
  • 기존 기획했던 레이아웃이나 전체적인 디자인이 얼추 완성되었다.
  • 클라이언트, 서버, 데이터베이스가 공개된 웹에서 정상적으로 통신할 수 있다.
  • 최소한의 보안이 마련되었다.
    • 브라우저에서 개발 버전에서 사용하던 secret이나 유저의 비밀번호가 노출되는가?
    • 유저의 기밀 정보 조회를 위해 인증 토큰, 세션이 꼭 필요한가?

이렇게 일정 기준을 충족했고, 핵심 기능이 완성되었으면 main 브랜치로 배포를 할 수 있습니다.


dev 브랜치

다음 버전 배포를 위한 "개발 중!" 브랜치

dev 브랜치는 다음 버전 배포를 위한 "개발 중!" 브랜치입니다. main 브랜치에서부터 브랜칭을 하는 게 보통이며, 가능하면 프로젝트 팀원과 프론트엔드와 백엔드의 결과를 합쳐서 확인해 볼 수 있을 정도로 준비가 되어야 합니다. CI/CD 파이프라인이 잘 구축되어 있다면 dev 브랜치의 코드도 배포를 해두고 수시로 확인할 수도 있습니다.

main 브랜치와 dev 브랜치는 GitHub Repository에 늘 업데이트되어있어야 하며, 팀원의 코드 리뷰를 받고 진행하는 것이 정석입니다. 엄밀한 코드 리뷰가 어렵다면, 같이 모여서 코드에 대해서 이야기를 나누고, 배포 상황을 점검하는 스탠드업 회의를 열어도 좋습니다. 너무 격식이 있을 필요는 없지만, 가능하면 모든 팀원이 확인 가능하게 “어떤 코드의 어디를 왜 이렇게 바꿨으면 좋겠다.”라는 코멘트를 GitHub Pull Request에 남기는 것을 권장합니다.


보조 브랜치

feature 브랜치

feature 브랜치는 기능 개발, 리펙토링, 문서 작업, 단순 오류 수정 등 다양한 작업을 기록하기 위한 브랜치입니다. 분류를 세세하게 나누기를 원하는 회사에서는 refactor, fix, docs, chore와 같이 세세하게 커밋 메시지나 브랜치 명에 prefix를 달기도 합니다. 아래는 feature 브랜치 이름과 커밋 메시지의 예시입니다. 더 많은 사례는 Conventional Commits에 대해서 확인하실 수 있습니다.

hash (브랜치 명) 커밋 메시지
2f85eea (feat/create-todo) feat: Todo 추가 기능
2ad0805 (fix/var-name) fix: 변수 네이밍 컨벤션에 맞게 변수명 변경 (ismale => isMale)
e7ce3ad (refactor) refactor: 불필요한 for 루프 삭제

feature 브랜치는 보통 각 개인의 로컬 리포지토리에서 만들고 작업합니다. feature 브랜치는 기능 개발을 위한 브랜치이기 때문에 2명 이상 같이 작업하는 경우가 드물어서, 브랜치 생성이나 삭제에 대해서 너무 두려워할 필요는 없습니다. 작은 기능이라도 브랜치를 새로 만들고, 자주 커밋하고, 자주 원격 GitHub Repository에 push하여 팀원들과 결과를 공유하는 것이 바람직합니다. 개인 로컬 리포지토리에서 너무 오래 작업을 하다 보면, 쉽게 발견할 수 있는 오류도 발견이 되지 않곤 합니다. 더 나은 코드를 위해 피드백받는 것을 두려워하지 맙시다.

회사에 따라서 커밋 기록을 남기는 일반적인 rebase-and-merge, 기능마다 깔끔하게 커밋을 남기기를 원해서 커밋 기록을 정리하는 squash-and-merge 등 다양한 머지 전략이 있습니다. 이번 Pre-Project에서는 squash-merge 전략을 사용해 보고, Main-Project에서는 팀원 간 상의를 통해 머지 전략을 세우길 바랍니다. 많은 경우 feature 브랜치는 머지하고 나서 삭제하지만, 복원해야 할 필요성이 있는 경우는 남겨두기도 합니다.