수업소개
여기서는 reset과 checkout을 하면 내부에서는 어떤 일이 일어나는지를 알아봅니다. 이 수업에서는 reset이 refs/heads/브랜치명 파일의 커밋 id를 바꾸는 것이고, checkout은 heads의 내용을 바꾸는 것이라는 것을 이해하시면 됩니다.
Rails 와 프론트 엔드 기술을 이용해 흥미 위주의 빠른 웹 개발 방법론
댓글
-
테스트 해보면 내용도 reset으로 날려버리기 전으로 돌아가네요.
a 라고 써있는 파일을 ab로 바꿔서 커밋하고 reset --hard를 사용해 이전 커밋으로 돌아가면 다시 a가 되지만
reflog에서 ab로 바꿔 커밋했던 id를 확인해 그 id로 다시 reset --hard 시키면 ab로 복원됩니다. -
git log
git reset --hard ORIG_HEAD
git reflog
.git\HEAD
.git\logs\refs\heads\master -
돌아갈 수 있는 커밋이 남는게 아니라 로그만 남는것 아닐까요..? -
reset을 한다는 건 결국 HEAD를 해당 id로 이동시키는 거고 지운다는 의미가 아니라 해당 커밋id를 최신 커밋으로 가리킨다는 거니까 reflog에 기록되는 것과는 상관이 없지 않나요? reflog에서는 모든 커밋을 기록하는 거니까 상관없이 'reflog에서 본id' 를 reset하는 거 까지 기록하고.. 결론적으로 어떻게 해도 지울 수 없는 거 아닐까요? 이고잉님이 말씀하셧던 것처럼 데이터가 너무 많아져서 git 내부적으로 gc가 실행되기 전까지는..
-
reset과 checkout의 원리에 대해서 배웠습니다.
reset --hard명령을 하면 되돌릴 수 없는 줄 알았는데 ORIG_HEAD에 커밋이 남는 군요
그리고 reflog명령을 통해서 로그들을 볼 수 있음을 알게되었습니다. -
reset을 했다는 기록도 reflog에 남네요.
결국 했던 리셋을 리셋 했다는 기록이 남아요. 어찌 됐든 없어지진 않는... -
그런데 git reset “git reflog에서 본 id” 를 입력한다면
이건 정말 복구가 안되게 reset 하는 걸까요 ? -
git reset --hard 커밋id 는 HEAD파일이 refs/heads/master 파일을 가리키고 그 파일은
원하는 커밋id로 되어있고, ORIG_HEAD라는 파일이 생겨 그내용은 기존 최신 커밋 id를 가지고 있으므로
다시 복귀할 때는 git reset --hard ORIG_HEAD 으로 하든 git reset --hard 최신커밋id로 가능.
이와는 틀리게 git checkout 원하는 커밋id은 HEAD파일 자체가 바로 원하는 커밋id를 바로 가르킨다.
복귀는 git checkout master -
단순히 예시를 위한 커밋 생성이기 때문에 일부로 빠른 재생으로 강의 시청자들을 배려해주신 듯 합니다.
-
첫 댓글을 달게 되어 영광입니다.
근데 수업 영상이 속도가 두배로 나와서 0.5속도로 보고 있는 중입니다. (30초에서 1분30초 사이의 영상입니다.) 혹시 보신다면 수정해주시면 감사하겠습니다.
버전 관리
| egoing |
| 현재 버전 | |
|---|---|
| 선택 버전 |
