😱 Git Merge, 실수했다면? git revert로 안전하게 되돌리기
안녕하세요, 개발자 여러분!
팀 프로젝트에서 야심차게 개발한 기능을 main 브랜치에 머지(Merge)했는데... 앗! 😱 예상치 못한 치명적인 버그가 발견되어 긴급하게 배포를 되돌려야 하는 상황, 한 번쯤 겪어보셨을 겁니다.
이때 git reset으로 과거를 지워버리자니 이미 팀원들과 공유된 브랜치라 무섭고, 어떻게 해야 할지 막막하셨나요?
오늘은 이런 상황에서 우리의 히어로가 되어줄 git revert와, 특히 머지 커밋(Merge Commit)을 되돌릴 때 꼭 알아야 할 -m 옵션의 비밀에 대해 쉽고 자세하게 알아보겠습니다.
왜 머지 커밋 Revert는 특별할까요?
일반 커밋을 revert하는 것은 간단합니다. git revert <커밋_해시> 한 줄이면 끝이죠. Git이 해당 커밋의 변경 사항을 정확히 반대로 적용하는 새로운 커밋을 만들어주니까요.
하지만 머지 커밋은 부모(parent)가 두 개라는 점에서 다릅니다.
feature 브랜치를 main 브랜치에 머지한 상황을 생각해볼까요? 이 머지 커밋은 두 개의 부모를 가집니다.
- 부모 1: 머지되기 전 main 브랜치의 마지막 커밋
- 부모 2: 머지된 feature 브랜치의 마지막 커밋
이 때문에 git revert를 그냥 실행하면 Git은 혼란에 빠집니다. "두 부모 중 어떤 것을 기준으로 삼고, 어떤 부모로부터 온 변경 사항을 되돌려야 하지?" 라고 말이죠.
바로 이때, 우리가 Git에게 방향을 알려주는 나침반 역할을 하는 것이 -m (또는 --mainline) 옵션입니다.
실전! 머지 커밋 Revert 따라하기 (Step-by-Step)
자, 이제 feature/login 브랜치를 main에 머지했다가 되돌리는 시나리오로 직접 실습해보겠습니다.
STEP 1: 되돌릴 머지 커밋 찾기
가장 먼저, 문제의 머지 커밋을 찾아야 합니다. git log를 이용해 히스토리를 확인합시다.
git log --oneline --graph
다음과 같은 로그를 확인했다고 가정해봅시다.
* a1b2c3d (HEAD -> main) Merge branch 'feature/login'
|\
| * 7f8e9d0 (feature/login) Add login form validation
| * 6a5b4c3 Add login button
|/
* d4e5f6g Initial commit on main
여기서 우리가 되돌리고 싶은 범인은 a1b2c3d 머지 커밋입니다.
STEP 2: 주축(Mainline) 부모 번호 확인하기
이제 -m 옵션에 쓸 부모 번호를 알아낼 차례입니다. git show 명령어로 머지 커밋의 상세 정보를 확인합니다.
git show a1b2c3d
출력 결과 상단에 이런 정보가 보일 겁니다.
commit a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0
Merge: d4e5f6g 7f8e9d0
Author: Your Name <you@example.com>
Date: ...
Merge branch 'feature/login'
Merge: d4e5f6g 7f8e9d0 라인을 주목하세요!
- d4e5f6g: 첫 번째 부모 (parent 1) 입니다. 즉, main 브랜치의 커밋입니다.
- 7f8e9d0: 두 번째 부모 (parent 2) 입니다. feature/login 브랜치에서 온 커밋이죠.
우리는 feature/login에서 온 변경 사항을 없애고 싶으므로, main 브랜치의 히스토리를 주축(mainline)으로 유지해야 합니다. 따라서 부모 1번을 선택해야 합니다.
STEP 3: git revert 실행하기 ✅
이제 모든 준비가 끝났습니다. -m 1 옵션과 함께 revert 명령을 실행합니다.
# git revert -m <주축_부모_번호> <되돌릴_머지_커밋>
git revert -m 1 a1b2c3d
이 명령을 실행하면, Git은 feature/login 브랜치를 통해 추가되었던 모든 변경 사항을 제거하는 새로운 커밋을 생성합니다. 커밋 메시지 편집기가 나타나면, 왜 되돌렸는지 명확한 이유를 적고 저장하면 작업 완료!
git log를 다시 확인해보면, Revert "Merge branch 'feature/login'" 이라는 새로운 커밋이 main 브랜치에 안전하게 추가된 것을 볼 수 있습니다.
⚠️ 가장 중요한 주의사항: 되돌린 브랜치, 다시 머지할 때
"좋아, 버그는 해결했고... 이제 feature/login 브랜치를 수정해서 다시 머지해야지!" 라고 생각하셨나요? 여기서 아주 중요한 함정이 있습니다.
문제점: 한 번 revert된 머지에 포함됐던 커밋들(6a5b4c3, 7f8e9d0)은 main 브랜치 입장에서 "이미 히스토리에 포함되었다가 되돌려진 내역"으로 기록됩니다. 그래서 나중에 수정된 feature/login 브랜치를 다시 머지하려고 하면, Git은 이전에 되돌렸던 커밋들의 변경 사항을 누락시킨 채 머지합니다.
해결책: "Revert를 Revert하라!" 이 문제를 해결하는 가장 깔끔한 방법은, 원래의 feature 브랜치를 다시 머지하기 전에, 이전에 했던 revert 커밋을 또다시 revert 해주는 것입니다.
- main 브랜치에서 feature/login 머지를 되돌린 revert 커밋을 찾습니다. (예: r1e2v3t)
- 이 revert 커밋을 다시 revert 합니다.
unfold_lessbashcontent_copyterminal
# Revert 커밋을 되돌려서, 과거의 feature/login 변경사항을 다시 복원 git revert r1e2v3t - 이제 main 브랜치는 feature/login의 변경 사항을 다시 받아들일 준비가 되었습니다.
- 수정된 feature/login 브랜치를 main에 머지합니다.
unfold_lessbashcontent_copyterminal
이제 모든 변경 사항이 정상적으로 포함됩니다!git merge feature/login
마치며: 오늘의 핵심 정리
git revert는 공유 브랜치의 히스토리를 깔끔하고 안전하게 관리할 수 있는 강력한 도구입니다. 머지 커밋을 되돌릴 때 오늘 배운 내용을 꼭 기억하세요!
- 머지 커밋 Revert: git revert -m 1 <머지_커밋_해시>
- 안전성: revert는 히스토리를 지우지 않고, 변경을 되돌리는 새로운 커밋을 생성합니다.
- 재머지(Re-merge) 시: 반드시 "Revert 커밋을 다시 Revert" 하는 패턴을 기억하세요.
이제 실수로 잘못된 브랜치를 머지해도 당황하지 않고, 전문가처럼 우아하게 대처할 수 있겠죠?
Happy Coding! 🚀
'GitHub' 카테고리의 다른 글
| 🚀 GitLab CI/CD 파헤치기: 프론트엔드 자동 배포 가이드 (0) | 2025.04.22 |
|---|---|
| 프론트엔드 Github Flow 관리 (3) | 2024.09.04 |
| 깃허브 다운 후 브랜치 생성 및 다운 (0) | 2023.08.08 |
