답변:
의미가 없기 때문에 (다른 명령은 이미 해당 기능을 제공함) 실수로 실수를 저지르는 가능성을 줄입니다.
경로의 "하드 리셋"은 git checkout HEAD -- <path>(파일의 기존 버전을 확인하여) 수행됩니다.
경로의 소프트 리셋은 의미가 없습니다.
경로에 대한 혼합 재설정이 git reset -- <path>수행됩니다.
git checkout -- <path>하드 리셋을하지 않습니다. 작업 트리 내용을 준비된 내용으로 바꿉니다. git checkout HEAD -- <path>경로에 대한 하드 리셋을 수행하여 인덱스와 작업 트리를 HEAD 커밋의 버전으로 바꿉니다.
reset --hard경로가 없으면이 누락 된 조각을 제공합니다. Git은 이미 너무 강력해서 "자신의 보호를 위해이 작업을 수행 할 수 없습니다"라는 변명에는 물이 전혀 없습니다. 어쨌든 그 중 어느 것도 중요하지 않습니다 git reflog.
git reset --hard -- <path>. 이에 대한 합법적 인 사용 사례가 있습니다.
문제는 어떻게 이미 대답 , 나는 설명 할 것이다 이유 부분.
그래서 git reset 은 무엇을합니까? 지정된 매개 변수에 따라 두 가지 다른 작업을 수행 할 수 있습니다.
경로를 지정하면 인덱스에서 일치하는 파일이 커밋 파일 (기본적으로 HEAD)로 바뀝니다. 이 동작은 작업 트리에 전혀 영향을 미치지 않으며 일반적으로 git add의 반대쪽으로 사용됩니다.
경로를 지정하지 않으면 현재 분기 헤드를 지정된 커밋으로 이동하고 그와 함께 인덱스와 작업 트리를 커밋 상태로 재설정합니다 (선택 사항). 이 추가 동작은 mode 매개 변수에 의해 제어됩니다.
--soft : 인덱스와 작업 트리를 건드리지 마십시오.
--mixed (기본값) : 작업 트리가 아닌 인덱스를 재설정합니다.
--hard : 인덱스와 작업 트리를 재설정합니다.
다른 옵션도 있습니다. 전체 목록 및 일부 사용 사례는 설명서를 참조하십시오.
커밋을 지정하지 않으면 기본적으로 HEAD로 설정되므로 git reset --soft헤드를 HEAD (현재 상태)로 이동하는 명령이므로 아무 것도 수행하지 않습니다. git reset --hard반면에, 인해에 의미가 부작용 , 그것은 머리에 머리를 이동라고 하고 인덱스 및 HEAD에 작업 트리를 재설정합니다.
나는 왜이 작업이 그 특성상 특정 파일에 대한 것이 아닌지 분명해야한다고 생각합니다. 먼저 분기 헤드를 이동하고 작업 트리를 재설정하고 인덱스는 보조 기능입니다.
git checkout명령으로 사용 가능하기 때문에 ? 동일한 작업을 수행하도록 재설정하면 사용자가 더 혼란 스러울 수 있습니다. 내 대답은 --hard옵션이 인덱스 재설정이 아닌 분기 재설정 모드이기 때문에 특정 파일에 적용 할 수 없다는 것입니다. 다른 답변에서 읽을 수 있듯이 작업 트리 재설정의 이름은 checkout입니다. 이 모든 것이 Git 사용자 인터페이스 IMHO의 나쁜 디자인 일뿐입니다.
git checkout다음과 비교 : git reset --인덱스 만 git checkout --설정하고 작업 트리 만 설정합니까?
: 그 뒤에 매우 중요한 이유가 의 원칙 checkout과reset .
Git 용어로 체크 아웃 은 "현재 작업 트리로 가져 오기"를 의미합니다. 또한 git checkout작업 트리를 저장소의 커밋 또는 커밋 또는 준비 영역의 개별 파일 (기본값 임)의 모든 영역의 데이터로 채울 수 있습니다 .
차례로 git reset 에는이 역할이 없습니다. 이름에서 알 수 있듯이, 그것은 현재의 심판을 다시하지만 항상 가진 저장소 독립적으로 "범위"의, 소스 등을 (--soft, --mixed 또는 --hard).
요약 :
따라서 약간 혼동 될 수있는 것은 git reset COMMIT -- files"파일 덮어 쓰기"가 일부 파일에만 해당되지 않기 때문에 존재한다는 것입니다.
공식 설명이없는 경우, 나는 오직 자식 개발자가 찾을 것을 추측 할 수 있습니다 reset폐기에 명령의 가장 좋은 이름이 저장소의 유일한 데이터 소스이었다 부여, 준비 영역에 만든 변경 여전히 다음 " 의은을 확장 할 수 기능 "대신에 새 명령을 작성.
그래서 어떻게 든 git reset -- <files>이미 예외적입니다. HEAD를 덮어 쓰지 않습니다. 이러한 모든 변형은 예외입니다. --hard버전 을 구할 수 있다고해도 다른 사람 (예 :)은 --soft이해가되지 않습니다.
git reset -- <files>이것은 유용한 기능이기 때문에 추가 된 것처럼 떨어졌지만 아무도 어떤 명령을 내려야할지 확실하지 않았습니다. 다행히 지금 우리는 훨씬 더 제정신이 git restore의 기능을 git checkout -- <path> git checkout <commit> -- <path>하고 git reset [<commit>] -- <path>훨씬 더 온건 기본값으로 훨씬 더 이전에 할 수 없었던 기능을 (대답을 받아 것과는 달리 말한다. 이제 마지막으로 쉽게 단지 감동 지수 않고, 나무를 작업을 복원 할 수 있습니다).
git reset매뉴얼 목록 호출의 3 가지 방법 :
2는 파일 단위입니다. 이들은 작업 트리에 영향을 미치지 않지만 <paths>다음으로 지정된 색인의 파일에서만 작동합니다 .
git reset [-q] [<tree-ish>] [--] <paths>..git reset (--patch | -p) [<tree-ish>] [--] [<paths>...]1은 현명한 커밋에서 작동 하는 모든 파일 참조에 <commit>, 그리고 수 작업 트리에 영향을
git reset [<mode>] [<commit>]단지 지정된 파일에서 작동 호출에는 모드가 없습니다 및 작업 트리에 영향을 미친다는.
둘 다 원한다면 :
git config 파일에서이 별칭을 사용할 수 있습니다 :
[alias]
reco = !"cd \"${GIT_PREFIX:-.}\" && git reset \"$@\" && git checkout \"$@\" && git status --short #" # Avoid: "fatal: Cannot do hard reset with paths."
그런 다음 다음 중 하나를 수행 할 수 있습니다.
$ git reco <paths>
$ git reco <branch/commit> <paths>
$ git reco -- <paths>
(Mnenonic for reco: reset && check out)
git checkout -- <path>한다 교체 와 함께git reset --hard <path>. 훨씬 더 의미가 있습니다 ...