🚀Git-Flow / branch Strategy

Dabi·2023년 3월 31일

GITHUB-FLOW SCM VCS git git flow gitlab-flow

형상관리

목록 보기

1/1

📖 1. Definition

브랜치 전략은 여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용하기 위한 워크플로우이다.

기존의 형상관리에 브랜치 전략을 도입시킨다면 , 여럿이 함께 관리하는데 있어 공통된 규약을 지키기만 하면 되기 때문에 코드를 작성하고 저장하고 관리하는데 드는 많은 비용을 절감할 수 있다.

이러한 브랜치 전략의 종류로는 Github-flow, git-flow, gitlab-flow 등이 있다.

이중 git-flow를 해당 flow가 지닌 branch 위주로 설명해보고자 한다.

🌈 2. Branch의 종류

⚪ 2.1. Main Branch

원격 저장소에는 수명이 무한한 두 가지 메인 브랜치가 존재한다.

바로 main(master) 브랜치와 develop 브랜치이다.

main(master) 브랜치와 develop 브랜치는 본래 이름 그대로 사용하는 경우가 일반적이다.

🔵 2.1.1. main(master) branch

제품으로 출시 될 수 있는 브랜치
main에서는 사용자에게 배포 가능한 상태만을 관리
배포(release) 이력을 관리하기 위해 사용

🟠 2.1.2. develop branch

다음 출시 버전을 개발하는 브랜치
기능 개발을 위한 브랜치(feature)들을 병합하기 위해 사용
직접적인 기능개발이 이루어 지지 않음 (commit&push ❌ | Pull&Merge request ⭕)
main으로부터 파생, 모든 기능이 추가되고 버그가 수정되어 배포가능한 안정적인 상태라면 develop을 main에 merge(병합)

🔘 2.2. Supporting Branch

Supporting 브랜치는 특별한 이유가 없는 한 main 혹은 develop에 반영된 후 삭제되므로,

유한한 수명을 가진다.

삭제되어도 해당 커밋들은 이미 develop 혹은 main에 올려보내졌기 때문에 유실되지 않는다. (revert, reset 가능)

Supporting 브랜치를 통해 구성원간의 수평적인 동시개발, 쉬운 기능 추적이 가능하다.

supporting 브랜치의 종류는 세가지가 있다.

💗 2.2.1. feature branch

기능을 개발하는 브랜치
feature 브랜치는 새로운 기능 개발 및 버그 수정이 필요할 때마다 develop 브랜치로부터 분기
feature 브랜치에서의 작업은 기본적으로 공유할 필요가 없기에 보통 로컬에서 관리
develop 으로부터 파생, 해당 기능 개발 건이 완료되면 develop 브랜치로 merge

네이밍 규칙은 feature/{기능요약} 의 형식을 가장 많이 사용한다.
이슈추적을 사용한다면 다음과 같은 형식을 따른다. feature/{issue-number}-{feature-name}

Feature branch flow

develop 브랜치에서 새로운 기능에 대한 feature 브랜치를 분기한다.

새로운 기능에 대한 작업을 수행한다.

작업이 끝나면 develop 브랜치로 merge한다.

이미 사용되지 않는데 남아있는 브랜치가 많다면 작업에 혼란을 줄 수 있으므로
특별한 상황이 아닌 이상 merge와 함께 해당 브랜치를 삭제한다.
(해당 브랜치를 삭제하여도 해당 브랜치의 commit 들은 상위 브랜치에 반영되고 저장되므로
삭제한다고 유실되는 것은 없음)

새로운 기능 개발이 필요하게 되면 다시 1번부터 시작한다.

# develop 브랜치에서 생성
$ git checkout -b feature/login develop

🟢 2.2.2. release branch

이번 출시 버전을 준비하는 브랜치, 해당 release가 종료 되면 삭제
배포를 위한 전용 브랜치를 분기해주면, 한팀이 해당 배포를 준비하는 동안 다른팀은 다음 배포를 위한 기능개발을 계속할 수 있다.

( ex_ A팀은 3버전 출시 / B팀은 3-2버전 개발)

release 브랜치는 배포를 위한 최종적인 버그 수정, 문서 추가 등 배포와 직접적으로 관련된
작업을 수행한다.
release 브랜치는 develop 으로부터 파생, 버그픽스 및 QA, 테스트를 마친 후 출시준비가 완료되면, develop과 main으로 반영
네이밍 규칙은 release-{x}.{y}.{z} 의 형식을 따른다.

🔴 2.2.3. hotfix branch

출시 버전에서 발생한 버그를 수정하는 브랜치
배포한 버전에 긴급한 수정건이 발생할 경우, master에서 분기하는 브랜치
수정 완료 후, master와 develop에 반영
버그 혹은 수정사항이 발생하여, 배포한 버전을 유지보수해야하는 경우, develop 브랜치에서
수정하여 배포하기에는 시간이 많이 소요됨
태그 네이밍은 hotfix-{x}.{y}.{z}의 형식을 따른다.

hotfix branch flow

배포한 버전에 긴급하게 수정할 부분 발생 ⇒ master 브랜치에서 hotfix 브랜치 분기

문제가 되는 부분 수정 후, master 브랜치에 merge하고 배포

❗❗❗hotfix 브랜치에서의 변경 사항은 develop 브랜치에도 merge한다.❗❗❗

🎫 3. GIT TAG

🔎 3.1. TAG 조회하기

해당 프로젝트에 태그가 존재한다면 git tag 명령어로 이미 존재하는 태그를 확인할 수 있음
-l 옵션을 이용해 git tag -l "v3.1*" 과 같이 3.1 버전대의 모든 태그를 조회할 수 있음
태그와 태깅된 커밋의 SHA-1 체크섬을 같이 보는 경우 git show-ref --tags를 사용

📋 3.2. TAG 생성하기

태그에는 Lightweight 태그, Annotated 태그가 존재

Lightweight 태그의 경우 git tag [tag명] 으로 생성 (현재까지 커밋한 상태에 태깅)
Annotated 태그의 경우 tag -a 옵션을 통해 남길 수 있으며, 작성자, 이메일 , 태깅날짜 ,태그메시지까지 남길 수 있음. 태그메시지의 경우 -m 옵션을 사용
특정 커밋에 태그를 남기고자 한다면, git log 를 통해 해당 커밋의 SHA-1 체크섬 밸류를 조회한 뒤, git tag -a [태그명] [대상 커밋의 체크섬값] 형식으로 사용 가능