Git Branch 배포 전략

# Git Branch 배포 전략

 

Git에서 개발(dev), 스테이징(stg), 프로덕션(prd) 환경을 포함하는 워크플로우는 일반적으로 다음 단계를 기반으로 구성한다.

1. 개발 환경 (dev):

개발자들이 코드를 작성하고 테스트하는 곳이다.

각 개발자는 자신의 브랜치에서 작업하며, 이는 메인 브랜치('master' 또는 'main')의 복사본이다. 그리고 작업하면서 이 브랜치에 변경 사항을 커밋한다.

# 작업을 위한 새 브랜치 생성
git checkout -b feature_branch

# 변경 사항을 만들고 커밋
git add .
git commit -m "Commit message"

2. 스테이징 환경 (stg):

개발 하려는 기능이 완성되고 코드가 테스트되면, 변경 사항은 'develop' 또는 'staging' 브랜치로 병합된다. 이 환경은 프로덕션 환경과 거의 동일하게 구성한다. 코드가 프로덕션에 배포되기 전에 테스트와 품질 보증을 위해 사용된다.

# develop 또는 staging 브랜치로 전환
git checkout develop

# 작업 브랜치를 develop에 병합
git merge feature_branch

3. 프로덕션 환경 (prd):

스테이징 환경에서 철저한 테스트 후, 코드는 'master' 또는 'main' 브랜치로 병합되고, 그런 다음 프로덕션 환경에 배포되어 실제로 작동하게 된다.

# master 또는 main 브랜치로 전환
git checkout master

# develop 브랜치를 master에 병합
git merge develop

4. 풀 리퀘스트:

종종 'develop' 또는 'master'에 직접 병합하는 대신, 개발자들은 풀 리퀘스트를 연다. 이는 그들의 작업 브랜치를 다른 브랜치(일반적으로 'develop' 또는 'master')로 병합하려는 요청이다. 이를 통해 코드 리뷰와 추가적인 체크가 코드가 병합되기 전에 실행될 수 있다.

# 기능 브랜치를 원격 저장소로 푸시
git push origin feature_branch

# 그런 다음, Git 호스팅 서비스의 인터페이스를 통해 풀 리퀘스트가 열립니다 (예: GitHub)

이는 일반적인 워크플로우이지만, 팀의 성격과 프로젝트 구성에 따라 달라질수 있다.

5. 병합

병합은 결제를 올려서 결제가 난 뒤에 병합이 실행 되거나 팀 리더 및 결재권자가 코드를 확인 후 병합하는 케이스가 있다.

상황 및 프로젝트에 맞게 구성하면 된다.

 

- 끝 -