Git 브랜치 전략이란?
- Git 브랜치 전략은 프로젝트에서 Git 브랜치를 효율적으로 사용하기 위한 일련의 규칙과 가이드라인이다.
- 이는 주로 팀 또는 개발자 간의 협업을 원활하게 하고, 코드의 안정성을 유지하며,
버전 관리를 효과적으로 수행하기 위한 방법을 제시한다.
- 다양한 Git 브랜치 전략은 있으며, 프로젝트의 규모, 팀 구조, 배포 주기 등에 따라 선택할 수 있다.
Git 브랜치 전략이 필요한 이유
- 효율성 향상: 브랜치 전략은 여러 개발자 및 팀 간의 협업을 간소화하고 충돌을 방지하여 효율성을 향상시킵니다.
- 안정성 및 배포 관리: 주요 브랜치와 보조 브랜치를 구분함으로써 안정된 코드와 개발 중인 코드를 분리하여 안정적인 버전을 관리하고 배포할 수 있습니다.
- 기능 개발 및 버그 수정 추적: 각각의 기능이나 버그 수정은 별도의 브랜치에서 진행되므로 추적이 쉽고, 필요에 따라 독립적으로 테스트하고 배포할 수 있습니다.
- 코드 리뷰 및 품질 향상: 개발자들은 작은 범위에서 작업하고, 풀 리퀘스트를 통해 코드 리뷰를 수행함으로써 코드 품질을 높일 수 있습니다.
- 롤백 및 이력 관리: 브랜치 전략을 통해 특정 버전으로 롤백하거나, 각각의 작업을 추적하는 데 용이한 이력을 관리할 수 있습니다.
- 배포 주기 최적화: 브랜치 전략은 릴리스를 준비하고 배포하는 데 필요한 단계를 정의하여 프로젝트의 배포 주기를 최적화합니다.
Flow란?
직역하여 흐름이라는 의미
git+Flow는 'git에서 제공하는 브랜칭 기능을 활용한 변경 이력 관리 전략'이라고 이해하자!
Git-Flow
Git Flow는 Vincent Driessen이 제안한 Git 기반의 코드 브랜칭 전략 중 하나로, 큰 프로젝트에서 효과적인 협업 및 버전 관리를 위한 모델이다.
Git Flow의 5가지 브랜치
- master: 제품의 안정된 버전을 나타내는 브랜치. 배포 가능한 코드만을 유지.
- develop: 개발 중인 코드를 통합하는 브랜치. 새로운 기능이나 버그 수정이 포함된다.
- feature/기능: 새로운 기능을 개발하는 데 사용되는 브랜치. 각 기능은 개별 브랜치에서 개발되고 테스트된 후 develop 브랜치로 병합.
- release : 배포를 준비하는 데 사용되는 브랜치. QA 및 테스트를 수행하고 마지막 버그 수정을 추가한 후 master와 develop으로 병합.
- hotfix : master에서 발생한 버그를 수정하는 데 사용되는 브랜치. 수정 후 master와 develop으로 병합.
master와 develop가 중요한 매인 브랜치이고 나머지는 필요에 의해서 운영하는 브랜치이다.
Git Flow의 한계
웹 어플리케이션에는 적합하지 않다
Vincent Driessen은 A successful Git branching model을 작성하고 10년이 지난 2020년에 해당 포스팅 위에 반성의 글(Note of Reflection)을 적는다. 그 내용을 요약하면 아래와 같다.
Git-Flow는 등장하고 10년 넘게 표준처럼 자리잡고, 더 나아가 마치 만병통치약처럼 사용되었다. 현재는 Git으로 관리되는 인기있는 유형의 소프트웨어가 웹 어플리케이션으로 이동하고 있다. 웹 어플리케이션은 일반적으로 롤백되지 않고, 지속적으로 제공(Continuous Delivery) 되므로 여러 버전의 소프트웨어를 지원할 필요가 없다.
웹 어플리케이션은 내가(Vincent Driessen) 10년전 블로그 글을 쓸때에는 염두해둔 소프트웨어 유형이 아니다. 팀이 소프트웨어를 지속적으로 제공한다면, Git Flow 대신 Github Flow와 같은 더 단순한 워크플로우를 채택할 것을 제안한다.
그러나 명시적으로 버전을 관리해야하는 소프트웨어를 개발한다면, 여전히 Git Flow가 적합할 수 있다.
- Vincent Driessen -
웹 어플리케이션은 특성상 사용자는 항상 최신의 단일 버전만을 사용하게된다. 여러 버전을 병렬적으로 지원할 필요가 없는 것이다. 또한 웹 어플리케이션은 하루에 몇번이고 릴리즈될 수 있다. 이런 특성상 웹 어플리케이션 개발에 Git Flow는 다소 적합하지 않다.
GitHub-Flow
GitHub Flow는 GitHub에서 제안하는 간단하고 효율적인 협업 워크플로우이다.
위의 flow가 단순한 만큼 사용법도 단순하다. master 브랜치의 역할만 확실히 지켜진다면 다른 브랜치에 대해 관여를 하지 않는다.
즉, master 브랜치를 제외하고 feature, hotfix, bugfix 등등의 브랜치를 구분하지 않는다.
GitHub Flow 사용법
1. 브랜치 생성 및 변경 사항 커밋
- 새로운 기능이나 버그 수정을 위해 브랜치를 생성하고 해당 브랜치에서 작업을 수행합니다.
- 변경 사항을 커밋하여 로컬 브랜치에 저장합니다.
git checkout -b feature-branch
# 변경 사항 커밋
git commit -m "Implement new feature"2. 풀 리퀘스트 생성
- 변경 사항이 완료되면 GitHub 웹 인터페이스 또는 로컬에서 풀 리퀘스트(PR)를 생성합니다.
- PR에는 변경 내용과 이에 대한 설명을 포함합니다.
3. 코드 리뷰 및 토론
- 다른 개발자들은 PR을 리뷰하고 코멘트를 달 수 있습니다.
- 코드 리뷰를 통해 품질 향상과 팀 간 소통을 도모합니다.
- 필요에 따라 추가 커밋을 통해 수정을 진행합니다.
4. 풀 리퀘스트 병합
- 코드 리뷰가 완료되면 PR을 메인 브랜치(일반적으로 main 또는 master)에 병합합니다.
- 이 단계에서 자동으로 테스트가 수행되고, 충돌이 없을 경우에만 병합됩니다.
git checkout main
git pull origin main
git merge feature-branch5. 브랜치 삭제:
- 풀 리퀘스트가 병합되면 사용한 브랜치를 삭제합니다.
- 브랜치를 삭제하여 불필요한 브랜치가 쌓이는 것을 방지합니다.
git branch -d feature-branchGitHub Flow는 지속적인 통합(Continuous Integration, CI)과 함께 사용되어 빠른 피드백과 안정적인 코드 배포를 지원하며, 특히 민첩한 소프트웨어 개발 및 릴리스에 적합한 워크플로우입니다.
참고
https://brownbears.tistory.com/603
https://hudi.blog/git-branch-strategy/
이미지 : https://puleugo.tistory.com/107
