작업 디렉토리에 숨김을 적용 할 수없는 이유는 무엇입니까?

작업 디렉토리에 숨김을 적용 할 수없는 이유는 무엇입니까?

---

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

작은 이야기 :

먼저 커밋 된 변경 사항을 푸시하려고했지만 "아니요. 안됩니다. 먼저 가져 오기"라는 메시지가 표시되었습니다. 그런 다음 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

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

---

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

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

숨김을 브랜치로 변환

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

git stash branch STASHBRANCH

"stash 분기"작업

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

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

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

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

If you just stashed while keeping some staged changes, then committed, and all you want to do is get the additional changes that where not staged when you stashed you can do the following. It will switch back to your original branch and index without changing your working copy. The end result will be your additional stash changes in your working copy.

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

Background

Stashes are commits likes branches/tags (not patches)

PS, It is tempting to think of a stash as a patch (just like it is tempting to think of a commit as a patch), but a stash is actually a commit against the HEAD when it was created. When you apply/pop you are doing something similar to cherry-picking it into your current branch. Keep in mind that branches and tags are really just references to commits, so in many ways stashes, branches, and tags are just different ways of pointing at a commit (and its history).

Sometimes needed even when you haven't made working directory changes

PPS, You may need this technique after just using stash with --patch and/or --include-untracked. Even without changing working directories those options can sometimes create a stash you can't just apply back. I must admit don’t fully understand why. See http://git.661346.n2.nabble.com/stash-refuses-to-pop-td7453780.html for some discussion.

---

The solution: You need to delete the file in question, then try to stash pop/apply again and it should go through. Don't delete other files, just the ones mentioned by the error.

The problem: Git sucks sometimes. When running git stash -u it includes untracked files (cool !) but it does not remove those untracked files and does not know how to apply the stashed untracked files on top of the leftovers (not cool !), which really makes the -u option pretty useless.

---

To apply the code differences in the stash as a patch instead, use the following command:

git stash show --patch | patch -p1

---

This has happened to me numerous times, I stash untracked files with git stash -u which end up being added to the repo and I can't apply the stashed changes anymore.

I couldn't find a way to force git stash pop/apply to replace the files, so I first remove the local copies of the untracked files that were stashed (be careful as it will delete any changes that haven't been committed) and then apply the stashed changes:

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

Finally, I use git status, git diff and other tools to check and add back portions from the removed files if there's something missing.

---

If you have uncommitted changes that you want to keep, you can create a temporary commit first:

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

Use whatever tools suits you to merge the previously committed changes back into the local files, and remove the dummy commit:

git reset HEAD~1

---

My similarly blocked pop operation was because leftover ignored files (see the .gitignore file). Git status showed me tracked and untracked, but my activities didn't clean up the ignored files.

Details: I had used git stash save -a, checked out the master to compile and see original behavior, then tried to put it all back to continue editing. When I checked out my branch and tried to pop, my ignored files were still there from before the stash save. That is because the checkout of master only affected committed files -- it didn't wipe the ignored files. So the pop failed, essentially saying it didn't want to restore my stashed ignored files on top of files that were still there. It is unfortunate that I couldn't figure out a way to start a merge session with them.

Ultimately, I used git clean -f -d -x to remove the ignored files. Interestingly, of my ~30, 4 files still remained after cleaning (buried in subdirectories). I'll have to figure out what category they are in, that they had to be manually deleted.

Then my pop succeeded.

---

Try this:

git checkout stash -- .

---

Other solution:

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

---

With Git 2.14.x/2.15 (Q3 2017), qwertzguy's solution from 2014 won't be necessary anymore.

Before Q3 2017, you had to delete the file in question, then try to stash pop/apply again.
With the next Git release, you won't have to do that.

See commit bbffd87 (11 Aug 2017) by Nicolas Morey-Chaisemartin (nmorey).
^{(Merged by Junio C Hamano -- gitster -- in commit 0ca2f32, 23 Aug 2017)}

stash: clean untracked files before reset

If calling git stash -u on a repo that contains a file that is not ignored any more due to a current modification of the gitignore file, this file is stashed but not remove from the working tree.
This is due to git-stash first doing a reset --hard which clears the .gitignore file modification and then call git clean, leaving the file untouched.
This causes git stash pop to fail due to the file existing.

This patch simply switches the order between cleaning and resetting and adds a test for this usecase.

---

The safest way to following stashing

git stash -u

This will stash all including unstaged change

git stash drop

after you are done working on it ,to remove your "safe" stash.

참고URL : https://stackoverflow.com/questions/10508903/why-cant-stash-be-applied-to-the-working-directory