소개
이 랩에서는 Git 브랜치가 로컬에서 삭제되었는지 확인하는 방법을 배우게 됩니다. 먼저, 깨끗한 시작 상태를 보장하기 위해 git branch를 사용하여 특정 브랜치가 없는지 확인하는 것으로 시작합니다. 그런 다음, 브랜치 삭제를 포함하여 로컬 저장소의 참조에 대한 업데이트를 기록하는 강력한 도구인 git reflog 명령어를 살펴보고 변경 내역을 확인할 수 있습니다. 마지막으로, 최근에 삭제된 브랜치를 사용하여 이러한 방법을 테스트하여 로컬 삭제 상태를 효과적으로 확인하는 방법을 확인합니다.
git branch 실행하여 부재 확인
이 단계에서는 나중에 삭제할 특정 브랜치가 현재 Git 저장소에 존재하지 않는지 확인합니다. 이는 브랜치 삭제와 같은 작업을 수행하기 전에 깨끗한 상태에서 시작하도록 보장하는 좋은 방법입니다.
먼저, 아직 해당 디렉토리에 있지 않다면 프로젝트 디렉토리로 이동합니다. 프로젝트는 ~/project/my-time-machine에 위치해 있습니다.
cd ~/project/my-time-machine
이제 git branch 명령어를 사용하여 저장소의 기존 브랜치를 나열해 보겠습니다. 기본적으로 이 명령어는 로컬 브랜치를 표시합니다.
git branch
다음과 유사한 출력을 볼 수 있습니다.
* master
이 출력은 현재 master 브랜치만 존재하며, 활성 브랜치임을 나타냅니다 (별표 *로 표시됨).
이 랩에서는 feature/new-feature라는 브랜치를 사용합니다. git branch를 다시 실행하여 이 브랜치가 아직 존재하지 않는지 확인해 보겠습니다. 방금 실행했고 master만 보았으므로 이미 존재하지 않는다는 것을 알고 있지만, 명령어를 다시 실행하면 브랜치 상태를 확인하는 개념을 강화합니다.
git branch
출력은 여전히 master 브랜치만 표시해야 합니다.
* master
이는 feature/new-feature 브랜치가 현재 저장소에 존재하지 않음을 확인합니다. 이는 다음 단계에서 이 브랜치를 생성하고 삭제하기 전에 예상되는 상태입니다. 브랜치 상태를 확인하는 방법을 이해하는 것은 프로젝트의 기록을 효과적으로 관리하는 데 필수적입니다.
git reflog 를 사용하여 삭제 확인
이 단계에서는 손실된 커밋 또는 브랜치를 복구하는 강력한 도구인 git reflog 명령어를 살펴봅니다. reflog (참조 로그) 는 로컬 저장소의 브랜치 팁 및 기타 참조에 대한 업데이트를 기록합니다. 즉, 커밋, 병합, 리베이스 및 브랜치 삭제를 포함하여 저장소에서 수행하는 거의 모든 변경 사항을 기록합니다.
먼저, 프로젝트 디렉토리에 있는지 확인합니다.
cd ~/project/my-time-machine
이제 나중에 삭제할 새 브랜치를 생성해 보겠습니다. 이렇게 하면 reflog에서 검색할 항목이 생깁니다.
git branch feature/new-feature
이 명령어는 현재 커밋을 가리키는 feature/new-feature라는 새 브랜치를 생성합니다. 존재하는지 확인해 보겠습니다.
git branch
이제 두 브랜치를 모두 볼 수 있습니다.
* master
feature/new-feature
이제 -d 플래그를 사용하여 feature/new-feature 브랜치를 삭제해 보겠습니다. 이는 "안전한" 삭제입니다 (브랜치에 병합되지 않은 변경 사항이 있는 경우 삭제를 방지합니다).
git branch -d feature/new-feature
삭제를 확인하는 출력을 볼 수 있습니다.
Deleted branch feature/new-feature (was <commit-id>).
<commit-id>를 터미널에 표시된 실제 커밋 ID 로 바꿉니다.
이제 reflog를 확인하여 삭제가 기록되었는지 확인해 보겠습니다.
git reflog
출력은 작업 내역을 표시합니다. 브랜치 삭제와 관련된 항목이 표시되어야 합니다 (정확한 출력은 다를 수 있음).
<commit-id> HEAD@{0}: branch: deleted feature/new-feature
<commit-id> HEAD@{1}: branch: Created from <another-commit-id>
... (other reflog entries)
reflog 항목 HEAD@{0}: branch: deleted feature/new-feature는 feature/new-feature 브랜치가 삭제되었음을 나타냅니다. HEAD@{0}은 가장 최근 작업을 나타냅니다. 이는 git branch에서 브랜치가 사라졌음에도 불구하고 삭제가 reflog에 기록되어 잠재적으로 복구할 수 있음을 보여줍니다.
git reflog를 이해하는 것은 안전망 역할을 하기 때문에 중요합니다. 실수로 브랜치를 삭제하거나 리베이스 또는 기타 작업으로 인해 커밋을 잃어버린 경우, reflog를 사용하여 작업을 복원하는 데 필요한 커밋 ID 를 찾을 수 있습니다.
최근 삭제된 브랜치로 테스트
이 단계에서는 git reflog의 정보를 사용하여 최근에 삭제된 브랜치를 잠재적으로 복구하는 방법을 보여줍니다. 이 특정 랩에서는 브랜치에 고유한 커밋이 없으므로 브랜치를 완전히 복구하지는 않지만, 복구에 사용되는 명령어를 연습합니다.
먼저, 프로젝트 디렉토리에 있는지 확인합니다.
cd ~/project/my-time-machine
이전 단계에서 feature/new-feature 브랜치를 삭제했음을 기억하십시오. 여전히 사라졌는지 확인해 보겠습니다.
git branch
출력은 여전히 master 브랜치만 표시해야 합니다.
* master
이제 reflog를 다시 살펴보고 삭제된 브랜치에 대한 항목을 찾아보겠습니다.
git reflog
branch: deleted feature/new-feature라고 표시된 줄을 찾습니다. 이 항목과 관련된 커밋 ID 를 기록해 둡니다. <commit-id> HEAD@{0}: branch: deleted feature/new-feature와 유사하게 표시됩니다.
삭제된 브랜치를 복구하려면 일반적으로 git branch <branch-name> <commit-id> 명령어를 사용합니다. 여기서 <branch-name>은 복구된 브랜치에 지정하려는 이름이고, <commit-id>는 브랜치가 마지막으로 가리키고 있던 reflog의 커밋 ID 입니다.
이 경우, feature/new-feature 브랜치는 생성되었고, 새로운 커밋 없이 즉시 삭제되었습니다. 따라서 reflog 에서 해당 커밋 ID 는 master 브랜치의 팁과 동일합니다. 이를 복구하면 기본적으로 master와 동일한 커밋을 가리키는 브랜치를 다시 생성하는 것과 같습니다.
삭제된 브랜치에 대한 reflog에서 찾은 커밋 ID 를 사용하여 복구 명령어를 시뮬레이션해 보겠습니다. <commit-id>를 reflog 출력의 실제 ID 로 바꿉니다.
git branch recovered-feature <commit-id>
이 명령어는 삭제되기 전 feature/new-feature가 가리키고 있던 커밋 ID 를 가리키는 recovered-feature라는 새로운 브랜치를 생성합니다.
이제 브랜치를 다시 확인해 보겠습니다.
git branch
이제 recovered-feature 브랜치가 나열되어야 합니다.
* master
recovered-feature
이는 git reflog를 사용하여 손실된 브랜치의 커밋 ID 를 찾은 다음 git branch를 사용하여 다시 생성하는 방법을 보여줍니다. 이는 실수로 삭제하거나 기록을 변경하는 작업으로부터 복구하는 강력한 기술입니다.
요약
이 랩에서는 git branch 명령어를 사용하여 로컬 Git 브랜치의 부재를 확인하는 방법을 배웠습니다. 브랜치를 생성하고 삭제하기 전에 깨끗한 시작점을 보장하기 위해 현재 브랜치 상태를 확인하는 것이 중요함을 확인했습니다.
또한 git reflog 명령어를 탐색하기 시작하여 브랜치 삭제를 포함하여 로컬 저장소의 참조에 대한 변경 사항을 추적하는 역할을 이해했습니다. 이는 손실된 작업을 잠재적으로 복구하는 데 중요합니다.
