브랜칭 전략은
보다 효율적인 개발 프로젝트 코드 관리를 위해 브랜치의 종류를 나눠서 관리하는 전략
을 의미한다.
그 중 가장 유명한 전략이
Git flow
전략이다.Coz’ Git flow
기존의 Git flow에서 파생된 여러 버전 중 하나.
핵심 브랜치 - main, dev
main 브랜치 : 사용자에게 언제든 제품으로 출시 가능한 브랜치
master, production등 다양하게 불리는 브랜치. 핵심기능이 충족되었으면 main브런치로 배포할 수 있다.
dev 브랜치 : 다음 버전 배포를 위한 "개발 중!" 브랜치
main 브랜치에서부터 브랜칭을 하는게 보통이며, 가능하면 프로젝트 팀원과 프론트엔드와 백엔드의 결과를 합쳐서 확인해볼 수 있을 정도로 준비가 되어야 한다.
CI/CD 파이프라인이 잘 구축되어 있다면 dev 브랜치의 코드도 배포를 해두고 수시로 확인할 수 있다.
main 브랜치와 dev 브랜치는 Github 리포지토리에 늘 업데이트 되어있어야 하며, 팀원의 코드 리뷰를 받고 진행하는 것이 정석이다. 가능하면 모든 팀원이 확인 가능하게 “어떤 코드의 어디를 왜 이렇게 바꿨으면 좋겠다.”라는 코멘트를 Github Pull Request에 남기는 것을 권장한다.
보조 브랜치 - feature
feature 브랜치: 기능 개발, 리펙토링, 문서 작업, 단순 오류 수정 등 다양한 작업을 기록하기 위한 브랜치
분류를 세세하게 나누기를 원하는 회사에서는 refactor, fix, docs, chore와 같이 세세하게 커밋 메시지나 브랜치 명에 prefix를 달기도 한다. 아래는 feature브랜치의 이름과 커밋 메시지의 예시이다.
(추가적인 예시는 다음에서 확인한다.https://www.conventionalcommits.org/ko/v1.0.0/)
hash (브랜치 명) 커밋 메시지
2f85eea (feat/create-todo) feat: Todo 추가 기능
2ad0805 (fix/var-name) fix: 변수 네이밍 컨벤션에 맞게 변수명 변경 (ismale => isMale)
e7ce3ad (refactor) refactor: 불필요한 for 루프 삭제
-
feature 브랜치는 보통 각 개인의 로컬 리포지토리에서 만들고 작업한다.
(보통 기능개발을 위한 브랜치여서, 2명이상 같이 작업하는 일이 드물다. 따라서 너무 생성과 삭제에 무서워하지 말자.) -
작은 기능이라도 브랜치를 새로 만들고, 자주 커밋하고, 자주 원격 Github 리포지토리에 push하여 팀원들과 결과를 공유하는 것이 바람직하다.
(피드백을 두려워하지 말자)
