Git에서 작업 되돌리는 명령어 간단하게 구분

git 에서 작업을 되돌리는 명령어는 여러가지가 있다. 자칫 잘못하면 되돌리는 순간 되돌릴 수 없기에 신중하게 잘 아라보고 사용해야 한다. 사실 처음 찾아보면 이해하기가 어렵다 간단히 두괄식으로 정리해보고자 한다.

git revert: 이전 커밋을 가져오는 명령어

git revert [커밋 ID]

git reset: 이전 커밋으로 되돌아 가는 명령어

git reset --hard [커밋 ID]

• '--soft': 인덱스와 작업디렉토리는 그대로 두고 HEAD만 변경
• '--mixed': 작업 디렉토리는 그대로 두고 인덱스를 HEAD와 일치시킴니다(default)
• '--hard': 인덱스와 작업 디렉토리 모두 HEAD와 일치하도록 초기화

git checkout: 특정 파일이나 되돌리는 명령어

git checkout [커밋 ID] -- [파일명]

git restore(git 2.23이후): git checkout 및 git reset의 모호함 해결, 복원하는 명령어

git restore --source=[커밋 ID] [파일명]  # 특정 파일을 특정 커밋 상태로 복원
git restore --staged [파일명]            # 스테이징된 파일을 언스테이징

git reflog: 백업과 비슷한 명령어, 모든 HEAD의 변경을 기록

git reflog
git reset --hard [reflog에서 찾은 커밋 ID]

추가설명

'git reset --hard'는 되돌릴 수 없나요?

• 기본적으로 복구가 불가능
• 예외상항:
  • 로컬 레포지토리의 reflog: git reflog를 사용하여 삭제된 커밋을 사용하여 삭제된 커밋을 찾을 수 있음
  • 백업: 정기적인 백업이 있다면 그것으로 복구

HEAD, 작업디렉토리, 인덱스의 차이

• HEAD: 현재 케트아웃된 커밋을 가리키는 포인터, 즉 현재 작업중인 브랜치의 최신 커밋을 나타냅니다.
• 작업디렉토리: 실제 파일들이 있는 디렉토리로, 이곳에서 파일 수정이 일어납니다.
• 인덱스(Staging Area 또는 Stage): 커밋하기 전의 상태를 임시로 저장하는 곳, 현재 작업 디렉토리의 파일들을 기반으로 다음 커밋을 준비하는 중간 단계

'git restore'는 'git checkout'과 'git reset'의 모호함을 어떻게 해결하였나요?

• git checkout과 git reset의 문제점: 이전에는 git checkout을 사용하여 브랜치를 변경하거나 특저 파일을 과거상태로 되돌리는데 사용했습니다. 반면, 'git reset'은 주로 HEAD를 이동시키거나 인덱스를 조작하는데 사용되었습니다. 이 두 명령어가 여러 작업에 걸쳐 사용되면서 어떤 상황에서 어떤 명령어를 사용해야 하는지 혼란이 생길 수 있었습니다.
• git restore의 도입: 이러한 모호함을 해결 예를 들어, 'git restore'로 작업 디렉토리의 파일을 과거 상태로 되돌리거나, 인덱스에 스테이지된 변경사항을 취소할 수 있습니다.

reflog와 백업의 차이

• 범위: 'reflog'는 Git 내부적인 변경에 한정된 기록
• 영속성: 'reflog'는 일정 기간 후 자동으로 일부 데이터를 정리
• 보호수준: 'reflog'는 로컬 Git 작업에 국한된 오류나 변경을 추적하여 복구하는데 유용하지만 외부적인 위험으로는 취약