Git 변경 사항 취소와 복구

지금까지는 이상적인 상황을 살펴봤습니다. 코드를 작성하고 커밋한 다음 Pull Request를 만드는 경우죠. 하지만 실제로는 파일을 추가하는 걸 깜빡하거나 커밋 메시지에 오타를 내거나, 방향을 잘못 잡는 일도 흔합니다. 이 글에서는 IDE 도구를 사용해 자주 겪는 문제를 해결하는 방법을 알아봅니다.

예시와 화면 캡처는 JetBrains IDE 기준이며, 사용 중인 버전에 따라 메뉴 이름과 위치가 다를 수 있습니다. 연습에는 별도의 학습용 저장소를 사용하세요. 실제 프로젝트에서는 해당 프로젝트의 브랜치, 커밋, 변경 사항 전송 규칙을 따르세요.

프로젝트에서 Claude Code를 사용할 때 저장된 기록은 이전 상태를 복구하는 데 도움이 됩니다. 하지만 Git은 키 입력 하나하나를 저장하지 않으므로 커밋하지 않은 변경 사항은 사라질 수 있습니다. 되돌리기 전에 브랜치와 선택된 파일, 필요한 복사본이 있는지 확인하세요.

Rollback - 로컬 변경 사항 되돌리기

상황: 파일을 수정했는데 변경 사항이 모두 잘못됐다는 걸 깨달았습니다. 마지막 커밋 상태로 빠르게 되돌리고 싶습니다.

Rollback 기능을 사용하세요:

1. 왼쪽 패널에서 Commit 탭을 여세요.
2. 목록에서 되돌릴 변경된 파일을 찾으세요. 여러 파일을 선택해도 됩니다.
3. 마우스 오른쪽 버튼을 클릭한 다음 Rollback을 선택하세요 (또는 둥근 화살표 아이콘을 누르세요).

IDE는 선택한 로컬 변경 사항이 사라진다고 경고합니다. 먼저 diff를 살펴보고 필요한 내용은 저장하세요. 정말 버리려는 변경 사항에만 Rollback을 적용한 뒤 결과를 확인하세요. 이 기능은 커밋하지 않은 작업을 삭제할 뿐, 백업하지 않습니다.

Amend - 마지막 커밋 보완하기

상황: 방금 Commit을 눌렀는데 중요한 파일(예: 업데이트한 테스트)을 포함하지 않았거나 메시지에 오타를 냈다는 걸 알아챘습니다. 아직 커밋을 공유하지 않았다면 Amend를 사용할 수 있습니다. 수정용 커밋을 별도로 만드는 방법도 괜찮으며, 이미 공유된 기록이라면 특히 그렇습니다.

공유하지 않은 커밋을 보완하려면 Amend(보완/수정) 기능을 사용하세요:

1. Commit 창에서 빠뜨린 파일을 수정하고 파일 옆에 체크 표시를 하세요.
2. Commit Message 패널에서 Amend 체크박스를 찾으세요 (또는 톱니바퀴 아이콘 -> Amend Commit을 선택하세요).
3. IDE가 이전 커밋 메시지를 가져옵니다. 필요하면 수정하세요.
4. Commit을 누르세요.

Amend는 기존 커밋을 다른 식별자를 가진 새 커밋으로 대체합니다. 기존 객체를 제자리에서 수정하는 것은 아닙니다. 이전 커밋을 이미 전송했고 다른 사람도 사용 중이라면 별도의 수정 커밋을 만드는 편이 보통 더 낫습니다.

자세한 내용은 JetBrains 공식 튜토리얼을 참고하세요.

Undo Commit

상황: 커밋을 만들었지만 Push로 아직 전송하지는 않았습니다. 너무 서둘렀다는 걸 깨달았고, 변경 사항은 편집기에 남겨 둔 채 커밋만 기록에서 없애고 싶습니다.

Undo Commit 기능을 사용하세요:

1. 아래쪽의 Git -> Log 탭을 열어 기록을 확인하세요.
2. 전체 그래프의 맨 위 항목이 아니라 현재 브랜치의 마지막 커밋(HEAD)을 찾아 컨텍스트 메뉴를 여세요.
3. Undo Commit을 선택하세요.

변경 목록(보통 Default Changelist)을 선택하고 OK를 누르세요. 커밋은 기록에서 사라지고 파일은 변경됨 상태로 Commit 창에 돌아옵니다. 작업 내용을 잃지 않았으니 계속 코드를 작성하면 됩니다.

Reset - 브랜치 이동과 파일 상태

Reset Current Branch to Here... 기능은 브랜치 포인터를 선택한 커밋으로 옮깁니다. 상황에 따라 최근 작업을 부드럽게 취소할 수도 있고 잘못된 코드를 완전히 지울 수도 있는 강력한 도구입니다.

상황 A - 최근 로컬 커밋 취소

Push하기 전에 로컬에서 커밋을 몇 개 만들었는데, 이 작업 흐름 전체가 잘못됐다는 걸 깨달았습니다.

1. Git -> Log 탭을 여세요.
2. 돌아가고 싶은 마지막 정상 커밋을 찾으세요 (잘못된 커밋들이 이어지기 전의 커밋입니다).
3. 해당 커밋을 마우스 오른쪽 버튼으로 클릭하고 Reset Current Branch to Here...를 선택하세요.

상황 B - 서버 상태로 되돌리기

원격 브랜치를 기준으로 추적 중인 파일을 복구하려고 합니다. 먼저 필요한 로컬 작업을 저장하고 Fetch를 실행하세요. origin/main 표시는 서버의 계속 갱신되는 상태가 아니라 마지막으로 가져온 시점의 상태를 나타냅니다. 충돌이 생긴 작업이 진행 중이라면 먼저 충돌을 해결해 작업을 마치거나 작업을 취소하세요. Hard를 만능 해결책처럼 사용하지 마세요.

1. Git -> Log를 여세요.
2. 원격 브랜치 표시를 찾으세요. 보통 보라색 레이블이 붙은 커밋이며, origin/main (또는 origin/your_branch_name)으로 표시됩니다. 서버에서 마지막으로 확인한 코드 상태입니다.
3. 해당 커밋을 마우스 오른쪽 버튼으로 클릭하고 Reset Current Branch to Here...를 선택하세요.

Reset 모드

Reset 창에서 모드를 신중하게 선택하세요. 세 가지 모드 모두 현재 브랜치를 선택한 커밋으로 옮기지만, 인덱스와 작업 파일을 다루는 방식은 다릅니다:

• Soft는 작업 파일과 인덱스를 유지합니다. Mixed는 작업 파일을 유지하면서 인덱스를 선택한 커밋 상태로 맞춥니다. 따라서 차이는 스테이징되지 않은 상태로 남습니다. 둘 다 파일 내용을 보존하지만 서로 다른 모드입니다.
• Hard는 인덱스와 추적 중인 파일을 선택한 커밋 상태로 맞추며, 커밋하지 않은 변경 사항은 삭제합니다. 관련 없는 일반 untracked 파일은 남을 수 있지만 복구를 방해하는 경로는 삭제될 수 있습니다. 커밋이 모든 저장소에서 즉시 사라지는 것은 아니지만 나중에 작업을 되살릴 수 있다고 기대해서는 안 됩니다.

Push 후에는 어떻게 할까요

상황: push한 뒤에야 실수를 발견했습니다.

커밋이 서버에 올라가면 프로젝트의 공유 기록에 포함됩니다. Reset이나 Amend로 기록을 다시 쓰면 동료에게 큰 문제가 생길 수 있습니다. 동료가 이미 변경 사항을 내려받아 그 위에서 작업을 시작했을 수도 있으니까요.

올바르고 안전한 해결 방법: 실수를 수정하는 새 커밋을 만들고 평소처럼 push하세요. 일반적인 방법입니다. 잘못된 코드 뒤에 알아보기 쉬운 수정 커밋이 이어지는 선형 기록이면 프로젝트의 변화 과정을 팀 전체가 쉽게 파악할 수 있습니다.

IDE에는 Revert Commit 기능도 있습니다. Git -> Log에서 잘못된 커밋을 마우스 오른쪽 버튼으로 클릭하고 Revert Commit을 선택하면 IDE가 새 "역커밋"을 만듭니다. 예를 들어 이전 커밋에서 추가한 줄을 삭제하는 식으로 반대 변경을 적용합니다.

Revert는 새 커밋으로 이미 공유한 변경 사항을 취소할 때 유용합니다. 코드와 텍스트 모두에 적용할 수 있지만 이후 변경 사항과 충돌할 수도 있습니다. 충돌을 해결한 뒤 결과를 확인하세요. 변경 사항이 복잡하게 얽혀 있다면 별도 수정 커밋이 더 명확할 때도 있습니다.

Stash / Shelve - 변경 사항 잠시 보관하기

상황: 새 기능을 한창 개발 중이라 파일 목록이 온통 빨간색과 파란색입니다. 그런데 팀 리드가 갑자기 "하던 일은 잠시 멈추고 main 브랜치의 버그부터 급히 고쳐 주세요"라고 합니다. 아직 충돌할 수 있는 변경 사항이 남아 있어 main으로 전환할 수 없습니다. 프로젝트 규칙에 따라 임시 로컬 커밋을 만들 수도 있지만, 지금 커밋하기 어렵다면 작업을 잠시 미뤄 둘 수 있습니다.

작업을 임시 보관함에 넣어 두면 됩니다. Git에서는 이를 Stash라고 하고, IDE에는 별도의 Shelve 기능이 있습니다 (선반에 올려 둔다는 뜻입니다).

1. Commit 창을 열고 변경된 파일을 선택하세요.
2. Shelve Changes...를 선택하세요. 이 단계는 Shelve에 해당하며 Git Stash는 별도로 실행합니다.
3. 나중에 알아볼 수 있는 이름을 입력하고 Shelve를 누르세요.

Shelve한 다음 남아 있는 파일을 확인하세요. 필요한 변경 사항이 모두 보관됐나요? 이제 main으로 전환해 버그를 수정하고 프로젝트 규칙에 따라 결과를 저장할 수 있습니다. 그런 다음 작업 브랜치로 돌아와 Shelf를 열고 Unshelve를 선택하세요.

Git Stash를 사용할 때는 별도의 stash 목록에서 필요한 항목을 복원하세요. Shelve와는 다른 저장소입니다. 일반 stash에는 추가 옵션 없이는 새 untracked 파일이 포함되지 않으므로 브랜치를 전환하기 전에 필요한 작업이 모두 보관됐는지 확인하세요. 복원 중 충돌이 생길 수 있으니 완료 후 파일을 다시 살펴보세요.

로그를 활용한 심화 작업

Git -> Log 창은 단순한 커밋 목록이 아닙니다. 변경 내역을 추적하는 데 유용한 도구입니다.

• 커밋 해시는 a1b2c3d처럼 문자와 숫자로 이뤄진 문자열입니다. 코드 스냅샷마다 고유한 식별자가 있습니다.
• 브랜치, 작성자, 날짜, 커밋 메시지의 단어로 기록을 필터링하면 특정 부분을 누가 언제 작업했는지 빠르게 찾을 수 있습니다.
• 특정 코드 줄이 추가되거나 삭제된 커밋을 찾으려면 Log 창에서 메시지뿐 아니라 변경 내용도 검색할 수 있습니다.
• 편집기 여백 (줄 번호가 표시되는 곳)을 마우스 오른쪽 버튼으로 클릭하고 Annotate with Git Blame을 선택하세요. IDE가 각 줄 옆에 마지막으로 수정한 사람과 커밋을 표시합니다. 이어서 해당 커밋과 관련 논의를 확인하세요. Blame은 줄의 마지막 수정 내역만 보여 줄 뿐, 수정한 이유까지 설명하지는 않습니다.

주의가 필요한 작업 - Force Push

이미 전송한 커밋을 수정하는 건 좋지 않다고 했습니다. 그런데 Undo Commit이나 Amend로 로컬 기록을 바꿨지만 서버에는 이전 버전이 남아 있다면 어떨까요? 일반 push는 공유 기록을 덮어쓰지 않도록 오류를 표시합니다.

Force push는 새 기록이 이전 기록을 이어 가지 않더라도 선택한 원격 참조를 교체합니다. 서버 전체를 지우는 것은 아닙니다. 결과는 전송하는 참조에 따라 달라지며, 브랜치 보호 규칙이 이런 전송을 막을 수도 있습니다.

Force push를 하면 원격 브랜치에서 로컬 기록에 없는 커밋이 사라질 수 있습니다. 따라서 공유 브랜치의 기록을 다시 쓰려면 팀과 별도로 합의해야 합니다. 일반적인 수정에는 새 커밋이나 Revert를 사용하세요.

Force push를 논의할 만한 일반적인 경우는 기록을 다시 쓰기로 합의한 뒤 자신의 브랜치에 적용하는 상황입니다. 이때도 다른 사람이 추가한 새 커밋이 없는지 확인하세요. --force-with-lease는 원격 브랜치가 예상한 상태인지 확인하지만, 어떤 커밋이 교체될지 이해해야 한다는 점은 달라지지 않습니다.

화면 캡처에서 Force Push는 Push 버튼의 드롭다운 메뉴에 있습니다. 사용하기 전에 현재 IDE 버전이 어떤 강제 전송 모드를 적용하는지 확인하세요.

무엇을 하는지 100% 확신할 수 없다면 force push를 사용하지 마세요. 수정 사항을 담은 새 커밋을 만들거나 Revert를 사용하는 편이 안전합니다.

프로젝트 업데이트

새 작업을 시작하기 전에 기준 브랜치와 아직 끝나지 않은 변경 사항을 확인하세요. 필요할 때 업데이트를 가져오고 병합 결과를 살펴보세요. Update Project를 실행해도 충돌이 없다고 보장할 수는 없습니다. 설정에 따라 merge 또는 rebase를 사용할 수 있습니다.

업데이트한 뒤에는 현재 브랜치와 커밋 목록, 파일 상태를 확인하세요. 충돌이 생겼다면 작업을 계속하기 전에 해결해야 합니다.

Git Log 컨텍스트 메뉴

Git -> Log 탭을 열어 커밋을 마우스 오른쪽 버튼으로 클릭하면 여러 명령이 담긴 컨텍스트 메뉴가 나타납니다. 용도별로 묶어 유용한 명령을 살펴보겠습니다.

그룹 1 - 조회와 분석 (안전한 작업)

• Copy Revision Number는 커밋의 고유 해시를 클립보드에 복사합니다. 동료에게 커밋 링크를 보내거나 작업 항목(Jira, YouTrack)에 기록할 때 유용합니다.
• Compare with Local은 이전 커밋의 파일 상태와 현재 편집기 내용을 비교합니다. 한 달 전 코드가 어땠는지 확인하기 좋습니다.
• Show Repository at Revision은 커밋 시점의 프로젝트 파일 구조를 엽니다. 현재 브랜치는 바뀌지 않습니다.

그룹 2 - 브랜치 작업

• New Branch...는 과거의 선택한 커밋에서 새 브랜치를 만듭니다. 작업을 한참 진행한 뒤 문제가 생겼다는 걸 깨닫고 마지막 정상 지점에서 새 브랜치를 시작하고 싶을 때 유용합니다.
• Checkout Revision은 로컬 프로젝트를 해당 커밋으로 전환합니다. 분리된 HEAD (detached HEAD) 상태가 됩니다. 이전 코드를 실행할 수 있지만 새 커밋은 어떤 브랜치에도 연결되지 않습니다. detached HEAD에서 필요한 커밋을 만들었다면 먼저 새 브랜치에 보존하세요. 돌아가려면 main 같은 일반 브랜치를 Checkout하세요.

그룹 3 - 커밋 변경과 이동

• Cherry-Pick은 다른 브랜치의 특정 커밋 하나를 현재 브랜치에 복사합니다. 예를 들어 누군가 다른 브랜치에서 내 작업을 막는 버그를 수정했다면, 해당 커밋만 Cherry-Pick해 가져올 수 있습니다. 다른 브랜치를 통째로 병합할 필요는 없습니다.
• Edit Commit Message...는 아직 Push하지 않은 커밋의 메시지를 빠르게 바꿉니다. 텍스트만 수정하면 될 때는 Amend보다 간단합니다.

그룹 4 - 변경 사항 취소

앞에서 자세히 살펴본 명령입니다:

• Reset Current Branch to Here...는 현재 브랜치를 해당 커밋으로 옮깁니다 (브랜치에서 접근할 수 있는 기록이 바뀝니다).
• Revert Commit은 변경된 내용을 취소하는 새 로컬 커밋인 "역커밋"을 만듭니다. 이후 이 커밋을 서버로 전송합니다.
• Undo Commit...은 로컬 커밋의 변경 사항을 다시 변경 창으로 돌려놓습니다.

그룹 5 - 기록 다시 쓰기

메뉴에는 Squash Commits... (여러 커밋을 하나로 합치기), Drop Commits (기록 중간의 커밋 삭제), Interactively Rebase from Here... 같은 명령도 있습니다. 로컬 기록을 세밀하게 다듬는 도구들입니다 (Interactive Rebase).

Git - 안전망

작업 상태에 따라 복구 방법을 선택하세요. 커밋하지 않은 파일, 로컬 커밋, 이미 공유한 기록에는 각각 다른 방법이 필요합니다. 필요한 버전을 저장해 두고 작업 전에 변경 사항을 확인하는 편이 모든 실수를 되돌릴 수 있다고 기대하는 것보다 낫습니다.

Claude Code와 함께 사용할 때

프로젝트에서 Claude Code를 사용할 때 이런 도구는 가장 중요한 안전장치입니다. 이렇게 활용해 보세요:

• 자주 커밋하세요. 커밋마다 되돌아갈 지점이 생깁니다. 에이전트가 잘못된 방향으로 가면 마지막 정상 상태로 돌아갈 수 있습니다.
• 커밋하지 않은 변경 사항을 취소하려면 먼저 보존할 내용을 구분하고, Rollback이나 git restore에서 적용 범위와 복구 기준을 확인하세요.
• 커밋은 했지만 아직 전송하지 않았다면 Undo Commit으로 변경 사항을 편집기에 돌려놓을 수 있습니다.
• 실수가 이미 서버에 올라갔다면 기록을 다시 쓰기보다 수정 커밋이나 Revert를 사용하는 편이 안전합니다.

이전 글: Pull request 작성부터 병합까지 · 다음 글: 저장소 만들기, rebase와 비밀 정보