git reset --hard HEAD~1'과 'git reset --soft HEAD~1'의 차이점은 무엇입니까?
저는 약속을 취소하려고 했습니다.사용하는 것이 위험한가요?git reset --hard HEAD~1?
다른 옵션의 차이점은 무엇입니까?git reset?
git reset소프트, 믹스, 하드, 머지 앤 킵의 다섯 가지 "modes"을 알고 있습니다.처음 세 가지부터 시작하겠습니다. 보통 접하게 되는 모드들이기 때문입니다.그 후에는 좋은 보너스를 얻을 수 있을 테니까, 채널 고정하세요.
이와 유사한 기록이 있는 저장소가 있다고 가정합니다.
7e05a95 (HEAD -> main) Update a
e62add5 Update b
ca9ae0a Update a
9b6060d Add c
eebe372 Add b
947586a Add a
최신 커밋이 있는 곳(7e05a95)에는 다음과 같은 변경 사항이 포함되어 있습니다.
diff --git a/a b/a
index b66ba06..28b68e2 100644
--- a/a
+++ b/a
@@ -1 +1 @@
-new content
+new new content
이제 당신이 뛰면 무슨 일이 벌어질까요?git reset다양한 모드로?한번 알아보겠습니다.
부드러운
사용시git reset --soft HEAD~1현재 분기에서 마지막 커밋을 제거하지만 파일 변경 내용은 작업 트리에 남아 있습니다.또한 변경 사항은 인덱스에 남아 있으므로 다음을 수행합니다.git commit이전의 커밋 "removed"과 정확히 동일한 변경 사항으로 커밋을 만듭니다.
이것이 실제로 어떻게 보일까요?다음과 같은 경우:
> git reset --soft HEAD^ # Assuming HEAD points at 7e05a95
> git status
On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: a
파일의 변경 내용을 보면a다시 실행할 준비가 되어 있습니다.
혼혈의
이 모드는 기본 모드이며 소프트와 매우 유사합니다.다음과 함께 커밋을 "제거"할 때git reset HEAD~1변경 내용은 계속 작업 트리에 유지되지만 인덱스에는 유지되지 않습니다. 따라서 커밋을 "redo"하려면 변경 내용을 추가해야 합니다.git add실행하기 전에
실제로 결과는 다음과 같습니다.
> git reset --mixed HEAD^ # Assuming HEAD points at 7e05a95
> git status
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: a
no changes added to commit (use "git add" and/or "git commit -a")
파일의 변경사항a아직은 있지만 그들은 지수에 없습니다.
어려운
사용시git reset --hard HEAD~1마지막 커밋에서 도입된 변경사항 외에 커밋되지 않은 모든 변경사항과 추적되지 않은 모든 파일을 잃게 됩니다.변경 사항이 작업 트리에 남아있지 않을 것이므로 작업을 수행합니다.git status명령어를 사용하면 저장소에 변경 사항이 없음을 알 수 있습니다.
이것을 조심해서 밟으세요.에 의해 추적되지 않은 커밋되지 않은 변경사항을 실수로 제거하는 경우git(speak: 커밋되었거나 적어도 인덱스에 추가됨), 사용자는 이를 다시 사용할 방법이 없습니다.git.
실제적인 예는 다음과 같습니다.
> git reset --hard HEAD^ # Assuming HEAD points at 7e05a95
> git status
On branch main
nothing to commit, working tree clean
보시다시피 변경 사항이 남아 있지 않습니다.파일에 커밋되지 않은 변경사항도 있었다고 가정할 때b이것들도 잃어버릴 겁니다!
> echo 'some uncommitted changes' > b
> git status
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: b
no changes added to commit (use "git add" and/or "git commit -a")
> git reset --hard HEAD^ # Assuming HEAD points at 7e05a95
> git status
On branch main
nothing to commit, working tree clean
보너스
지킨다
git reset --keep HEAD~1그것은 흥미롭고 유용한 것입니다.현재와 다른 파일만 재설정합니다. HEAD그리고 주어진 약속.이러한 파일 중 하나 이상에 커밋되지 않은 변경사항이 있으면 재설정을 중지합니다.으로 안전한 합니다 .hard.
에서 가 있었던를 다시 .b:
> echo 'some uncommitted changes' > b
> git status
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: b
no changes added to commit (use "git add" and/or "git commit -a")
> git reset --keep HEAD^ # Assuming HEAD points at 7e05a95
> git status
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: b
no changes added to commit (use "git add" and/or "git commit -a")
했습니다 했습니다.a 않은 사항은 했습니다.b!
반복하자면, "hard"는 모든 변경사항을 제거하고 "keep"은 재설정 커밋에서 변경사항만 제거합니다.
이러한 각 모드는 깃 리셋 설명서에서 자세히 설명합니다.
는.git reset커밋을 제거하려면 커밋이 실제로 손실된 것이 아니라 커밋을 가리키는 참조나 자식을 가리키는 참조가 없을 뿐입니다.이 제"다를 사용하여 "을 복구할 도 있습니다.git reset를 들어 SHA-1합니다, 명령어로 으로써.git reflog.
깃 리셋에는 소프트, 믹스, 병합, 하드, 유지의 5가지 주요 모드가 있습니다.헤드, 스테이지(인덱스), 작업 디렉토리를 변경하거나 변경하지 않는 것이 차이점입니다.
Git reset --hard는 헤드, 인덱스 및 작업 디렉토리를 변경합니다.
Git reset --soft는 헤드만 변경합니다.인덱스를 변경하지 않았습니다. 작업 디렉토리.
다시 말해서, 당신이 당신의 커밋을 취소하고 싶다면, --soft면 충분합니다.그러나 이후에도 인덱스와 작업 디렉토리에 잘못된 커밋으로 인한 변경 사항이 남아 있습니다.파일을 수정하고 수정한 후 인덱스에 추가하고 다시 커밋할 수 있습니다.
--hard를 사용하면 프로젝트에서 완벽한 슬레이트를 얻을 수 있습니다.마치 지난번 커밋 때와 달라진 게 없는 것처럼.원하는 것이 확실하다면 앞으로 나아가십시오.하지만 이렇게 하면 마지막 커밋을 완전히 잃게 됩니다(참고: 손실된 커밋을 복구하는 방법은 여전히 있습니다).
리셋 명령에 대한 설명을 그래픽으로 보여주는 유용한 기사입니다.
https://web.archive.org/web/20171119010424/http ://git-scm.com/blog/2011/07/11/reset.html
Reset --hard는 확인하지 않고 작업 복사본을 덮어쓰기 때문에 상당히 위험할 수 있으므로, 파일을 커밋하지 않은 경우에는 파일이 사라집니다.
Source tree에 관해서는 커밋을 취소할 방법이 없습니다.어쨌든 커버 밑에 리셋을 해야 할 가능성이 큽니다.
이는 git reset 사용 --hard와 git reset 사용 --soft의 주요 차이점입니다.
--soft
인덱스 파일이나 작업 트리를 전혀 만지지 않습니다(그러나 모든 모드와 마찬가지로 헤드를 로 재설정합니다).이렇게 하면 변경된 모든 파일이 "Changes to commited"(변경사항이 커밋됨) 상태로 남게 됩니다.
--hard
인덱스와 작업 트리를 재설정합니다.이후 작업 트리에서 추적된 파일에 대한 변경 내용은 모두 삭제됩니다.
reset --hard <commit-id> 사항을 그 다. 다른 경우에는reset --soft <commit-id>또한 사용자는 커밋 상태로 돌아가지만 커밋 상태 이후에 커밋된 파일은 준비되지 않은 상태로 유지할 수 있습니다.
에서 이 .git push -f origin <branch-name>원격 분기 커밋 ID가 동기화되지 않았습니다.
언급URL : https://stackoverflow.com/questions/24568936/what-is-difference-between-git-reset-hard-head1-and-git-reset-soft-head
'programing' 카테고리의 다른 글
| w3wp clr.dll 오류 디버그 방법 (0) | 2023.10.07 |
|---|---|
| Android에서 활동에서 단편으로 데이터 전송 (0) | 2023.10.07 |
| 프로젝트에서 위험을 고려할 때 -I 포함 스위치를 사용하는 이유는 무엇입니까? (0) | 2023.10.07 |
| XML 문서에 HTML 내용을 삽입할 수 있습니까? (0) | 2023.10.07 |
| 팬더 데이터 프레임에 열 레벨을 간단히 추가하는 방법 (0) | 2023.10.07 |