Git 실수 안전하게 되돌리기: 리버트, 리셋, 체크아웃 설명
Git 실수를 자신 있게 해결하세요! 이 가이드는 `git revert`, `git reset`, `git checkout`을 설명하여 커밋을 안전하게 되돌리고, 파일을 복원하며, 리포지토리 기록을 관리하는 방법을 안내합니다. 각 명령어를 언제 어떻게 사용하여 소중한 작업을 잃지 않고 오류를 수정하는지 배워보세요. 모든 Git 사용자에게 필수적인 내용입니다.
Git 실수를 안전하게 되돌리는 방법: Revert, Reset, Checkout 설명
Git 실수는 보통 생각보다 심각하지 않습니다. 잘못된 파일을 커밋했거나, 너무 많이 스테이징했거나, 공유 브랜치에 잘못된 변경 사항을 푸시했을 수 있습니다. 안전한 해결 방법은 한 가지 질문에 달려 있습니다: 변경 사항이 이미 공유되었습니까?
이 가이드는 git revert, git reset, git checkout을 언제 사용해야 하는지, 신중하게 복사할 수 있는 예제와 함께 설명합니다. 간단히 말하면 다음과 같습니다: 공유된 커밋에는 git revert를, 로컬 정리에는 git reset을, 브랜치를 전환하거나 이전 파일 상태를 복원할 때만 git checkout을 사용하세요.
먼저, 되돌리려는 내용을 확인하세요
실행 취소 명령을 실행하기 전에 현재 상태를 확인하세요:
git status
git log --oneline --decorate -5
git status는 스테이징되지 않았거나, 스테이징되었거나, 추적되지 않은 작업이 있는지 알려줍니다. git log는 최근 커밋과 브랜치가 가리키는 위치를 보여줍니다.
잃고 싶지 않은 로컬 작업이 있다면 먼저 빠른 안전 브랜치를 만드세요:
git branch backup-before-undo
이 브랜치는 잘못된 명령을 선택했을 경우 쉽게 돌아갈 수 있는 방법을 제공합니다.
이미 푸시된 커밋에는 git revert 사용
git revert는 이전 커밋의 반대를 적용하는 새 커밋을 만듭니다. 기록을 삭제하지 않으므로 main, develop 또는 다른 사람이 풀했을 수 있는 공유 브랜치에 가장 안전한 선택입니다.
히스토리가 다음과 같다고 가정해 보겠습니다:
A -- B -- C -- D main
커밋 C에 버그가 도입되었지만 D는 정상이며 유지되어야 합니다. 커밋 해시를 찾으세요:
git log --oneline
그런 다음 해당 커밋만 되돌리세요:
git revert abcdef1
Git이 되돌리기 커밋 메시지를 위해 편집기를 엽니다. 저장하면 히스토리는 다음과 같이 보입니다:
A -- B -- C -- D -- E main
커밋 E는 C의 변경 사항을 취소합니다. 모든 사람이 정상적으로 새 커밋을 풀 수 있습니다.
병합 커밋 되돌리기
병합 커밋에는 Git이 메인라인이 어떤 부모인지 알아야 하므로 추가 플래그가 필요합니다:
git revert -m 1 <merge-commit-hash>
main으로의 일반 병합의 경우 -m 1은 일반적으로 "첫 번째 부모 유지"를 의미하며, 이는 병합된 브랜치입니다. 여기서 추측하지 마세요. 먼저 다음을 실행하고 부모를 검사하세요:
git show --summary <merge-commit-hash>
어떤 부모를 유지해야 할지 확실하지 않다면 팀원에게 묻거나 임시 브랜치에서 되돌리기를 테스트하세요.
로컬 커밋에는 git reset 사용
git reset은 현재 브랜치 포인터를 이동합니다. 모드에 따라 스테이징 영역과 작업 파일도 변경할 수 있습니다. 주로 푸시하지 않은 커밋에 사용하세요.
파일 스테이징 취소
잘못된 파일을 스테이징했다면 파일 내용을 변경하지 않고 스테이징을 취소하세요:
git restore --staged unwanted_file.txt
오래된 Git 예제에서는 종종 다음과 같은 동등한 명령을 사용합니다:
git reset HEAD unwanted_file.txt
두 명령 모두 파일을 스테이징 영역에서 제거합니다. 편집 내용은 작업 디렉토리에 그대로 남아 있습니다.
마지막 커밋을 취소하지만 변경 사항은 스테이징 상태로 유지
커밋 메시지가 잘못되었거나 다시 커밋하기 전에 파일을 하나 더 추가하려면 --soft를 사용하세요:
git reset --soft HEAD~1
브랜치가 한 커밋 뒤로 이동하지만 해당 커밋의 변경 사항은 스테이징된 상태로 유지됩니다.
마지막 커밋을 취소하고 변경 사항을 스테이징되지 않은 상태로 유지
다시 커밋하기 전에 파일을 재작업하려면 기본 혼합 리셋을 사용하세요:
git reset HEAD~1
이 명령은 브랜치를 한 커밋 뒤로 이동시키고 변경 사항을 작업 디렉토리에 남깁니다.
로컬 커밋과 파일 변경 사항을 모두 삭제
--hard는 브랜치, 스테이징 영역 및 작업 디렉토리의 추적된 파일을 재설정합니다:
git reset --hard HEAD~1
삭제된 변경 사항이 필요하지 않다고 확신하는 경우에만 사용하세요. 추적되지 않은 파일은 제거하지 않지만, 추적된 파일의 편집 내용은 다시 묻지 않고 삭제합니다.
git checkout을 신중하게 사용
git checkout은 오래된 Git 워크플로에서 두 가지 일반적인 작업을 수행합니다: 브랜치 전환과 파일 복원입니다. 최신 Git 버전에서는 이러한 작업을 더 명확한 명령어로 분할했습니다: 브랜치 전환에는 git switch, 파일 복원에는 git restore를 사용하세요.
브랜치를 전환하려면:
git switch main
오래된 동등 명령:
git checkout main
추적된 파일 하나의 커밋되지 않은 변경 사항을 폐기하려면:
git restore my_file.txt
오래된 동등 명령:
git checkout -- my_file.txt
해당 파일 복원은 선택한 파일의 커밋되지 않은 편집 내용에 대해 파괴적입니다. 나중에 편집 내용이 필요할 수 있다면 먼저 스태시하세요:
git stash push -m "save work before restore"
너무 멀리 갔다면 git reflog 사용
git reset --hard를 실행했거나 실수로 브랜치를 이동했다면 git reflog가 여전히 HEAD가 가리키던 위치를 보여줄 수 있습니다:
git reflog
HEAD@{2}와 같은 이전 항목이나 리셋 이전의 커밋 해시를 볼 수 있습니다. 해당 항목에서 복구 브랜치를 만들 수 있습니다:
git branch recovery <commit-hash>
Reflog는 클론에 로컬이며 백업 시스템이 아니지만, 최근 실수에서 자주 구해줍니다.
어떤 명령을 선택해야 할까요?
잘못된 커밋이 이미 푸시되었거나 다른 사람이 해당 커밋을 기반으로 작업했을 수 있는 경우 git revert를 사용하세요.
마지막 로컬 커밋을 다시 실행해야 하지만 변경 사항이 여전히 올바른 경우 git reset --soft를 사용하세요.
마지막 로컬 커밋을 스테이징되지 않은 파일 변경 사항으로 되돌리려면 git reset을 사용하세요.
로컬 추적 변경 사항을 삭제해도 되는 경우에만 git reset --hard를 사용하세요.
특정 파일의 커밋되지 않은 변경 사항을 폐기하려면 git restore 또는 git checkout -- <file>을 사용하세요.
가장 안전한 습관은 git status를 확인하고, 위험이 클 때 임시 백업 브랜치를 만들고, 공유 기록을 다시 쓰지 않는 것입니다. 커밋이 공유 원격 저장소에 도달했다면 git revert가 일반적으로 가장 깔끔한 해결 방법입니다.