개발자나 데이터 엔지니어에게는 실수로 git 브랜치를 삭제하거나 커밋을 잘못 재설정하는 것보다 더 짜증나는 일이 없습니다. 그래서 제가 스스로 경험을 통해 배우고 싶었던 것을 공유하게 되어 기쁩니다. 그것은 git reflog를 사용하는 방법입니다. git reflog는 정말 도움이 되는 기술 중 하나이며, 지금 약간의 시간을 들이면 나중에 큰 머리 아픔을 피할 수 있습니다.
저는 실수로부터 탐색하고 복구하는 데 정말 유용한 git reflog를 보여드리겠지만, 버전 관리에 대해 알아야 할 모든 것을 배울 수 있는 Git의 기초 및 GitHub 개념 소개 코스를 추천하고 싶습니다.
git reflog란 무엇인가?
Git reflog 또는 참조 로그는 Git 리포지토리에서 브랜치 팁 및 HEAD 참조의 업데이트를 기록하는 로컬 추적 메커니즘입니다. (Git에서 HEAD는 작업 디렉토리와 스테이징 영역이 기반으로 하는 현재 커밋을 가리킵니다.)
git log가 조상을 기반으로 한 커밋 히스토리를 표시하는 반면, git reflog는 브랜치 전체에서 커밋이 어떻게 연결되는지를 보여주며 HEAD의 모든 이동을 기록합니다. 이는 reflog가 소멸된 커밋을 복구하고 최근 작업을 디버깅하는 데 유용하게 만듭니다.
reflog 항목은 언제 생성됩니까?
Reflog 항목은 HEAD 또는 브랜치 참조의 상태를 변경하는 작업을 수행할 때마다 생성됩니다. 일반적인 시나리오는 다음과 같습니다:
-
git commit을 사용하여 변경 사항을 커밋하는 경우. -
git checkout branch_name을 사용하여 다른 브랜치로 전환하는 경우. -
git branch new_branch를 사용하여 새 브랜치를 생성하는 경우. -
git rebase를 사용하여 리베이스하는 경우 -
git reset --hard를 사용하여 이전 커밋으로 되돌리는 경우. -
git merge를 사용하여 브랜치를 병합하는 경우.
로컬 저장소에서 업데이트를 추적하는 데 사용하는 코드는 다음과 같습니다:
git reflog
로컬 저장소에서 업데이트를 추적하기 위해 git reflog를 사용합니다. 이미지 작성자.
git reflog의 출력을 해석하는 방법은 무엇인가요?
다음과 같이 출력을 해석할 수 있습니다:
-
HEAD@{0}: 가장 최근의 작업은 HEAD 브랜치로 전환한 것입니다. -
HEAD@{1}: 그 전에 파일 형식을.xlxs에서.csv형식으로 변경했습니다. -
HEAD@{2}: 파일을 저장소에 푸시할 때 첫 번째 커밋을 만들었습니다.
각 항목은 다음을 보여줍니다:
-
커밋 해시 (
fa82776) -
리플로그 인덱스 (
HEAD@{0},HEAD@{1}, 등) -
수행된 작업 설명 (커밋, 체크아웃, 리베이스)
git reflog 사용 방법
Git reflog는 참조 업데이트를 추적하고 저장소의 이전 상태로 복원하는 방법을 제공합니다. reflog 항목을 탐색하는 방법을 이해함으로써 잃어버린 커밋을 복구하고, 변경 사항을 취소하며, 작업의 과거 버전을 비교할 수 있습니다.
기본 git reflog 명령
아래는 기본 reflog 명령입니다:
git reflog
위 명령은 HEAD 또는 브랜치 참조를 업데이트한 최근 작업의 목록을 표시합니다. 여기에는 커밋, 브랜치 전환, 리셋, 리베이스 등이 포함됩니다. 각 항목은 reflog 기록에서의 위치를 나타내기 위해 HEAD@{0}, HEAD@{1}와 같이 인덱싱됩니다.
과거 상태 참조하기
Git reflog는 과거 참조 업데이트를 기록하여 저장소의 이력에서 이전 지점을 찾고 복원할 수 있게 해줍니다. 이것이 없다면 이러한 참조가 존재하지 않아 특정 과거 상태로 돌아가려면 정확한 커밋 해시가 필요합니다. 이제 Git이 우리에게 이러한 과거 상태를 탐색할 수 있게 하는 방법을 살펴보겠습니다. git checkout을 사용하여
HEAD@{n}: 특정 reflog 항목을 가리키는데, 여기서 n은 인덱스를 나타냅니다. 예를 들어, HEAD@{2}은 HEAD의 세 번째로 최신 상태를 가리킵니다.
git checkout HEAD@{2}
과거 변경 사항을 추적하기 위해 git checkout을 사용하는 방법. 저자: 이미지
branch@{time}: 특정 시간에 브랜치의 상태를 가리킵니다. 예를 들어, main@{1.week.ago}는 일주 전의 main 브랜치의 상태를 가리키고, feature@{yesterday}는 어제의 feature 브랜치의 상태를 가리킵니다.
git checkout main@{1.week.ago}
과거 변경 사항을 추적하기 위해 git checkout 사용하기. 저자: 이미지.
시간 기반 한정자
git reflog는 과거 상태를 복원하는 데 도움을 줄 뿐만 아니라 그들을 비교할 수 있도록 합니다. reflog는 참조 업데이트를 추적하므로 시간이 지남에 따라 리포지토리가 어떻게 변화했는지 볼 수 있습니다. 이제, git diff가 reflog 항목을 활용하여 과거와 현재 상태를 비교하는 방법을 살펴보겠습니다.
다음은 reflog 색인 번호에만 의존하는 대신 특정 시간으로 리포지토리를 복원할 수 있게 하는 시간 한정자의 예시입니다.
git checkout HEAD@{1.minute.ago} # 1분 전 상태
git checkout HEAD@{1.hour.ago} # 1시간 전 상태
git checkout HEAD@{1.week.ago} # 1주 전 상태
git checkout HEAD@{yesterday} # 어제 상태
git checkout HEAD@{2024-01-01.12:00:00} # 특정 타임스탬프의 상태
git diff를 사용하여 과거 상태 비교
과거 상태를 비교하려면 git diff와 같은 명령어를 사용할 수 있습니다. 다음 명령어는 현재 메인 브랜치 상태 main@{0}와 하루 전 상태 main@{1.day.ago}를 비교합니다. 출력 결과는 이 두 스냅샷 간의 차이를 보여줍니다.
git diff main@{0} main@{1.day.ago}
git diff로 과거 상태 비교. 저자 이미지.
Git Reflog의 일반적인 사용 사례
Git reflog는 잃어버린 변경 사항을 복구하고 실수를 되돌리며 일반적인 Git 문제를 해결하는 데 매우 유용한 도구입니다. 아래는 git reflog가 도움이 될 수 있는 몇 가지 실용적인 시나리오입니다.
잘못된 리셋 취소하기
만약 실수로 git reset --hard를 사용하여 브랜치를 리셋했다면, reflog를 사용하여 이전 상태로 복원할 수 있습니다.
git reset --hard HEAD@{3}
잃어버린 커밋 복구
브랜치를 실수로 삭제하거나 리셋 또는 리베이스로 인해 커밋을 잃었을 경우 git reflog를 사용하여 잃어버린 커밋을 찾을 수 있습니다.
git reflog
reflog 출력에서 커밋 해시를 찾아서 확인하세요:
git checkout <commit-hash>
잃어버린 커밋을 확인한 후 새 브랜치를 생성하여 보존할 수 있습니다:
git branch recovered-branch <commit-hash>
리베이스 실패 수정
리베이스가 잘못된 경우, git reflog를 사용하여 리베이스 이전 커밋을 찾고 브랜치를 리셋할 수 있습니다. 리베이스 이전의 커밋을 식별하고 이를 리셋하세요.
git reset --hard HEAD@{3} # reflog 출력에 따라 숫자를 조정하세요
삭제된 브랜치 복원하기
브랜치를 실수로 삭제한 경우, git reflog를 사용하여 복구할 수 있습니다. 삭제된 브랜치의 마지막 알려진 커밋을 찾아서 재생성하세요:
git branch restored-branch <commit-hash>
스태시 기록 추적하기
Git reflog는 스태시 기록을 보는 데에도 사용할 수 있습니다. 아래 명령어는 스태시 작업을 나열하여 필요할 경우 이전 스태시를 복구할 수 있도록 합니다.
git reflog stash
이전 스태시 항목을 적용하려면 다음 명령을 사용하십시오:
git stash apply stash@{2}
로컬 변경 사항을 덮어쓰는 최상의 방법에 대해 배우려면 Git Pull Force: 로컬 브랜치를 원격으로 덮어쓰는 방법 자습서를 확인하십시오.
Git Reflog 하위 명령어 및 옵션
Git은 reflog를 관리하고 상호 작용하는 데 사용되는 여러 하위 명령어와 옵션을 제공합니다.
Git reflog 하위 명령어
다음은 주요 git reflog 하위 명령어 및 사용 방법을 구조적으로 분해한 것입니다.
git reflog show: 기본적으로 HEAD 또는 브랜치와 같은 지정된 참조에 대한 reflog 항목을 표시합니다.
git reflog show
git reflog show를 사용하여 지정된 참조에 대한 항목을 표시합니다. 저자 이미지.
git reflog list: 이 명령은 reflog를 가진 모든 참조를 표시합니다. 저장된 reflog 항목을 가진 브랜치 및 HEAD 참조를 식별하는 데 유용합니다.
git reflog list
git reflog delete <ref>@{<specifier>}: 지정된 시간 제한을 초과하는 이전 reflog 항목을 정리합니다. 예를 들어, 다음 명령은 30일보다 오래된 항목을 제거합니다.
git reflog expire --expire=30.days.ago
git reflog delete <ref>@{<specifier>}: 참조 및 위치를 기반으로 특정 reflog 항목을 삭제합니다. 아래 명령은 HEAD의 인덱스 2에 있는 reflog 항목을 제거합니다.
git reflog delete HEAD@{2}
git reflog exists <ref>: 특정 참조에 대한 reflog가 존재하는지 확인합니다. 예를 들어, 아래 명령어는 main 브랜치에 reflog가 있으면 성공을 반환합니다.
git reflog exists main
git reflog 하위 명령어에 대한 옵션
다음은 git reflog 하위 명령어에 사용할 수 있는 옵션과 그 사용법입니다.
--expire-unreachable=<time>: 어떤 ref에서도 도달할 수 없는 reflog 항목만 정리합니다. 예를 들어, 아래 명령어는 7일 이상 된 도달할 수 없는 reflog 항목을 제거합니다.
git reflog expire --expire-unreachable=7.days.ago
--all: HEAD뿐만 아니라 모든 참조에 대한 reflog를 처리합니다. 아래 명령어는 모든 브랜치에서 60일 이상된 모든 reflog를 정리합니다.
git reflog expire --expire=60.days.ago --all
--dry-run: 실제로 삭제하지 않고 제거될 것을 보여주는 명령 실행을 시뮬레이트합니다. 예를 들어, 아래 명령은 어떤 항목이 제거될지 보여줍니다.
git reflog expire --expire=30.days.ago --dry-run
--verbose: 명령에 의해 수행된 작업에 대한 자세한 출력을 제공합니다. 아래 명령은 예전 reflog 항목이 만료될 때 자세한 세부 정보를 표시합니다.
git reflog expire --expire=90.days.ago --verbose
Git Reflog vs. Git Log: 주요 차이점
git log와 git reflog 둘 다 저장소의 이력에 대한 통찰을 제공하지만, 서로 다른 목적을 가지고 있습니다. 각각이 버전 관리 및 복구 전략에 어떻게 사용될 수 있는지 이해하기 위해 이러한 차이를 살펴보겠습니다.
-
git log는 브랜치의 커밋 이력을 따라가며 커밋의 조상을 보여줍니다. 저장소의 내용이 어떻게 진화했는지를 시간 순으로 제공합니다. -
git reflog는 HEAD, 브랜치, 스태시와 같은 참조의 업데이트를 기록하며, 브랜치 전환, 리셋, 리베이스 등의 동작을 포함합니다. 이는 커밋 계보의 일부가 아닐 수 있는 변경 사항을 추적합니다. -
git reflog는 귀하의 머신에만 국한되며 원격 리포지토리와 공유되지 않습니다. -
git log는 더 이상 브랜치 조상의 일부가 아닌 커밋을 복구할 수 없지만,git reflog는 참조 업데이트를 추적하여 “잃어버린” 커밋을 복구하는 데 도움을 줄 수 있습니다. 이러한 커밋이 어떤 브랜치에서도 더 이상 접근할 수 없더라도 말입니다.
아래 표는 이러한 주요 차이점을 요약합니다.
| Feature | git log | git reflog |
|---|---|---|
| 커밋 추적 | 예 | 아니오 |
| 참조 업데이트 추적 | 아니오 | 예 |
| 원격 공유 | 예 | 아니오 |
| 커밋을 복구할 수 있습니다 | 아니요 | 예 |
Git Reflog 사용에 대한 모범 사례
Git reflog는 잃어버린 커밋을 복구하고 히스토리 문제를 해결하는 데 강력한 도구이지만, 효과적으로 사용하려면 주의가 필요합니다. reflog를 사용할 때 따라야 할 몇 가지 모범 사례가 있습니다.
-
복구 및 디버깅을 위해 Reflog 사용: 브랜치를 실수로 잘못 재설정하거나 리베이스한 경우,
git reflog를 확인하여 이전 참조를 찾아 복원합니다. -
주의해야 할 점
git reset --hard:git reset --hard는 커밋되지 않은 변경 사항을 영구적으로 삭제할 수 있습니다. 문제가 발생할 경우 복구할 수 있는지 확인하기 위해 항상 먼저 reflog를 확인하십시오. -
파괴적인 명령을 실행하기 전에 백업을 유지하십시오: 데이터 손실을 방지하기 위해 Git 저장소의 자동 백업을 구현하십시오. 백업은 하드웨어 고장 또는 기타 재앙 발생 시 복구 가능성을 보장하기 위해 안전한 오프사이트 위치에 저장하십시오.
-
장기 복구를 위해 Reflog에만 의존하지 마십시오:기본적으로 reflog 항목은 90일 동안 유지됩니다. 이 기간이 지나면 가비지 수집되어 복구할 수 없게 될 수 있습니다. 로컬 reflog 이상으로 보존되도록 커밋을 정기적으로 원격 저장소에 푸시하십시오.
-
git reflog expire를 사용하여 오래된 항목 관리하기: 저장소의 reflog가 혼잡해지면git reflog expire를 사용하여 오래되거나 접근할 수 없는 항목을 정리하세요.
결론
Git에서 프로젝트의 이력을 효과적으로 관리하려면 기본 명령어 이상의 것이 필요합니다. 참조 업데이트를 추적하는 고급 도구를 탐색하여 분실된 커밋을 복구하고 삭제된 브랜치를 복원하며 실수를 수정하는 데 유용한 안전망을 제공할 수 있습니다. 이러한 도구들과 함께 git reset, git checkout, git revert와 같은 명령어를 직접 사용해보는 것은 버전 관리 능력을 크게 향상시킬 수 있습니다.
우리의 강좌를 수강하는 것은 배우는 좋은 방법뿐만 아니라 소프트웨어 개발을 진지하게 다룬다는 신호를 직장에 보낼 수 있는 좋은 방법입니다. 그 방향으로, 저희의 모든 수준을 위한 상위 20개 Git 인터뷰 질문과 답변 블로그 포스트를 공부하고 저희의 새로운 Git 기초 기술 트랙을 수강하여 Git에 관한 모든 것에 대해 전문가가 되는 것을 추천합니다.