git reset 더하기-hard 의 차 이 를 자세히 설명 합 니 다.

보통 저희 가 제출 하 는 코드 는 git add,git commt-m 입 니 다.   git push 의 이러한 절차.임시 저장 소 에 추가 하여 git 라 이브 러 리 에 제출 하여 버 전 번 호 를 만 들 고 push 는 원 격 창고 에 가서 다른 사람 이 사용 할 수 있 도록 합 니 다.이것 은 완전 하고 매우 순 조로 운 절차 다.그러나 실제 개발 에 서 는 이렇게 순 조 롭 지 않 아 이런 저런 문제 가 자주 발생 한다.
git reset 는 우리 가 잘못된 내용 을 제출 한 후에 되 돌려 주 는 명령 입 니 다.
git reset 버 전 번 호 는 이 버 전 번호 로 되 돌아 가 는 것 입 니 다.
보통
git reset HEAD 는 현재 버 전 으로 되 돌아 가 는 것 입 니 다.git reset HEAD^이전 버 전 으로 되 돌아 가기
우리 git add 파일

이때 우 리 는 잘못된 내용 을 추가 한 것 을 발 견 했 습 니 다.이때 우 리 는 add 작업 만 했 습 니 다.즉,수정 한 내용 을 임시 저장 구역 에 추가 하고 commt 를 실행 하지 않 았 기 때문에 버 전 번호 가 생 성 되 지 않 았 습 니 다.현재 버 전 번호 에 대응 하 는 내용 인지,아니면 add 이전의 내용 인지,그래서 우 리 는 코드 를 현재 버 전 으로 되 돌려 주면 됩 니 다.
git reset HEAD,캡 처 에 도 알림 내용 use git reset HEADto unstage 가 있 습 니 다.제 이 해 는 임시 저장 소 에 추 가 된 내용 을 제거 하 는 것 입 니 다.
명령 을 실행 한 후 현재 git 상 태 를 다시 봅 니 다.그림:

상 태 를 보 니 우리 가 작업 구역 의 내용 을 수정 하고 add 가 없 을 때의 상태 와 같 습 니 다.
git reset HEAD 작업 은 임시 저장 구역 에 만 효과 가 있 고 작업 구역 의 내용 에 효과 가 없 음 을 설명 합 니 다.그래서 우 리 는 작업 구역 의 내용 을 수정 하려 면 계속 명령 을 집행 하여 복원 해 야 한다.위의 캡 처 알림 에 따 르 면 git add 는 추가 되 었 습 니 다.오류 가 발견 되 어 되 돌 아 왔 기 때문에 이 를 실행 할 수 없습니다.
또 하나의 명령 알림:git checkout--to discard changes in working directory 는 특정한 파일 을 다운로드 하고 이 파일 이 작업 영역 에서 변경 한 내용 을 버 리 는 것 을 의미 합 니 다.일단 이렇게 번역 합 시다.서 류 를 복원 하 더 라 도 작업 구역 의 수정 은 사 라 졌 다.그림 과 같이 이 명령 을 실행 하여 상 태 를 봅 니 다.

이때 당신 이 일 하 는 서 류 를 보 러 가면 수 정 된 곳 이 없어 지고 작업 구역 의 문서 도 깨끗 해 져 서 서 서 류 를 철저하게 복원 한 셈 입 니 다.
이상 의 장면 은 add 이후 commt 가 없습니다.다음은 add 와 commt 이후 의 어떻게 해 야 하 는 지 살 펴 보 겠 습 니 다.

그림 에서 보 듯 이 저 는 commt 를 했 습 니 다.push 가 없습니다.push 의 내용 은 우리 가 먼저 상관 하지 않 습 니 다.push 라 는 명령 은 사실 제출 과 관계 가 없습니다.그 는 원 격 으로 보 냈 을 뿐 입 니 다.push 가 되면 우리 가 뒤로 물 러 난 후에 다시 push 를 할 뿐 입 니 다.그 러 니 push 라 는 조작 을 고민 하지 마 세 요.그 는 버 전 을 제출 하 는 것 과 사실 관계 가 없다.
화제 로 돌아가다.우 리 는 이미 commt 를 만 들 었 습 니 다.최신 버 전 번호 가 생 성 되 었 다 는 것 을 설명 합 니 다.이때 우 리 는 되 돌아 가 고 싶 습 니 다.분명 이전 버 전의 버 전 번호,git reset 버 전 번 호 를 알 고 있다 면 됩 니 다.그러나 일반적으로 우 리 는 버 전 번 호 를 기억 하지 않 습 니 다.물론 git log 명령 을 실행 하여 찾 을 수 있 습 니 다.git 는 이전 버 전 을 되 돌려 주 는 더 간단 한 방법 을 제공 합 니 다.  git reset HEAD^,이 명령 은 이전 버 전 으로 되 돌아 가 는 데 사 용 됩 니 다.잘못된 길이 멀 어 졌 다 면 이전 버 전 으로 되 돌아 가 는 것 만으로 도 해결 되 지 않 을 수 있 습 니 다.로 그 를 찾 아 해당 버 전 번 호 를 찾 아 git reset 버 전 번 호 를 되 돌려 야 합 니 다.git reset HEAD^를 실행 한 후 상 태 를 확인 합 니 다.그림:

이 캡 처 는 add 만 하고 commt 의 후퇴 를 하지 않 은 캡 처 와 일치 합 니 다.유일한 차이 점 은
git reset 뒤에 있 는 하 나 는 HEAD 이 고 하 나 는 HEAD 입 니 다^.이것 은 잘 이해 할 수 있 습 니 다.하 나 는 commt 가 없 기 때문에 버 전 번호 가 생 성 되 지 않 았 습 니 다.하 나 는 이미 commt 이 되 었 고 새로운 버 전 번호 가 있 습 니 다.환불 하려 면 이전 버 전 번 호 를 써 야 겠 어 요.
git reset-hard 와 없 는-hard 의 차 이 를 말 하려 고 했 는데 이렇게 쓸데없는 말 을 많이 했 어 요.에이,어 지 럽 지 않 았 으 면 좋 겠 어 요.뒤에 설명해 드릴 게 요.-hard 의 역할.
마찬가지 로,우 리 는 먼저 add 를 하고 commt 작업 을 하지 않 습 니 다.add 를 한 후에 git reset--hard HEAD 를 실행 합 니 다.그림 과 같 습 니 다.

그리고 git status 를 실행 하여 상 태 를 봅 니 다.그림:

주의 하 세 요.여기 와 없 는--hard 는 차이 가 있 습 니 다.매개 변수 인 hard 가 있 으 면 작업 구역 의 내용 도 직접 수정 하 였 습 니 다.-hard 를 추가 하지 않 을 때 임시 저장 구역 만 작 동 했 을 뿐 작업 구역 에 영향 을 주지 않 습 니 다.-hard 가 한 걸음 에 도착 하면 추가 하지 않 습 니 다.-hard 는 따로 실행 해 야 합 니 다.두 단계 작업 을 해 야 합 니 다.보아하니 하 드 가 훨씬 편리 해 보이 지만,나 는 모두 에 게 이것 을 사용 하 는 것 을 건의 하지 않 는 다.왜냐하면 이것 은 살상력 이 좀 강하 기 때문이다.만약 에 자기가 지우 고 싶 지 않 은 걸 손 으로 지 웠 다 면 후회 하 는 약이 없 을 거 야.그 러 니까 조심 하 세 요.
추가--hard,commt 가 있 는 지 없 는 지 는 구분 되 지 않 습 니 다.여 기 는 캡 처 하지 않 습 니 다.여러분 스스로 시도 해 보 세 요.
git reset 에-hard 의 차 이 를 추가 하 는 지 에 대한 자세 한 설명 은 여기까지 입 니 다.git reset-hard 내용 은 우리 의 이전 글 을 검색 하거나 아래 의 관련 글 을 계속 찾 아 보 세 요.앞으로 많은 응원 바 랍 니 다!