힘내 : "변경되었지만 커밋되지 않은"상태에서 완고하게 멈춘 파일 2 개를 되 돌리는 방법은 무엇입니까?

로컬로 변경 한 것으로 추정되는 두 개의 파일이있는 저장소가 있습니다.

그래서 나는 이것에 붙어 있습니다.

$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   dir1/foo.aspx
#       modified:   dir2/foo.aspx
#
no changes added to commit (use "git add" and/or "git commit -a")

Doing git diff은 사실이 아닌 것처럼 보이지만 전체 파일 내용이 변경되었다고 말합니다.

흥미롭게도이 파일을 로컬로 변경 한 기억이 없습니다. 이 저장소는 하나의 원격 저장소 (개인, GitHub.com, FWIW)와 함께 사용됩니다.

내가 무엇을 시도하든 이러한 로컬 변경 사항을 삭제할 수 없습니다. 나는 모두를 시도했다 :

$ git checkout -- .
$ git checkout -f
$ git checkout -- dir1/checkout_receipt.aspx
$ git reset --hard HEAD
$ git stash save --keep-index && git stash drop
$ git checkout-index -a -f

즉 , Git에서 단계 화되지 않은 변경 사항을 어떻게 폐기합니까?에 설명 된 모든 것을 시도했습니다 .게다가. 그러나 2 개의 파일은 "변경되었지만 커밋되지 않은"상태로 남아 있습니다.

도대체 두 개의 파일이 이렇게 멈춰 있고 겉보기에는 "테이블을 되돌릴 수 없음"으로 보이는 이유는 무엇입니까 ??

PS는 이미 시도 것 명령을 보여주는 위의 목록에서, 내가 잘못 쓴 git revert내가 의미하는 경우 git checkout. 미안하고 노력해야한다고 대답 해주신 분들께 감사드립니다 checkout. 나는 그것을 수정하기 위해 질문을 편집했습니다. 나는 이미 시도했다 checkout.

파일의 줄 끝은 무엇입니까? 나는 그들이 CRLF라고 확신합니다. 그렇다면이 가이드를 확인하세요. http://help.github.com/line-endings/

간단히 말해, 커밋시 줄 끝을 LF로 변환하도록 git이 설정되어 있는지 확인한 다음 해당 파일을 커밋해야합니다. 저장소의 파일은 항상 LF 여야하며 체크 아웃 된 파일은 git을 올바르게 설정했다고 가정하고 OS의 기본 파일이어야합니다.

비슷한 문제를 해결하기 위해 몇 시간을 보냈습니다. 체크 아웃 한 원격 지점에서 모든 파일을 삭제하고 git checkout -f다시 실행할 때에도 4 개의 파일이 '변경되었지만 업데이트되지 않음'으로 완고하게 표시되었습니다 (또는이 게시물의 다른 변형)!

이 4 개의 파일은 필요했지만 내가 수정 한 것은 아닙니다. 내 마지막 해결책은 Git이 변경되지 않았다고 설득하는 것입니다. 다음은 모든 체크 아웃 된 파일에 대해 작동하며 '수정 됨'상태를 표시합니다. 실제로 수정 된 파일을 이미 커밋 / 숨겨 놓았는지 확인하십시오! :

git ls-files -m | xargs -i git update-index --assume-unchanged "{}"

그러나 Mac OSX에서는 xargs가 약간 다르게 작동합니다 (주석의 경우 Daniel).

git ls-files -m | xargs -I {} git update-index --assume-unchanged {}

나는 이것을 다음 시간을 위해 자리 표시 자로 추가했지만 다른 사람에게도 도움이되기를 바랍니다.

-알

이것은 내 경우에 동일한 문제를 해결하는 방법입니다. open .gitattributes change :

* text=auto

에:

#* text=auto

힌트를 위해 @Simon East에게 감사드립니다.

또 다른 가능성은 차이점 (체크 아웃 명령으로 이러한 파일을 되 돌리지 못하게하는)이 파일 모드 중 하나라는 것입니다. 이것은 나에게 일어난 일입니다. 내 버전의 git에서는 다음을 사용하여 찾을 수 있습니다.

git diff dir1 / foo.aspx

그리고 파일 모드 변경을 보여줍니다. 그래도 되돌릴 수는 없습니다. 그 사용을 위해

git config core.filemode false

또는 추가하여 텍스트 편집기에서 git .config를 변경하십시오.

[핵심]

filemode = false

이렇게하면 다음을 사용할 수 있습니다.

git reset HEAD dir1 / foo.aspx

파일이 사라져야합니다.

(이 모든 것은 어떻게 git ignore mode changes (chmod)? )에 대한 답변에서 얻었습니다.

하려고 노력하다 로컬 변경 사항 되 돌리십시오 .

git checkout -- dir1/foo.aspx
git checkout -- dir2/foo.aspx

수정 된 것으로 표시되는 일부 팬텀 변경 파일이 있었지만 실제로는 동일했습니다.

이 명령을 실행하면 때때로 작동합니다.
(git의 "스마트"하지만 종종 도움이되지 않는 줄 끝 변환을 끕니다)

git config --local core.autocrlf false

그러나 다른 경우 .gitattributes에는 일부 줄 끝 설정이있는 루트 의 파일 로 인해 autocrlf꺼져 있어도 특정 파일 에 적용하려고 했습니다. 실제로 도움이되지 않았기 때문에을 삭제 .gitattributes하고 커밋했으며 파일이 더 이상 수정 된 것으로 표시되지 않았습니다.

git checkout dir1/foo.aspx
git checkout dir2/foo.aspx

또한 문자 대소 문자를 명명하는 디렉토리와 관련된 문제가있을 수 있습니다. 동료 중 일부는 디렉토리 이름을 예를 들어 myHandler 에서 MyHandler로 변경했을 수 있습니다 . 나중에 원래 디렉토리의 일부 파일을 푸시하고 가져 오면 원격 저장소에 2 개의 개별 디렉토리 가 있고 Windows에서는 하나만 가질 수 있으므로 로컬 시스템 에는 하나만있을 것입니다. 그리고 당신은 곤경에 처했습니다.

이 경우인지 확인하려면 원격 저장소가 이중 구조인지 확인하십시오.

이 문제를 해결하려면 리포지토리 외부에있는 상위 디렉터리의 백업 복사본을 만든 다음 상위 디렉터리를 삭제하고 푸시합니다. 당겨서 (삭제 된 것으로 표시된 두 번째 항목이 상태에 표시되어야하는 경우) 다시 밀어 넣습니다. 그런 다음 백업에서 전체 구조를 다시 만들고 변경 사항을 다시 푸시하십시오.

문제 를 더 잘 이해하기 위해 문제 를 재현하는 방법에 대한 힌트를 제공하는 것이 도움이 될 것이라고 생각합니다 .

$ git init
$ echo "*.txt -text" > .gitattributes
$ echo -e "hello\r\nworld" > 1.txt
$ git add 1.txt 
$ git commit -m "committed as binary"
$ echo "*.txt text" > .gitattributes
$ echo "change.." >> 1.txt

# Ok let's revert now

$ git checkout -- 1.txt
$ git status
 modified:   1.txt

# Oooops, it didn't revert!!


# hm let's diff:

$ git diff
 warning: CRLF will be replaced by LF in 1.txt.
 The file will have its original line endings in your working 
 directory.
 diff --git a/1.txt b/1.txt
 index c78c505..94954ab 100644
 --- a/1.txt
 +++ b/1.txt
 @@ -1,2 +1,2 @@
 -hello
 +hello
  world

# No actual changes. Ahh, let's change the line endings...

$ file 1.txt 
 1.txt: ASCII text, with CRLF line terminators
$ dos2unix 1.txt
 dos2unix: converting file 1.txt to Unix format ...
$ git diff
 git diff 1.txt
 diff --git a/1.txt b/1.txt
 index c78c505..94954ab 100644
 --- a/1.txt
 +++ b/1.txt
 @@ -1,2 +1,2 @@
 -hello
 +hello
  world

# No, it didn't work, file is still considered modified.

# Let's try to revert for once more:
$ git checkout -- 1.txt
$ git status
 modified:   1.txt

# Nothing. Let's use a magic command that prints wrongly committed files.

$ git grep -I --files-with-matches --perl-regexp '\r' HEAD

HEAD:1.txt

두번째 방법은 재현 : : 위의 스크립트에서이 줄을 교체
echo "*.txt -text" > .gitattributes
로
git config core.autocrlf=false
와 같이 라인의 나머지 부분을 계속

위의 모든 내용은 무엇입니까? 텍스트 파일이 있습니다 (일부 상황에서) (예를 들어, CRLF로 커밋 -text에서 .gitattributes/ 또는 core.autocrlf=false).

나중에 동일한 파일을 텍스트 ( -text-> text) 로 처리하려면 다시 커밋해야합니다.
물론 일시적으로 되돌릴 수 있습니다 ( Abu Assar 가 올바르게 답변 한대로 ). 우리의 경우 :

echo "*.txt -text" > .gitattributes
git checkout -- 1.txt
echo "*.txt text" > .gitattributes

대답은 다음과 같습니다. 파일을 변경할 때마다 동일한 문제가 발생하기 때문에 정말 그렇게 하시겠습니까?

기록을 위해 :

저장소에서이 문제를 일으킬 수있는 파일을 확인하려면 다음 명령을 실행하십시오 (git은 --with-libpcre로 컴파일해야 함).

git grep -I --files-with-matches --perl-regexp '\r' HEAD

파일을 커밋함으로써 (텍스트로 처리하고 싶다고 가정하면) 이러한 문제를 해결하기 위해 http://help.github.com/line-endings/ 링크에서 제안 된 작업을 수행하는 것과 동일 합니다. . 그러나을 제거 .git/index하고 수행하는 대신 reset파일을 변경 한 다음 수행 git checkout -- xyz zyf한 다음 커밋 할 수 있습니다.

나는 파일이 윈도우에서 변경되었지만 WSL에서 볼 때가 아니라 흥미로운 추가와 함께 동일한 문제가 발생했습니다. 라인 엔딩, 리셋 등을 어지럽히 지 않고 변경할 수 없었습니다.

결국 이 답변 에서 해결책을 찾았습니다 . 다음은 편의를위한 텍스트입니다.

다음 단계를 사용하여이 문제를 해결했습니다.

1) Git의 색인에서 모든 파일을 제거하십시오.

git rm --cached -r .

2) Git 인덱스를 다시 작성하여 모든 새 줄 끝을 선택하십시오.

git reset --hard

솔루션은 git 사이트 https://help.github.com/articles/dealing-with-line-endings/ 에 설명 된 단계의 일부였습니다.

나에게 문제는 라인 엔딩에 관한 것이 아닙니다. 폴더 명 (Reset_password-> Reset_Password)에서 대소 문자를 변경하는 내용이었습니다. 이 솔루션이 도움이되었습니다 : https://stackoverflow.com/a/34919019/1328513

이 문제는 git이 대소 문자 차이를 다른 파일로 취급하지만 Windows는이를 동일한 파일로 취급하기 때문에 발생할 수 있습니다. 파일 이름에 대문자 만 변경된 경우 해당 저장소의 모든 Windows 사용자는이 상황에 처하게됩니다.

해결책은 파일 내용이 올바른지 확인한 다음 다시 커밋하는 것입니다. 두 파일의 내용이 다르기 때문에 병합해야했습니다. 그런 다음 당기면 중복 파일을 삭제하여 해결할 수있는 병합 충돌이 발생합니다. 병합 해결을 다시 커밋하면 안정적인 상태로 돌아갑니다.