reflog로 손실된 커밋 찾기

• HEAD와 브랜치가 어디에 있었는지에 대한 이 저장소의 기록으로 reflog를 읽어보세요.
• 복원하기 전에 후보 커밋의 내용을 확인하세요.
• 체크아웃하지 않고 측정된 커밋에서 분기를 만듭니다.
• reflog가 되돌릴 수 없는 것, 즉 커밋되지 않은 작업과 만료된 항목을 말해보세요.

귀하는 18과 결과 M의 분기인 private/lost-signup에 있습니다. "문서: 가입 복구 메모 유지"라는 메모를 커밋하고 docs/signup-recovery.md을(를) 추가한 다음 한 커밋 뒤로 하드 리셋을 실행했습니다. 메모는 지점, 그래프 및 파일에서 사라졌습니다. 아직 구조 분기가 없으며 다른 항목도 변경하지 않았습니다.

모든 것이 로컬이며 무료 요금제(GitTree에서 로그인을 요청함)입니다. 호스팅 계정도 없고, 공급자도 없고, 인터넷도 없습니다. 모든 신원은 허구입니다(example.com). 실제 프로젝트에서는 이 강의를 실행하지 마세요. 준비 과정의 하드 리셋은 일회용 복사본의 리허설입니다.

동일한 사본에서 둘 다 수행하지 말고 GitTree 또는 기본 Git 명령을 사용하여 변경하십시오. 결과를 읽는 것은 항상 안전합니다. 메뉴 라벨은 GitTree 2.0의 자체 문자열에서 왔으며 기본 명령은 일회용 복사본에서 Git 2.43을 사용하여 실행되었습니다. GitTree 단계가 macOS, Windows 또는 Linux에서 실행되지 않았습니다.

reflog는 ref 움직임에 대한 로컬 일기입니다. HEAD에는 하나가 있으며 각 분기에도 마찬가지입니다. "커밋", "체크아웃", "재설정" 등을 각각 커밋과 함께 기록합니다. 다른 클론에는 일기가 없습니다. 브랜치 이름이 여전히 존재할 수 없는 커밋이며, 이를 찾는 방법은 reflog입니다.

HEAD@{1}와 같은 선택기는 지금부터 항목을 다시 계산하므로 이후 작업마다 변경됩니다. 사용하기 전에 후보자의 동작, 시간, ID 및 파일을 읽으십시오. 오프셋을 레시피로 기억하지 마십시오.

reflog는 저장된 커밋을 찾습니다. 27과에서 설명한 것처럼 커밋되지 않은 편집 내용은 찾을 수 없습니다. 항목 만료: 기본적으로 Git은 약 30일 동안 분기가 도달하지 않는 커밋에 대한 항목을 유지하며 저장소에서 이를 변경할 수 있습니다. 복구하는 동안 정리 또는 만료 명령을 실행하지 마십시오.

커밋에서 브랜치를 생성하면 참조가 하나만 추가되고 다른 것은 추가되지 않습니다. 현재 분기, 색인 및 파일은 현재 위치에 유지됩니다.

18과 결과 M의 별도 일반 복사본에서 시작하고 원본을 그대로 둡니다. 브랜치를 생성하고 DOC_LOST를 저장한 후 커밋하고 커밋 하나를 다시 하드 리셋하세요. 이 파괴적인 준비는 일회용 복사본에만 해당됩니다.

아래에 명명된 단계에서만 저장하십시오. 이는 최종 개행 문자가 포함된 완전한 UTF-8/LF 본문입니다. 마크다운 펜스를 붙여넣지 마세요. 변경되지 않은 실행 가능 파일은 명명된 입력을 상속합니다. 별도의 변형 버전이 원본을 덮어쓰면 안 됩니다.

docs/signup-recovery.md — DOC_LOST

# Recovered signup work

Keep a branch name before leaving useful experimental work.

Command+Shift+P(Ubuntu에서는 Ctrl+Shift+P)를 사용하여 팔레트를 엽니다.

1. 다음 섹션에 표시된 대로 리허설을 작성하고 손실된 커밋의 제목을 기록해 둡니다.
2. 팔레트를 열고 View Reflog…을(를) 실행하세요. Reflog of이 HEAD로 설정된 상태로 "Reflog" 대화상자가 열립니다. 항목이 최신 항목부터 나열됩니다.
3. 상위 항목을 읽어보세요. 최신에는 "재설정"이라고 표시되어 있고 그 아래에는 "문서: 가입 복구 메모 유지"라는 제목으로 "커밋"이라고 표시되어 있습니다. 목록이 길면 Show Older Entries를 사용하세요. 두 번째 행이 항상 옳다고 가정하지 마십시오.
4. 커밋 항목을 선택합니다. 대화상자에는 Show in Graph 및 New branch name가 표시됩니다. Show in Graph는 브랜치가 도달하는 커밋만 배치할 수 있으므로 손실된 커밋의 경우 대화 상자를 닫고 그래프는 M에 유지됩니다. 다음 단계를 위해 리플로그를 다시 엽니다. 복원한 후 커밋 파일을 읽습니다.
5. 대화 상자로 돌아가서 동일한 항목을 선택하고 New branch name에 rescue/signup를 입력한 다음 Restore as Branch를 선택합니다. 알림에는 "브랜치 복구/가입이 생성되었습니다. 실행 취소하면 다시 제거됩니다."라는 메시지가 표시됩니다.
6. 결과를 확인하세요. rescue/signup은(는) 손실된 커밋을 가리키고 현재 분기는 여전히 M의 private/lost-signup이며 파일은 변경되지 않았습니다. 복원된 커밋을 선택하고 해당 파일 docs/signup-recovery.md을 엽니다. DOC_LOST입니다.
7. 구조 지점을 제자리에 두십시오. 그래프를 정리하기 위해 정리를 실행하지 마십시오.

과정의 모든 일반적인 커밋에 대해: Summary는 명시된 주제이고, Description는 비어 있으며, 옵션 Amend Previous Commit, Skip Hooks, Add Signed-off-by, Different Author, Push After Commit 및 Allow Empty Commit는 꺼져 있습니다.

18과 결과의 별도의 깨끗한 사본에서만:

git switch --create private/lost-signup

DOC_LOST를 docs/signup-recovery.md로 저장한 후:

git add -- docs/signup-recovery.md
git commit --quiet -m "docs: keep the signup recovery note"
git reset --hard HEAD~1
git reflog show --format=%gs -2 HEAD

reset: moving to HEAD~1
commit: docs: keep the signup recovery note

ID와 함께 후보자를 나열하고 분실되었다고 생각되는 후보자를 확인하십시오.

git reflog show --format='%H %gs' HEAD
git show "<lost-sha>:docs/signup-recovery.md"

<lost-sha>을 "commit: docs: keep the signup Recovery Note" 줄의 ID로 바꿉니다. 이 즉각적인 예에서 HEAD@{1}은 동일한 커밋이지만 해당 오프셋은 규칙이 아닙니다. 확인하지 않고 복구 브랜치를 생성합니다:

git branch rescue/signup "<lost-sha>"
git show rescue/signup:docs/signup-recovery.md
git symbolic-ref --short HEAD
git status --short

파일은 DOC_LOST이고 인쇄된 분기는 private/lost-signup이며 상태는 비어 있습니다. HEAD이(가) M에 남아 있기 때문에 파일에 메모가 표시되지 않습니다. 만료 또는 정리 명령은 이에 포함되지 않습니다.

Where you end: rescue/signup는 손실된 커밋을 가리키며 해당 파일은 DOC_LOST입니다. 현재 브랜치, 인덱스 및 파일은 재설정 이후와 똑같으며 아무것도 푸시되지 않았습니다.

• 항목을 읽는 대신 HEAD@{1}을 고정 레시피로 사용합니다.
• 브랜치를 저장하기 전에 재설정하거나 다시 체크아웃하면 더 많은 항목이 추가되고 원하는 항목이 묻어납니다.
• 커밋되지 않은 편집 내용이 리플로그에 포함될 것으로 예상됩니다.
• 무언가를 찾는 동안 정리 명령을 실행합니다.

커밋이 목록에 없으면 잘못된 참조를 보고 있는 것일 수 있습니다. HEAD와 브랜치 간에 Reflog of를 전환하고 Show Older Entries을 사용하세요. 실제로 사라진 경우 만료되었거나 커밋되지 않은 것입니다. 앱에서 Restore as Branch 뒤의 알림에는 Undo가 분기를 다시 제거한다고 되어 있습니다.

각 질문에 답한 후 그 이유를 읽어보세요. '필수'라고 표시된 질문은 수업 완료에 반영됩니다.

1. 질문 1/6

   질문 1/6

   리플로그가 무엇인가요?

   답을 하나 선택하세요.

   모든 클론과 서버가 함께 유지하는 공유 로그입니다.

   파일 백업.

   HEAD와 각 분기가 가리키는 위치에 대한 로컬 기록입니다.

   커밋 그래프와 동일합니다.

   답변 확인
2. 질문 2/6

   질문 2/6

   다음 중 리플로그에 대한 설명으로 옳은 것은 무엇입니까?

   해당하는 답을 모두 선택하세요.

   커밋하지 않은 편집 내용을 저장합니다.

   HEAD와 각 지점에는 고유한 지점이 있습니다.

   이전 항목이 만료됩니다.

   프로젝트의 다른 복제본에는 항목이 없습니다.

   답변 확인
3. 질문 3/6

   질문 3/6필수

   Reflog에서 손실된 커밋을 찾았으며 rescue/signup 이름의 Branch로 복원을 사용했습니다. 무엇이 보이나요?

   답을 하나 선택하세요.

   rescue/signup이(가) 손실된 커밋을 가리키고 파일이 변경되지 않은 상태로 여전히 M의 private/lost-signup에 있습니다.

   현재 rescue/signup에 있으며 메모가 파일에 다시 있습니다.

   private/lost-signup는 손실된 커밋으로 이동합니다.

   reflog 항목이 삭제됩니다.

   답변 확인
4. 질문 4/6

   질문 4/6

   입력 변경: 메모를 커밋하지 않은 다음 하드 리셋을 실행했습니다. 리플로그가 다시 가져올 수 있나요?

   답을 하나 선택하세요.

   예, 이전 항목 표시를 통해 가능합니다.

   예, HEAD@{1}입니다.

   아니요. 리프로그는 커밋을 가리키며 이 콘텐츠는 한 번도 포함되지 않았습니다.

   예, Reflog를 브랜치로 전환하면 됩니다.

   답변 확인
5. 질문 5/6

   질문 5/6필수

   몇 가지 작업을 더 수행한 후 git branch rescue HEAD@{1}을(를) 실행했는데 파일이 원하는 파일이 아닙니다. 무슨 일이에요?

   답을 하나 선택하세요.

   HEAD@{1}은 재설정 후 항상 올바른 커밋입니다.

   리플로그가 손상되었습니다.

   손실된 커밋은 새 브랜치에서 삭제되었습니다.

   HEAD@{1}는 지금부터 다시 계산되므로 새로운 작업마다 이름이 변경됩니다. 목록을 읽고 손실된 커밋의 ID를 사용하세요.

   답변 확인
6. 질문 6/6

   질문 6/6필수

   구조 브랜치를 생성한 후 어떤 판독 결과가 강의 내용대로 작동했음을 보여주나요?

   해당하는 답을 모두 선택하세요.

   이제 docs/signup-recovery.md이(가) 파일에 존재합니다.

   git show rescue/signup:docs/signup-recovery.md는 "# 복구된 가입 작업"으로 시작하여 복구된 메모를 인쇄합니다.

   git status --short는 아무것도 인쇄하지 않습니다.

   git symbolic-ref --short HEAD는 private/lost-signup을(를) 인쇄합니다.

   답변 확인

두 개의 최신 리프로그 라인, 손실된 커밋의 ID, 복구된 파일의 첫 번째 라인 및 체크아웃이 있는 브랜치를 보고합니다. 그런 다음 커밋한 적이 없는 편집 내용에 대해 리플로그에 어떤 내용이 표시되는지 말하세요.

• reflog는 심판 이동에 대한 로컬 일기입니다.
• 후보자를 확인한 다음 그것으로부터 분기하십시오.
• 저장되지 않은 편집 내용이 아닌 커밋을 찾습니다.

• 재설정: 부드러움, 혼합 및 단단함 (제 27과)
• HEAD를 이동하지 않고 기록 읽기(강의 8)
• GitTree 다운로드

Reflog — سجل المراجع; 구조 지점 — froع حبظ; 선택기 — محدِّد.