type
status
date
slug
summary
tags
category
icon
password
왜 필요 한가
- 코드 관리의 효율성>안정적인 프로덕션 환경
- 작업의 독립성> 코드 충돌 최소화
- 안정성 유지> 개발 속도 향상
- 코드 리뷰 및 품질 관리> 코드 품질 향상
- 배포 및 롤백의 용이성
Feature Branch
각 기능별로 독립적인 브랜치를 생성하여 작업
서로 작업에 영향을 주지 않고 효율적으로 협업
Github Flow
규모가 작거나 중간 크기의 프로젝트에 적합
빠른 개발 주기와 지속적인 배포에 초점
- 브랜치 생성
- 기준 브랜치에서 새로운 브랜치 생성
- 브랜치 명은 작업 내용을 설명하는 명칭
- 기준 브랜치는 항상 배포 가능한 상태
- 작업 진행
- 원격 저장소 push
- PR(PullRequest) 생성 -> 코드 리뷰 후 브랜치 병합, PR 종료
Git Flow
프로젝트 코드 관리와 릴리즈를 체계적으로 진행하는 방법론
- Master: 프로덕션 환경에 배포되는 안정적인 코드가 저장되는 브랜치
- Develop: 개발 중인 코드를 관리하는 브랜치
- Feature: 새로운 기능 개발을 위한 브랜치(Dev 브랜치로부터 분기)
- Release: 새로운 버전 릴리스를 준비하는 브랜치(Dev 브랜치로부터 분기)
- Hotfix: 긴급한 버그 수정을 위한 브랜치(Master 브랜치로부터 분기)
- 신규 기능 개발
- Develop 브랜치에서 Feature 브랜치 생성
- 기능 개발 완료 후 Develop 브랜치로 merge
- 릴리즈 준비
- Develop 브랜치에서 Release 브랜치 생성
- 버전 번호를 부여하고, 문서 작업 등 릴리즈와 관련된 작업 진행
- 릴리즈 확정
- Release 브랜치를 Master 브랜치로 merge
- 해당 커밋에 태그를 추가하여 릴리즈 버전 명시
- 이후 Release 브랜치는 Develop 브랜치로 merge
- 긴급한 버그 수정
- Master 브랜치에서 발견한 버그는 Hotfix 브랜치를 생성해서 수정
- 수정 완료 후 Master와 Develop 브랜치로 merge
Gitlab Flow
Git Flow의 복잡함과 Github Flow의 단순함을 보완한 브랜치 전략
master, feature, production 브랜치로 분류
- Feature
- 새로운 기능 개발을 위한 브랜치
- Master
- git flow develop 브랜치와 동일
- feature 브랜치에서 병합된 기능에 대해 test 수행
- Production
- gitflow의 master 브랜치와 동일한 배포 브랜치
- test를 진행시 pre-production 브랜치로 test서버에 배포하여 검증함
전략 선정 기준
- 프로젝트 규모
- 개발 팀의 구성
- 개발 및 배포 주기
- 코드 안정성
전략 | 특징 |
Feature Branch | 규모가 작거나 중간 크기의 프로젝트에 적합 |
ㅤ | 서로 다른 기능 개발이 동시에 이루어질 때 유용 |
ㅤ | 간단한 브랜치 전략을 사용하여 협업을 원할 때 적합 |
Github Flow | 규모가 작거나 중간 크기의 프로젝트에 적합 |
ㅤ | 지속적인 통합 및 배포를 원할 때 유용 |
ㅤ | 빠른 개발 주기와 간단한 브랜치 전략을 선호할 때 적합 |
Git Flow | 규모가 크고 복잡한 프로젝트에 적합 |
ㅤ | 여러 개발자들이 협업하고, 다양한 기능 및 릴리즈가 동시에 관리되어야 할 때 유용 |
ㅤ | 코드의 안정성과 릴리즈 관리를 체계적으로 수행하고자 할 때 적합 |
- 저자:Laigasus
- URL:https://laigasus.vercel.app/article/1
- 저작권:이 블로그의 모든 글은 특별한 언급이 없는 한 BY-NC-SA 계약을 채택합니다. 출처를 표시해주세요!