작업 디렉토리에 숨김을 다시 적용 할 수 없습니다.
작은 이야기 :
먼저 커밋 된 변경 사항을 푸시하려고했지만 “아니요, 먼저 풀 수 없습니다.”라는 메시지가 표시되었습니다. 그런 다음 GitHub에서 항목을 가져온 다음 변경 사항을 푸시합니다. 가져 오려고 할 때 덮어 쓸 변경 사항이 있으며 변경 사항을 숨겨야한다고 표시했습니다. 좋아요, 변경 사항을 숨겼습니다 … 당겨서 커밋 된 변경 사항을 푸시했습니다. 하지만 지금은 작업 중이던 커밋되지 않은 변경 사항을 복원 할 수 없습니다.
이것은 오류입니다.
MyPath/File.cs already exists, no checkout
Could not restore untracked files from stash
확실히 나는 아직 git의 모든 개념을 이해하지 못합니다. 그들은 저를 약간 혼란스럽게합니다 … 어쩌면 제가 뭔가 잘못했을 수도 있습니다.
누군가가이 문제를 해결하도록 도울 수 있다면 좋을 것입니다. 저는 지금 한 시간 이상 Google과 모든 것을 검색했지만 아직 해결책을 찾지 못했습니다.
도움을 주시면 감사하겠습니다. 감사!
답변
숨김에 나중에 저장소에 추가 된 추적되지 않은 파일이 포함 된 것 같습니다. 당신이 그것을 시도하고 체크 아웃 할 때, git은 기존 파일을 덮어 쓰기 때문에 당연히 거부합니다.
문제를 해결하려면 해당 파일을 삭제하고 (괜찮습니다. 여전히 저장소에 있음) 숨김을 적용한 다음 파일의 숨김 버전을 저장소 내 버전으로 적절하게 바꾸는 것과 같은 작업을 수행 할 수 있습니다.
편집 : 파일이 저장소에 추가 되지 않고 작업 트리에서만 생성되었을 수도 있습니다 . 이 경우 단순히 로컬 파일을 삭제하지 말고 다음을 수행하십시오.
- 다른 곳으로 옮기세요
- 은닉을 적용
- 두 파일 버전을 수동으로 병합합니다 (작업 트리 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 개의 파일이 정리 후에도 남아 있습니다 (하위 디렉터리에 묻혀 있음). 수동으로 삭제해야하는 카테고리가 무엇인지 알아 내야합니다.
그런 다음 내 팝이 성공했습니다.