운영 미배포 작업을 보류 브랜치로 분리해 관리하는 방법

운영 배포 전 main에만 올린 작업을 취소해야 하는데, 이미 개발 환경 배포 브랜치에는 반영돼서 그쪽은 건드릴 수 없는 상황. 별도 보류 브랜치에 작업을 먼저 백업한 뒤, main에서는 git revert로 되돌리고, 운영 배포 시점에 보류 브랜치를 다시 합치는 방식으로 해결한다.

 

 

 

배경

배포 흐름이 아래처럼 분리된 환경을 가정한다.

• feat/* → main → 개발 배포 브랜치 → 개발 환경 배포
• feat/* → main → 운영 배포 브랜치 → 운영 환경 배포

작업을 main에 올리고 개발 배포 브랜치까지 merge해 개발 환경에는 이미 반영됐지만, 운영 배포 브랜치에는 아직 merge하지 않은 시점에 다음 배포 일정이 미뤄지는 경우가 있다. 이때 main은 다음 운영 배포 전까지 깨끗한 상태를 유지해야 하므로, 해당 작업만 main에서 제외하면서도 이미 배포된 개발 환경은 그대로 둬야 한다.

 

단순히 git reset --hard로 되돌리면 이미 push한 공유 브랜치의 히스토리가 삭제돼 위험하다. 대신 히스토리를 보존하면서 변경만 반대로 적용하는 git revert를 쓴다.

 

 

 

준비물

• 작업이 올라간 main 커밋 해시 (git log main --oneline으로 확인)
• 작업을 보관할 보류 브랜치 (예: feat/hold) — 없으면 새로 생성
• 로컬 저장소에 main, 개발 배포 브랜치, 보류 브랜치에 대한 push 권한

 

 

절차

1단계: 보류 브랜치에 작업 백업

운영 배포 전까지 작업을 보관할 브랜치로 이동해, main에 올렸던 작업 커밋을 cherry-pick으로 가져온다.

git checkout feat/hold
git cherry-pick <main에 올린 작업 커밋해시>
git push origin feat/hold

확인 방법: git log feat/hold --oneline에 해당 커밋이 보이면 백업 완료.

 

2단계: main에서만 작업 되돌리기

main을 최신 상태로 받은 뒤, 해당 커밋을 revert한다. 작업 커밋이 여러 개면 최신 커밋부터 하나씩 revert한다.

git checkout main
git pull origin main
git revert <작업 커밋해시> --no-edit
git push origin main

--no-edit은 revert 커밋 메시지를 편집기 없이 기본값으로 바로 쓰겠다는 옵션이다. 머지 커밋을 revert해야 하는 경우엔 부모 브랜치 기준을 지정해야 한다.

git revert -m 1 <머지커밋해시> --no-edit

-m 1은 merge 시 main 쪽(첫 번째 부모) 기준으로 되돌린다는 의미다.

확인 방법: git log main --oneline에 Revert "..." 커밋이 새로 생기고, 해당 변경분이 코드에서 사라졌는지 확인.

 

3단계: 개발 배포 브랜치는 그대로 둔다

개발 환경에는 이미 반영된 상태이므로 아무 작업도 하지 않는다. 운영 배포 전까지 main → 개발 배포 브랜치 merge 자체를 하지 않는 것이 중요하다. revert가 그쪽에 들어가면 개발 환경에서 해당 기능이 사라질 수 있다.

확인 방법: 개발 배포 브랜치의 최근 merge 로그에 main의 revert 커밋이 포함되지 않았는지 확인.

 

4단계: 운영 배포 시점에 다시 합치기

운영 배포 일정이 오면, 보류 브랜치를 main에 merge하고, 이어서 운영 배포 브랜치로 merge한다.

git checkout main
git merge feat/hold
git push origin main
# 이후 운영 배포 브랜치로 merge

확인 방법: main에 보류 브랜치의 커밋이 다시 들어왔는지, revert로 빠졌던 변경이 복원됐는지 코드 diff로 확인.

 

 

정리

1. 운영 미배포 작업은 처음부터 보류 브랜치에서 진행하고, 배포 시점에만 main으로 merge하는 흐름을 기본으로 삼는다
2. git revert는 히스토리를 지우지 않고 변경만 반대로 적용하므로, 이미 push한 공유 브랜치에서는 reset --hard보다 항상 안전하다
3. revert 대상은 내 작업 커밋만이며, 단순히 원격 브랜치를 동기화한 merge 커밋은 되돌릴 필요 없다
4. 브랜치 작업 외에, 프론트엔드 변경이 있었다면 push 전 최소한 빌드 검사(예: pnpm build — 타입 검사 + 프로덕션 빌드)로 컴파일 오류 여부를 확인하는 과정도 함께 거쳐야 한다