[GIT] GIT 전략 (1) - 일반 배포 프로세스

최근 회사 내에서 코드 관리 효율성을 높이기 위해 GIT 브랜치 전략을 새롭게 정립해보았다.

 

기존에는 브랜치 운영 방식이 명확하지 않아 협업이 비효율적이었고, 배포 과정에서도 혼선이 발생하는 경우가 있었다. 이를 해결하기 위해 새로운 Git 전략을 도입하고 정리한 내용을 공유해보려고 한다.

 

먼저, 1차로 일반적인 배포 프로세스를 정리하고, 이후 2차에서는 Hotfix 처리 방식을 다룰 예정이다.

 

또한, 이번 작업을 정리하며 Excalidraw라는 서비스로 브랜치 전략을 도식화했는데, 시각적으로 정리하기에 매우 유용한 도구였다. 추천할 만한 서비스인 것 같다.

Git 브랜치 전략 개요

기본 브랜치

기본적으로 운영되는 브랜치는 개발(Dev) → 스테이징(Stage) → 운영(Live) 흐름을 따릅니다.

• dev 브랜치 : 새로운 기능 개발이 이루어지는 브랜치. 모든 feature 브랜치는 여기에서 분기 후 병합됨.
• stage 브랜치 : 배포 전 최종 검수 및 QA, 버그 수정을 담당하는 브랜치.
• live 브랜치 : 실제 운영 환경에 배포되는 브랜치.

일회성 브랜치

일회성 브랜치는 특정 작업을 위해 단기적으로 생성되며, 작업 완료 후 기본 브랜치에 병합

• feature 브랜치 : 새로운 기능 개발을 위해 dev 브랜치에서 분기하여 작업 후 다시 dev에 병합.
• hotfix 브랜치 : 긴급한 버그 수정이 필요할 때 생성되는 브랜치. 수정이 완료되면 dev 브랜치로 병합하며, 일부 변경 사항을 즉시 적용해야 할 경우 cherry-pick을 활용하여 live에 선반영.

 

 

1. dev 브랜치 기반의 로컬 Feature 브랜치 생성

1-1. dev 브랜치 최신화

git checkout dev
git pull origin dev

 

1-2. dev 브랜치 기반으로 feature 브랜치 생성

git checkout -b <브랜치명>

-> feature 브랜치는, feature/<기능 관련명> 으로 짓도록..

ex) git checkout -b feature/login

 

 

2. 해당 feature 브랜치에서 작업

2-1. 현재 로컬 브랜치 확인

git branch

 

2-2. 위에서 만든 feature로 checkout 되어있지 않으면 해당 브랜치로 checkout

git checkout <브랜치명>

ex) git checkout feature/login

 

3. 작업한 내용 원격 feature 브랜치에 배포

3-1. 작업한 내용 dev 브랜치와 병합을 위해 로컬 dev브랜치 동기화

→ dev 브랜치로 이동 후

git checkout dev

 

3-2. 로컬 dev브랜치 최신화

git pull origin dev

만약 위 처럼 git 원격에 추가 반영된 사항이 있으면 로컬 dev로 가져옴

 

3-3. 위에서 작업하던 feature 브랜치로 이동 후

git checkout feature/login

 

3-4. 최신화 된 로컬 dev 브랜치와 병합

git merge dev

 

3-5. feature 브랜치 작업된 내용 staging agrea에 올린 후

git add .

※ 변경된 파일 전부다 반영하는 게 아니라면, . 대신 파일 경로 지정해줌
ex) git add /program/login.pro.php

 

3-6. staging area에 올린 파일들 커밋

git commit -m "<커밋 메세지>"

 

 

3-7. 원격 feature 브랜치로 push

git push origin feature/login

 

4. MR (Merge Request) 요청

4-1. Gitlab 이동

 

4-2. MR요청하려는 프로젝트로 이동 후

 

4-3. Merge requests 메뉴로 이동

 

4-4. New merge request 생성

 

4-5. 병합할 브랜치 선택

 

4-6. MR 생성