개발자 Lim

GitLab-Flow 전략이란?

GitLab에서 제안한 효율적인 브랜치 관리 전략이다.

기존의 Git Flow나 GitHub Flow의 방식을 확장하여, 복잡한 프로젝트와 배포 환경에서도 안정적인 작업을 가능하게 하는 것이 특징이다.

GitHub Flow전략과 마찬가지로 Master 브랜치가 항상 배포 가능한 상태를 유지하며 

Git Flow전략과 마찬가지로 다양한 종류의 브랜치를 활용하여 작업을 분류 할 수 있다.

(간단한 경우) 브랜치 종류 

master : 항상 배포 가능한 상태를 유지하는 최종 브랜치
feature : 새로운 기능이나 버그 수정을 위한 브랜치 master 브랜치로부터 분기하며 master 브랜치로 병합된다.

방법

1. master 브랜치에서 작업을 시작하기 위한 feature 브랜치로 분기합니다.
2. feature 브랜치에서 작업을 시작하고 작은 단위로 쪼개 커밋합니다.
3. 작업이 완료된 코드는 리뷰 및 테스트를 하고 master 브랜치에 병합시킵니다.

(복잡한 경우) 브랜치 종류

master : 항상 배포 가능한 상태를 유지하는 최종 브랜치로 모든 배포 환경에 대한 공통 코드가 존재한다.
feature : 새로운 기능이나 버그 수정을 위한 브랜치 master 브랜치로부터 분기하며 master 브랜치로 병합된다.
environment : 특정 환경에 대응하는 브랜치 환경에 따라 여러개의 종류가 있을 수 있다.
- development : environment 브랜치 중 하나로 개발자들이 새로운 기능을 개발하고 초기 테스트를 진행하는 환경의 브랜치
- staging : environment 브랜치 중 하나로 실제 서비스 배포 전 마지막 테스트와 검증을 수행하는 환경의 브랜치
- production : environment 브랜치 중 하나로 실제로 사용자에게 서비스되는 프로덕션 환경의 코드를 담당하는 최종 브랜치

방법

1. master 브랜치에서 새로운 기능이나 수정이 필요한 부분에 대해 feature 브랜치를 생성하여 분기합니다.
2. feature 브랜치에서 작업을 시작하고 작은 단위로 쪼개 커밋합니다.
3. 작업이 완료된 코드는 PR 리뷰 및 테스트를 하고 master 브랜치에 병합합니다.
4. master 브랜치에 병합된 변경 사항을 development 브랜치, 환경에 반영합니다.
5. development 브랜치,환경에서 테스트가 성공적으로 수행되면 staging 브랜치,환경에 반영합니다.
6. 실제 서비스 배포 전 마지막 테스트와 검증을 수행하고 완료되면 최종적으로 production 브랜치,환경으로 병합합니다.

(특별한 경우) 브랜치 종류

master : 항상 배포 가능한 상태를 유지하는 최종 브랜치 모든 배포 환경에 대한 공통 코드가 존재한다.
feature : 새로운 기능이나 버그 수정을 위한 브랜치 master 브랜치로부터 분기하며 master 브랜치로 병합된다.
environment : 특정 환경에 대응하는 브랜치
- development : environment 브랜치 중 하나로 개발자들이 새로운 기능을 개발하고 초기 테스트를 진행하는 환경의 브랜치
- staging : environment 브랜치 중 하나로 실제 서비스 배포 전 마지막 테스트와 검증을 수행하는 환경의 브랜치
- production : environment 브랜치 중 하나로 실제로 사용자에게 서비스되는 프로덕션 환경의 코드를 담당하는 최종 브랜치
release : 특정 버전의 배포를 위한 브랜치, 특정 버전의 준비가 완료된 후 해당 브랜치를 프로덕션 브랜치로 병합하여 배포하게 된다.
hotfix : 프로덕션에서 발생한 긴급한 이슈를 해결하기 위한 브랜치 production 브랜치로부터 분기하며 수정 후에는 production과 master 브랜치 모두에 병합된다.

방법

1. master 브랜치에서 작업을 시작하기 위한 feature 브랜치로 분기합니다.
2. feature 브랜치에서 작업을 시작하고 작은 단위로 쪼개 커밋합니다.
3. 작업이 완료된 코드는 PR 리뷰 후 mater 브랜치에 병합합니다.
4. master 브랜치에서 release 브랜치로 분기 후 테스트와 검증을 수행합니다.
5. release 브랜치에 병합된 변경 사항에 테스트가 성공적으로 수행되면 master, development 브랜치, 환경에 반영합니다.
6. development 브랜치,환경에서 테스트가 성공적으로 수행되면 staging 브랜치,환경에 반영합니다.
7. 실제 서비스 배포 전 마지막 테스트와 검증을 수행하고 완료되면 최종적으로 production 브랜치,환경으로 병합합니다.
8. production 환경에서 발생한 긴급한 이슈는 hotfix 브랜치에서 긴급 수정하고 production 및 master 브랜치로 병합합니다.

장점

• 다양한 브랜치를 전략을 사용하여 작업을 분류하기 때문에 복잡한 프로젝트에 적합하다.
• 다양한 브랜치 전략으로 조합하여 사용할 수 있어 유연성이 높다.
• 지속적인 배포와 통합 master 브랜치에서 일어나는 모든 변경 사항은 즉시 테스트와 통합이 가능해지므로, 지속적인 통합(CI)와 배포(CD)를 가능하게 한다. 

단점

• 다양한 브랜치와 워크플로우를 관리해야 하므로 복잡성이 높다.
• 다양한 브랜치를 유지하고 관리하기 위한 비용이 발생할 수 있다.

언제 사용하면 좋은가?

1. 복잡한 프로젝트를 관리 해야할 때
2. 다양한 환경에서 배포해야 할 프로젝트인 경우
3. 지속적인 통합 및 배포 (CI, CD)환경의 구축이 필요한 프로젝트인 경우