git이 경로별로 하드 / 소프트 리셋을 수행 할 수없는 이유는 무엇입니까?

git이 경로별로 하드 / 소프트 리셋을 수행 할 수없는 이유는 무엇입니까?

---

$ git reset -- <file_path> 경로별로 재설정 할 수 있습니다.

그러나 $ git reset (--hard|--soft) <file_path>다음과 같은 오류가보고됩니다.

Cannot do hard|soft reset with paths.

---

요점이 없기 때문에 (다른 명령은 이미 해당 기능을 제공함) 우연히 잘못된 일을 수행 할 가능성을 줄입니다.

경로에 대한 "하드 리셋"은 git checkout HEAD -- <path>(파일의 기존 버전을 확인하여) 수행됩니다.

경로의 소프트 리셋은 의미가 없습니다.

경로에 대한 혼합 재설정이 git reset -- <path>수행됩니다.

---

를 사용하여 수행하려는 작업을 수행 할 수 있습니다 git checkout HEAD <path>.

즉, 제공된 오류 메시지는 나에게 의미가 없습니다 ( git reset하위 디렉토리에서 잘 작동 함). 나는 git reset --hard당신이 요구하는 것을 정확하게하지 않아야하는 이유를 알 수 없습니다 .

---

문제는 어떻게 이미 대답 , 나는 설명 할 것이다 이유 부분.

그래서 git reset 은 무엇을합니까? 지정된 매개 변수에 따라 두 가지 다른 작업을 수행 할 수 있습니다.

• 경로를 지정하면 인덱스에서 일치하는 파일이 커밋 파일 (기본적으로 HEAD)로 바뀝니다. 이 동작은 작업 트리에 전혀 영향을 미치지 않으며 일반적으로 git add의 반대쪽으로 사용됩니다.

• 경로를 지정하지 않으면 현재 분기 헤드를 지정된 커밋으로 이동하고 그와 함께 인덱스 및 작업 트리를 해당 커밋 상태로 다시 설정합니다. 이 추가 동작은 mode 매개 변수에 의해 제어됩니다.
  --soft : 인덱스와 작업 트리를 건드리지 마십시오.
  --mixed (기본값) : 작업 트리가 아닌 인덱스를 재설정합니다.
  --hard : 인덱스와 작업 트리를 재설정합니다.
  다른 옵션도 있습니다. 전체 목록 및 일부 사용 사례는 설명서를 참조하십시오.

  커밋을 지정하지 않으면 기본적으로 HEAD로 설정되므로 git reset --soft헤드를 HEAD (현재 상태)로 이동하는 명령이므로 아무 것도 수행하지 않습니다. git reset --hard반면에, 인해에 의미가 부작용 이 머리에 머리를 이동 말한다, 그리고 인덱스 및 HEAD에 작업 트리를 재설정합니다.

  나는 왜이 작업이 그 특성상 특정 파일에 대한 것이 아닌지 분명해야한다고 생각합니다. 먼저 분기 헤드를 이동하고 작업 트리를 재설정하고 인덱스는 보조 기능입니다.

---

오리진 또는 업스트림 (소스)과 실제 브랜치 사이에 슬래시를 넣으십시오.

git reset --hard origin/branch

또는

git reset --hard upstream/branch`

---

설명

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)

---

: 그 뒤에 매우 중요한 이유가 의 원칙 checkout과reset .

Git 용어로 체크 아웃 은 "현재 작업 트리로 가져 오기"를 의미합니다. 또한 git checkout작업 트리를 저장소의 커밋 또는 커밋 또는 스테이징 영역의 개별 파일 (기본값) 로 모든 영역의 데이터로 채울 수 있습니다 .

차례로 git reset 에는이 역할이 없습니다. 이름에서 알 수 있듯이, 그것은 현재의 심판을 다시하지만 항상 가진 저장소 독립적으로 "범위"의, 소스 등을 (--soft, --mixed 또는 --hard).

요약 :

• 체크 아웃 : 어디서나 (인덱스 / repo commit)-> 작업 트리
• reset: Repo commit -> Overwrite HEAD (and optionally index and working tree)

Therefore what can be a bit confusing is the existence of git reset COMMIT -- files since "overwriting HEAD" with only some files doesn't make sense!

In the absence of an official explanation, I can only speculate that the git developers found that reset was still the best name of a command to discard changes made to the staging area and, given the only data source was the repository, then "let's extend the functionality" instead of creating a new command.

So somehow git reset -- <files> is already a bit exceptional: it won't overwrite the HEAD. IMHO all such variations would be exceptions. Even if we can conceive a --hard version, others (for example --soft) wouldn't make sense.

---

git reset --soft HEAD~1 filename undo the commit but changes remain in local. filename could be -- for all commited files

참고URL : https://stackoverflow.com/questions/11200839/why-git-cant-do-hard-soft-resets-by-path