작업 디렉토리에 숨김을 다시 적용 할 수 없습니다.

작은 이야기 :

먼저 커밋 된 변경 사항을 푸시하려고했지만 "아니요, 먼저 풀 수 없습니다."라는 메시지가 표시되었습니다. 그런 다음 GitHub에서 항목을 가져온 다음 변경 사항을 푸시합니다. 가져 오려고 할 때 덮어 쓸 변경 사항이 있으며 변경 사항을 숨겨야한다고 표시했습니다. 좋아요, 변경 사항을 숨겼습니다 ... 당겨서 커밋 된 변경 사항을 푸시했습니다. 하지만 지금은 작업 중이던 커밋되지 않은 변경 사항을 복원 할 수 없습니다.

이것은 오류입니다.

MyPath/File.cs already exists, no checkout
Could not restore untracked files from stash

확실히 나는 아직 git의 모든 개념을 이해하지 못합니다. 그들은 저를 약간 혼란스럽게합니다 ... 어쩌면 제가 뭔가 잘못했을 수도 있습니다.

누군가가이 문제를 해결하도록 도울 수 있다면 좋을 것입니다. 저는 지금 한 시간 이상 Google과 모든 것을 검색했지만 아직 해결책을 찾지 못했습니다.

도움을 주시면 감사하겠습니다. 감사!

숨김에 나중에 저장소에 추가 된 추적되지 않은 파일이 포함 된 것 같습니다. 당신이 그것을 시도하고 체크 아웃 할 때, git은 기존 파일을 덮어 쓰기 때문에 당연히 거부합니다.

문제를 해결하려면 해당 파일을 삭제하고 (괜찮습니다. 여전히 저장소에 있음) 숨김을 적용한 다음 파일의 숨김 버전을 저장소 내 버전으로 적절하게 바꾸는 것과 같은 작업을 수행 할 수 있습니다.

편집 : 파일이 저장소에 추가 되지 않고 작업 트리에서만 생성되었을 수도 있습니다 . 이 경우 단순히 로컬 파일을 삭제하지 말고 다음을 수행하십시오.

1. 다른 곳으로 옮기세요
2. 은닉을 적용
3. 두 파일 버전을 수동으로 병합합니다 (작업 트리 vs. 이동).

가장 안전하고 쉬운 방법은 아마도 물건을 다시 숨기는 것입니다.

git stash -u             # This will stash everything, including unstaged files
git stash pop stash@{1}  # This will apply your original stash

나중에 결과에 만족하면 전화 할 수 있습니다.

git stash drop

"안전한"은닉을 제거합니다.

@bentolo에서 언급했듯이 불평하는 파일을 수동으로 삭제하고 분기를 전환 한 다음 수동으로 다시 추가 할 수 있습니다. 그러나 저는 개인적으로 "git 내부"에 머무르는 것을 선호합니다.

이를 수행하는 가장 좋은 방법은 숨김을 분기로 변환하는 것입니다. 브랜치가되면 여러분이 알고 사랑하는 일반적인 브랜치 관련 기술 / 도구를 사용하여 git에서 정상적으로 작업 할 수 있습니다. 이것은 실제로 나열된 오류가없는 경우에도 은닉으로 작업하는 데 유용한 일반적인 기술입니다. 숨김이 실제로는 내부적으로 커밋되기 때문에 잘 작동합니다 (PS 참조).

숨김을 브랜치로 변환

다음은 숨김이 생성되었을 때 HEAD를 기반으로 분기를 생성 한 다음 숨김을 적용합니다 (커밋하지 않음).

git stash branch STASHBRANCH

"stash 분기"작업

다음에 수행 할 작업은 숨김과 대상 브랜치 (ORIGINALBRANCH라고 함)가 현재 어디에 있는지 간의 관계에 따라 다릅니다.

옵션 1-일반적으로 숨김 분기 리베이스 (숨김 이후 많은 변경 사항)

ORIGINALBRANCH에서 많은 변경을 수행했다면 STASHBRANCH를 지역 지점처럼 취급하는 것이 가장 좋습니다. STASHBRANCH에서 변경 사항을 커밋하고 ORIGINALBRANCH에서 리베이스 한 다음 ORIGINALBRANCH로 전환하고 STASHBRANCH 변경 사항을 리베이스 / 병합하십시오. 충돌이있는 경우 정상적으로 처리하십시오 (이 접근 방식의 장점 중 하나는 충돌을 확인하고 해결할 수 있다는 것입니다).

옵션 2-숨김과 일치하도록 원래 분기 재설정 (숨김 이후 제한적 변경)

몇 가지 단계적 변경을 유지하면서 방금 숨긴 다음 커밋하고 원하는 것은 숨길 때 준비되지 않은 추가 변경 사항을 얻는 것입니다. 다음을 수행 할 수 있습니다. 작업 복사본을 변경하지 않고 원래 분기 및 색인으로 다시 전환됩니다. 최종 결과는 작업 복사본의 추가 숨김 변경 사항입니다.

git symbolic-ref HEAD refs/heads/ORIGINALBRANCH
git reset

배경

Stashe는 브랜치 / 태그 (패치 아님)와 같은 커밋입니다.

추신, stash를 패치로 생각하고 싶지만 (커밋을 패치로 생각하고 싶은 유혹처럼) stash는 실제로 생성되었을 때 HEAD에 대한 커밋입니다. 신청 / 팝업 할 때 현재 브랜치에 체리를 선택하는 것과 유사한 작업을 수행합니다. 브랜치와 태그는 실제로 커밋에 대한 참조 일 뿐이므로 여러면에서 스 태시, 브랜치 및 태그는 커밋 (및 해당 내역)을 가리키는 다른 방법 일뿐입니다.

작업 디렉토리를 변경하지 않은 경우에도 필요함

PPS, --patch 및 / 또는 --include-untracked와 함께 숨김을 사용한 후에이 기술이 필요할 수 있습니다. 작업 디렉토리를 변경하지 않아도 이러한 옵션은 때때로 다시 적용 할 수없는 숨김을 생성 할 수 있습니다. 나는 그 이유를 완전히 이해하지 못한다는 것을 인정해야합니다. 자세한 내용은 http://git.661346.n2.nabble.com/stash-refuses-to-pop-td7453780.html 을 참조하십시오 .

해결책: 문제의 파일을 삭제 한 다음 팝 / 적용을 다시 시도해야합니다. 다른 파일을 삭제하지 말고 오류에서 언급 한 파일 만 삭제하십시오.

문제 : Git은 때때로 짜증납니다. 실행하는 경우 git stash -u는 비 추적 파일 (멋진!)를 포함하지만, 하지 않습니다 그 비 추적 파일을 제거 하지 않습니다 정말 만드는, (냉각하지!) 남은 상단에 은닉의 비 추적 파일을 적용하는 방법을 알고 -u옵션이 꽤 쓸모.

대신 stash의 코드 차이점을 패치로 적용하려면 다음 명령을 사용하십시오.

git stash show --patch | patch -p1

이것은 나에게 여러 번 발생했습니다. 추적되지 않은 파일을 git stash -u 하여 결국 저장소에 추가되고 더 이상 숨겨진 변경 사항을 적용 할 수 없습니다.

강제 git stash pop/apply로 파일을 대체 하는 방법을 찾을 수 없었기 때문에 먼저 숨겨져 있던 추적되지 않은 파일의 로컬 복사본을 제거한 다음 ( 커밋되지 않은 변경 사항을 삭제하므로주의 하십시오) 숨김 된 변경 사항을 적용합니다 :

rm `git ls-tree -r stash@{0}^3 --name-only`
git stash apply

마지막으로, 사용 git status, git diff및 기타 도구를 확인하고없는 무언가가 있다면 제거 된 파일의 부분을 다시 추가 할 수 있습니다.

유지하려는 커밋되지 않은 변경 사항이있는 경우 먼저 임시 커밋을 만들 수 있습니다.

git add --all
git commit -m "dummy"
rm `git ls-tree -r stash@{0}^3 --name-only`
git stash apply

적합한 도구를 사용하여 이전에 커밋 된 변경 사항을 로컬 파일에 다시 병합하고 더미 커밋을 제거합니다.

git reset HEAD~1

비슷하게 차단 된 팝 작업은 남은 무시 파일 때문이었습니다 (.gitignore 파일 참조). Git 상태는 추적 됨과 추적되지 않음으로 표시되었지만 내 활동은 무시 된 파일을 정리하지 못했습니다.

세부 사항 : 나는 사용했다git stash save -a 하고 마스터를 확인하여 원래 동작을 컴파일하고 확인한 다음 편집을 계속하기 위해 모두 다시 배치하려고했습니다. 브랜치를 체크 아웃하고 팝을 시도했을 때 무시한 파일이 숨김 저장 이전에 남아있었습니다. 이는 마스터 체크 아웃이 커밋 된 파일에만 영향을 미치기 때문입니다. 무시 된 파일은 지우지 않았습니다. 그래서 팝은 실패했고, 본질적으로 여전히 거기에있는 파일 위에 숨겨둔 무시 된 파일을 복원하고 싶지 않다고 말했습니다. 그들과 병합 세션을 시작하는 방법을 찾지 못한 것은 유감입니다.

궁극적으로 git clean -f -d -x무시 된 파일을 제거했습니다. 흥미롭게도 ~ 30 개 중 4 개의 파일이 정리 후에도 남아 있습니다 (하위 디렉터리에 묻혀 있음). 수동으로 삭제해야하는 카테고리가 무엇인지 알아 내야합니다.

그런 다음 내 팝이 성공했습니다.

이 시도:

git checkout stash-.

다른 솔루션 :

cd to/root/your/project

# Show what git will be remove
git clean -n

# If all is good
git clean -f

# If not all is good, see
git clean --help

# Finish
git stash pop

Git 2.14.x / 2.15 (2017 년 3 분기)에서는 2014 년부터 qwertzguy 의 솔루션이 더 이상 필요하지 않습니다.

2017 년 3 분기 이전에는 문제의 파일을 삭제 한 다음 다시 숨김 / 적용을 시도해야했습니다.
다음 Git 릴리스에서는 그렇게 할 필요가 없습니다.

Nicolas Morey-Chaisemartin ( )의 commit bbffd87 (2017 년 8 월 11 일)을 참조하십시오 . ^{(Merged by Junio ​​C Hamano -- in commit 0ca2f32 , 23 Aug 2017)}nmorey
gitster

stash: 재설정하기 전에 추적되지 않은 파일 정리

git stash -u파일의 현재 수정으로 인해 더 이상 무시되지 않는 파일이 포함 된 저장소를 호출 하는 gitignore경우이 파일은 숨겨 지지만 작업 트리에서 제거되지 않습니다.
이것은 git-stash먼저 파일 수정 reset --hard을 지우고 .gitignore를 호출 git clean하여 파일을 그대로두기 때문입니다.
이로 인해 git stash pop기존 .

이 패치는 단순히 청소와 재설정 사이의 순서를 전환하고이 사용 사례에 대한 테스트를 추가합니다.

은닉을 따르는 가장 안전한 방법

git stash -u

이것은 무단계 변경을 포함하여 모두 숨겨집니다.

자식 숨김 드롭

작업을 마친 후 "안전한"은닉을 제거합니다.