Git에서 잃어버린 Commit 찾기

@[git|commit|reflog]
Git를 사용하는 과정에서 때때로 일부 오작동, 예를 들어reset,rebase,merge 등이다.특히 Commit 이후 git reset --hard HEAD 로컬 레코드와 파일을 서버 버전으로 강제 롤백하여 로컬에서 수정한 모든 것을 Git 현재 지점의 서버 버전으로 복구하고 자신의Commit 레코드도 사라졌습니다.이런 상황에 직면하면 당황하지 마라. 우리가 Git에서 한 모든 조작은 원래의 조작에서 수정한 것일 뿐이고 기록되어 저장된다. 즉, 네가 무엇을 하든지 Git에게 롤백 조작을 할 수 있다는 것이다.

Commit 찾기 ##

다음 예제를 통해 스크롤하는 방법에 대해 알아봅니다.

$ git init
$ touch foo.txt
$ echo 'test data' >> foo.txt
$ git add foo.txt
$ git commit -m "initial commit"

$ echo 'new data' >> foo.txt
$ git commit -a -m "more stuff added to foo"

당신은 지금git의 역사 기록을 보면 두 번의 제출을 볼 수 있습니다.

$ git log
* 98abc5a (HEAD, master) more stuff added to foo
* b7057a9 initial commit

이제 첫 번째 제출 상태를 초기화합니다.

$ git reset --hard b7057a9
$ git log
* b7057a9 (HEAD, master) initial commit

이것은 우리가 두 번째 제출을 잃어버린 것처럼 보이고 현지의 수정도 사라져서 되찾을 방법이 없다.하지만 리프로그는 이 문제를 해결하는 데 쓰인다.간단하게 말하면 모든 HEAD의 역사를 기록합니다. 즉, reset, checkout 등 조작을 할 때 이 조작들은reflog에 기록됩니다.

$ git reflog
b7057a9 HEAD@{0}: reset: moving to b7057a9
98abc5a HEAD@{1}: commit: more stuff added to foo
b7057a9 HEAD@{2}: commit (initial): initial commit

그래서 우리는 우리의 제2commit을 되찾으려면 다음과 같은 조작만 해야 한다.

$ git reset --hard 98abc5a

git 기록을 다시 한 번 보겠습니다.

$ git log
* 98abc5a (HEAD, master) more stuff added to foo
* b7057a9 initial commit

동시에 로컬 대 foo.txt가 한 수정도 답장했습니다.
PS: 여기서 또 다른Commit 찾기 작업git cherry-pick 98abc5a을 언급합니다. 이 작업은 위의reset 작업과 다른 점은 후자는 단순히 98abc5a라는 Commit를 추출하여 롤백하는 것입니다. 만약에 b7057a9와 98abc5a 사이에 다른Commit 작업이 있다면 중간의 이 Commit의 수정을 무시할 수 있기 때문에 이 명령을 사용하면 파일의 충돌이 발생할 수 있습니다.

git reset의 구체적인 사용법 ###

git reset [--hard|soft|mixed|merge|keep] [ HEAD] 역할: 현재 지점reset을 지정된 또는 HEAD(기본적으로 최신 커밋, 즉 최신 커밋 이전 버전으로 재설정)
참고:

index,gitadd를 실행하면 파일에 인덱스를 만들고 추적된 모든 파일 인덱스는 index에 넣으며 파일이 수정되어 제출될 예정

working tree, 현재 작업 구역, 수정되었지만add되지 않은 파일, 작업 구역에 저장

ORIG_HEAD, 이전 작업 상태를 가리키는 데 사용되며, 매번commit이나pull이나reset,git는 오래된 HEAD를 복사합니다.git/ORIG_HEAD, ORIG_ 쌍을 통해HEAD 참조는 이전 작업 상태

를 나타냅니다.
1. index와 working tree를 다시 설정하면 모든 변경 사항이 버려집니다. 파일의 수정, 추가, 삭제 등 작업을 포함하고 HEAD를 가리키기 때문에gitlog를 통해 버전 제출 기록을 볼 수 있습니다.reset의 버전 기록은 버려지지만gitreflog를 통해 볼 수 있습니다
2. soft는 index와 working tree를 재설정하지 않고 HEAD만 가리키며commit된 파일이commit를 취소한다는 것을 나타냅니다. git status를 통해 보면 파일이commit 상태인'Changes to be committed'에 있습니다.
3. mixed(기본값)는 index를 재설정하지만working tree를 재설정하지 않습니다. 추가된 파일이add가 취소되었음을 나타냅니다. git status를 통해 보면 파일은 색인을 추가해야 하는 상태입니다. "Changes not staged for commit"
4. merge는 index를 재설정하고workingtree에서 변경된 파일을 재설정하지만 index와workingtree가 일치하지 않는 파일을 보존합니다
5,keep index,working tree에서 변경된 파일 재설정

기록된 저장 문제 ##

앞에서 말한 바와 같이 Git에서 한 모든 동작은 기록에 저장됩니다. 보통 로컬 Git 라이브러리에서 clone을 실행하기 시작한 모든 동작이 저장되어 있기 때문에 오래 전의 일부Commitlog를 찾을 수 없습니다. 삭제된 제출을 위해 더 긴 저장 주기를 설정할 수 있습니다.예를 들어 $ git config gc.pruneexpire "30 days" 삭제된 제출은 삭제된 지 30일 후에gitgc를 실행한 후에 영구적으로 버려진다는 뜻이다.git gc의 자동 운행을 끄고 싶을지도 모릅니다. $ git config gc.auto 0 이 경우 git gc를 수동으로 실행하는 경우에만 영구적으로 삭제합니다.
참고 링크: 춤추고 싶은 쥐는 Git의 기록을 수정할 수 없습니다 Terry_용 bolasblack(GitHub)