본문 바로가기

Web Development/Problem Solving

[Problem Solving][git revert] 현업 Git 브랜치 전략: A 작업 일시 중단 후 B 작업 우선 배포

현업에서 개발 배포까지 완료된 A 작업을 잠시 중지하고, B 작업을 먼저 배포해달라는 요청을 받았습니다.
이 상황에서 제가 문제를 해결한 방법을 정리해 공유드립니다.

1. 브랜치 운영 구조

  1. main: 운영 배포 브랜치
  2. dev: 개발 서버 배포용 브랜치
  3. detail: 기능 개발 브랜치 (A, B 작업 진행)

2. 기존 작업 흐름

  1. detail 브랜치에서 A 작업 수행
  2. A 작업을 dev 브랜치로 머지 → 개발 서버 배포
  3. QA 후 main에 머지하여 운영 배포

3. 운영팀 요청

  1. A 작업을 운영에서 제외하고, B 작업을 먼저 반영해달라
  2. A 작업은 나중에 다시 적용할 예정

4. 해결을 위한 선택지

항목 git revert git reset
기능 커밋을 취소하는 반대 커밋 생성 커밋 자체를 제거
히스토리 유지됨 (되돌리는 커밋이 추가됨) 잘라냄 (되돌린 커밋은 사라짐)
협업 시 안전 (브랜치 공유에 적합) 위험 (강제 push 필요, 충돌 우려)
롤백 가능성 다시 revert하여 복구 가능 복구 어려움 (reflog 의존)

5. 선택한 방법: git revert

  • 이유
    • dev는 공용 브랜치이므로, reset 사용 시 강제 push가 필요해 위험
    • A 작업을 나중에 다시 살릴 계획이므로 revert가 유리

6. 구체적 작업 절차

  1. dev에서 A 작업 머지 커밋 되돌리기
    git checkout dev
    git log --oneline   # A 작업 머지 커밋 해시 확인
    git revert -m 1 <merge-commit-hash>
    git push origin dev
    
  2. detail 브랜치에서 dev 머지 (A 되돌림 동기화)
    git checkout detail
    git merge dev
    # 충돌 발생 시 해결 (A 작업 내역이 사라짐)
    git commit -m "Merge dev into detail to sync A revert"
    
  3. detail에서 B 작업 진행 및 dev에 반영
    # B 작업 수행 후
    git checkout dev
    git merge detail
    git push origin dev
    
  4. A 작업이 다시 필요할 경우 (되돌린 revert 되돌리기)
    git revert <revert-commit-hash>
    git push origin dev
    

7. 히스토리 흐름 요약

dev:
A1 --- A2 --- MergeA --- Revert(MergeA) --- Merge(B) --- Revert(Revert) ← A 복구

detail:
A1 --- A2 --- MergeA to dev
         \
          merge dev (A 작업 삭제됨) --- B 작업 --- Merge to dev