한 번의 명령으로 초기화하기: 마음껏 망치고(그리고 고치고) 돌아올 수 있게 해주는 작은 Git 트릭

코드에 뭔가 위험한 시도를 해보고 싶은데, 로컬 환경이 망가질까 봐 망설인 적 있나요? 그런 걱정을 하는 사람은 당신만이 아닙니다. 많은 개발자들이 사실 필요 이상으로 조심스럽게 코드를 짜곤 합니다. 실험했다가 되돌릴 수 없을까 봐 두려운 거죠.

좋은 소식은 이겁니다. 아주 작은 Git 트릭 하나(그리고 몇 가지 습관)만 알면, 이제부터는 마음껏 부숴도 되는 자유를 얻을 수 있습니다. 그리고 한 줄 명령으로 작업 디렉터리를 언제든지 깔끔한 상태로 되돌릴 수 있습니다.

이 글에서는 다음과 같은 모던하고 안전한 방식으로 로컬 변경사항을 관리하고 초기화하는 방법을 설명합니다.

• 작업 트리의 변경을 정리하거나 되돌리는 git restore
• 브랜치 간 이동을 책임지는 git switch
• 단기용 안전망으로 쓰는 git stash

이 글을 다 읽고 나면 다음을 할 수 있게 됩니다.

• 필요할 때 로컬 변경사항을 안전하게 전부 버리고 처음 상태로 돌아가기
• 예전 Git 명령으로 인덱스나 브랜치를 실수로 건드리는 일 줄이기
• 저장소를 의미 불명 stash와 브랜치로 가득한 잡동사니 서랍으로 만들지 않고 관리하기

0단계: 먼저 Git이 설치돼 있는지 확인하기

이 모든 걸 하려면, 당연하지만 우선 Git이 설치되어 있어야 합니다.

터미널(Windows의 Command Prompt/PowerShell, macOS Terminal, Linux shell 등)을 열고 다음을 실행합니다.

git version

다음과 비슷한 출력이 보이면 됩니다.

git version 2.39.3

만약 이런 에러가 나온다면:

'git' is not recognized as an internal or external command

또는:

bash: git: command not found

아직 Git이 설치되지 않은 상태입니다.

빠른 설치 방법:

• Windows: Git for Windows를 설치하거나, Git이 포함된 GitHub Desktop을 설치합니다.
• macOS: Homebrew가 있다면 brew install git으로 설치하거나, 터미널에서 git을 한 번 실행했을 때 뜨는 안내에 따라 Xcode Command Line Tools를 설치합니다.
• Linux: 배포판 패키지 매니저로 설치합니다. 예: sudo apt install git, sudo dnf install git 등.

또한 Git 버전이 2.23 이상인지 확인해야 합니다. 이 버전부터 git restore와 git switch가 도입되었습니다.

git version
# 버전 숫자가 2.23 이상인지 확인하세요

버전이 너무 오래됐다면, 이 가이드를 그대로 따라 하기 위해 Git을 업데이트하세요.

왜 git restore가 현대적인 "한 번의 초기화" 명령인가

예전 Git 튜토리얼에서는 보통 이런 명령들을 많이 보여줍니다.

git checkout -- .

혹은 심지어:

git reset --hard

이 명령들도 동작은 합니다. 하지만 꽤나 무식한 도구에 가깝습니다.

• git checkout은 역사적으로 역할이 너무 많았습니다. 브랜치 전환, 파일 복구 등 여러 일을 한 명령으로 처리했죠. 오타 한 번 잘못 내면 원치 않는 브랜치로 이동해버리기 쉽습니다.
• git reset --hard는 단순히 작업 트리를 비우는 것을 넘어, 인덱스(스테이징 영역) 를 건드리고 HEAD를 옮기기도 합니다. 그저 로컬 파일 변경을 버리고 싶었을 뿐이라면, 과한 선택입니다.

Git 2.23 이상에서는 이런 역할을 명확하게 나눌 수 있도록 명령을 쪼개 두었습니다.

• git restore → 작업 트리의 파일을 다룸
• git switch → 브랜치 이동을 담당
• git reset → 인덱스와 커밋 히스토리를 조작

이렇게 역할을 분리하면 명령의 의도가 더 분명해지고, 실수로 히스토리를 망가뜨릴 가능성도 줄어듭니다.

핵심 트릭: 작업 트리를 한 번에 초기화하는 명령

로컬 코드가 완전히 난장판이 되었는데, 지금 브랜치에서 마지막 커밋 상태로만 돌아가고 싶다면 이렇게 하면 됩니다.

git restore .

이 명령이 하는 일:

• 현재 디렉터리와 하위 디렉터리의 커밋되지 않은 모든 변경사항을 버립니다.
• 작업 트리의 파일들을 현재 HEAD 커밋과 동일한 상태로 되돌립니다.
• 인덱스(스테이징 영역) 와 브랜치는 건드리지 않습니다.

즉, 히스토리는 그대로 둔 채 작업 디렉터리만 깔끔하게 만들어주는 한 줄짜리 초기화 명령입니다.

이럴 때 쓰면 좋습니다:

• 로컬에서 이것저것 실험해봤는데, 마음에 안 들고 다 지우고 싶을 때
• 코드가 더 이상 빌드도 안 되고 엉망이라, 그냥 마지막 커밋 상태로 돌아가고 싶을 때
• 새로운 작업을 시작하기 전에, 완전히 깨끗한 상태를 만들고 싶을 때

이럴 때는 쓰지 마세요:

• 나중에 쓸 수도 있을 것 같은 변경인데 아직 어디에도 저장(커밋/브랜치/패치 등)하지 않은 상태일 때
• 애매하지만 어쩌면 중요한 변경을 이미 스테이징하거나 커밋해둔 상태인데, 그걸 어떻게 할지 아직 확신이 없을 때 (이럴 땐 브랜치로 분리하는 게 낫습니다)

git restore .가 강력한 이유는, 그 범위가 철저하게 작업 트리로 제한되어 있기 때문입니다.

restore / switch / reset 삼총사를 이해하기

이 트릭을 진짜로 편하게 쓰려면, Git이 하는 일을 머릿속에서 세 가지 버킷으로 나눠 두면 좋습니다.

1. 작업 트리(Working tree) – 실제 디스크 위의 파일들
2. 인덱스(Index) – 다음 커밋에 포함할 파일을 모아두는 스테이징 영역
3. 브랜치 & 히스토리 – 커밋, HEAD, 각종 참조(ref)

그리고 각 영역에 대응하는 명령을 이렇게 매칭해 둡니다.

• git restore → 작업 트리(Working tree)

  • 파일 변경을 버리거나 되돌리는 역할
  • 예: git restore app.py

• git switch → 브랜치 & HEAD

  • 어느 브랜치(그리고 커밋)를 보고 있는지 전환
  • 예: git switch feature/login-ui

• git reset → 인덱스(+ 옵션에 따라 히스토리)

  • 스테이징 취소, HEAD 이동, 커밋 포인터 재배치 등
  • 예: git reset HEAD~1 (주의해서 사용하세요!)

파일 정리에는 git restore, 브랜치 이동에는 git switch를 쓰면, 원래 git reset으로 무리하게 하던 일을 분리해서 쓸 수 있고, 위험한 실수를 줄일 수 있습니다.

로컬에서 더 안전하게 실험하는 방법

이제 실제 개발 흐름 속에서 마음껏 망쳐도 괜찮게 만들어주는 실용적인 워크플로우를 살펴보겠습니다.

1. 항상 기능 브랜치에서 시작하기

main(혹은 master) 위에서 바로 작업을 시작하는 대신, 기능 브랜치를 하나 파고 시작하세요.

git switch -c experiment-new-idea

만약 Git 버전이 아직 낮아서 git switch가 없다면:

git checkout -b experiment-new-idea

이제부터 이 브랜치에서 만드는 커밋은 모두 메인 라인과 분리되어, 실험용 공간이 됩니다.

2. 망가질 걱정 없이 마음껏 실험하기

파일을 마음껏 수정하세요. 과감하게 리팩터링하고, 삭제하고, 추가하고, 별별 시도를 다 해보세요.

실험을 하다가 점점 엉망이 되고, "이건 아닌 것 같다"는 생각이 들면:

git restore .

이 브랜치에서의 마지막 커밋 상태로 깔끔하게 돌아옵니다.

반대로, 실험 결과가 그럴듯해 보인다면 이제 커밋하면 됩니다.

git add .
git commit -m "Try new idea for data caching"

나중에는 이 브랜치를 main에 merge하거나 rebase해서 반영해도 되고, 아니다 싶으면 그냥 버려도 다른 브랜치에는 전혀 영향을 주지 않습니다.

git stash: 안전망이지 창고가 아니다

git stash는 미완성 작업을 위한 장기 보관소처럼 잘못 쓰이는 경우가 정말 많습니다. 그러다 보면 stash@{17} 같은, 내용도 기억 안 나는 stash가 잔뜩 쌓이곤 하죠.

git stash는 짧은 시간 동안만 작업을 잠깐 치워두는 임시 안전망 정도로 쓰는 것이 가장 효율적입니다.

git stash가 유용한 순간

현재 작업 중인 변경을 잠깐 치워두고 작업 트리를 깨끗하게 만들고 싶을 때, 하지만 지금 변경을 완전히 버리기는 싫을 때 잘 어울립니다.

예를 들어:

1. 리팩터링을 반쯤 진행한 상태인데,
2. 같은 저장소에서 급한 버그를 하나 고쳐달라는 요청이 들어왔습니다.

이럴 때는 이렇게 할 수 있습니다.

git stash push -m "WIP: partial refactor"
# 더 짧게는
git stash

이제 작업 트리가 깨끗해집니다. 여기서 버그를 고치고, 커밋하고, 푸시까지 합니다.

그 후 다시 이전 작업을 가져오려면:

git stash pop

이전에 작업하던 변경사항이 다시 적용되고, 방금 썼던 stash 항목은 목록에서 제거됩니다.

git stash에 의존하면 안 되는 경우

현재 하는 작업이 짧은 끊김을 넘어서는 기간 동안 살아 있어야 한다는 걸 알고 있다면, 익명 stash에 계속 쌓아두기보다 브랜치 + 커밋으로 관리하는 편이 훨씬 낫습니다.

장기 stash 대신 쓸 만한 대안:

• 새 기능 브랜치를 만들거나, 이미 작업 중인 기능 브랜치 위에서 계속 작업하기:

  git switch -c wip-refactor-user-service

• 명확하게 표시된 WIP(작업 중) 커밋을 하나 남기기:

  git add .
  git commit -m "WIP: refactor user service (incomplete)"

나중에 인터랙티브 리베이스나 스쿼시 머지로 히스토리를 깨끗하게 정리하는 건 어렵지 않습니다. 하지만 반년 전 stash가 뭐였는지 기억도 안 나서 그냥 버려야 하는 상황은, 한 번 잃으면 정말 끝입니다.

간단한 기준을 하나 세워두세요:

지금 하는 작업이 한두 시간 이후까지도 중요하다면, stash에만 두지 말고 브랜치와 커밋으로 남기는 편이 낫다.

정리해서 보는 실제 시나리오

다음과 같은 상황을 떠올려 봅시다.

1. 지금 main 브랜치 위에 있습니다.
2. 브랜치를 만들지 않은 채로, 바로 파일을 수정하기 시작했습니다. (누구나 한 번쯤은 하는 실수죠.)
3. 20분쯤 지나 보니, 모든 게 망가졌고 후회가 밀려옵니다.

옵션 A: 전부 버려도 상관없을 때

이 경우라면 그냥 이렇게 하면 됩니다.

git restore .

작업 트리는 다시 main의 마지막 커밋 상태와 완전히 동일해집니다. 방금의 실수는 없던 일이 됩니다.

그리고 나서, 다음부터는 조금 더 안전하게 시작해 봅니다.

git switch -c feature/new-approach

이제부터의 실험은 이 브랜치 위에서 이뤄지기 때문에, main은 깨끗하게 유지됩니다.

옵션 B: 지금 작업이 엉망이긴 한데, 나중에 쓸 수도 있을 것 같을 때

"지금 보기엔 난장판이지만, 나중에 다시 참고할 수도 있겠다"는 생각이 든다면 이렇게 합니다.

git switch -c scratch/experiment-idea
# 새 브랜치를 만들 때, 현재 작업 내용은 그대로 따라옵니다

이제 방금까지의 변경은 scratch/experiment-idea라는 브랜치에 안전하게 남아 있습니다.

그래도 다른 브랜치에서 잠시 깨끗한 상태가 필요하다면, 임시로 stash를 끼워 넣을 수도 있습니다.

git stash push -m "WIP experiment idea"
# 다른 브랜치로 옮겨서 잠깐 고치고
git switch main
# 나중에 다시 돌아와서
git switch scratch/experiment-idea
git stash pop

하지만 그 작업을 계속 가져갈 생각이라면, 결국 이 브랜치 위에 WIP 커밋을 하나 남겨두는 편이 stash보다 깔끔한 관리 방법입니다.

마무리: "망가뜨려도 된다"는 허락을 스스로에게 주기

한 줄 명령으로 언제든지 로컬 코드를 복구할 수 있다는 사실을 알고 나면, 훨씬 더 과감하게 실험하고, 공격적으로 리팩터링하고, 편하게 배울 수 있습니다.

핵심만 정리해 보면:

• git restore . 으로 현재 브랜치의 마지막 커밋 상태로 작업 트리만 깔끔하게 되돌릴 수 있습니다.
• 다음 세 가지 축을 항상 머릿속에 두세요.
  • git restore → 작업 트리(로컬 파일 변경)
  • git switch → 브랜치(어느 라인을 보고/작업하는지)
  • git reset → 인덱스와 히스토리(신중하게 사용해야 하는 영역)
• git stash는 임시 안전망 정도로만 쓰고, 미완성 작업의 창고로 쌓아두지 마세요.
• 오래 가는 작업이라면, 기능 브랜치와 커밋을 활용하는 편이 훨씬 낫습니다. WIP 커밋도 괜찮습니다.
• git version으로 항상 현재 버전을 확인하고, 여기서 소개한 명령이 없다면 Git을 설치하거나 업데이트하세요.

이 작은 도구 세트를 익혀 두면, Git은 더 이상 알 수 없고 위험한 괴물이 아니라, 원래 그래야 했던 것처럼 더 높이, 더 빠르게 올라가도 떨어질 걱정을 줄여 주는 안전 장비가 되어 줄 것입니다.