후 git reset --hard, git status나를 내 파일을 제공합니다 Changes not staged for commit:섹션.

나는 또한 시도했다 git reset ., git checkout -- .그리고 git checkout-index -f -a아무 소용.

그렇다면 단계적 변경을 어떻게 제거 할 수 있습니까?

이것은 Visual Studio 프로젝트 파일에만 적용되는 것 같습니다. 기묘한. 이 붙여 넣기를 참조하십시오 http://pastebin.com/eFZwPn9Z을 . 이 파일들에서 특별한 점은 .gitattributes에 내가 가지고있는 것입니다.

*.sln        eol=crlf
*.vcproj     eol=crlf
*.vcxproj*   eol=crlf

또한 autocrlf내 global에서 false로 설정되어 .gitconfig있습니다. 어떻게 든 관련이있을 수 있습니까?

나는 같은 문제가 있었고 .gitattributes파일 과 관련이 있었다 . 그러나 문제를 일으킨 파일 형식이에 지정되지 않았습니다 .gitattributes.

간단히 실행하여 문제를 해결할 수있었습니다.

git rm .gitattributes
git add -A
git reset --hard

해결 !!!

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

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

git rm --cached -r .

2) Git 인덱스를 다시 작성하여 모든 새로운 줄 끝을 가져옵니다.

git reset --hard

해결책은 자식 사이트 https://help.github.com/articles/dealing-with-line-endings/ 에 설명 된 단계의 일부였습니다.

힘내는 저장소에없는 파일을 재설정하지 않습니다. 따라서 다음을 수행 할 수 있습니다.

$ git add .
$ git reset --hard

이렇게하면 모든 변경 사항이 준비되어 Git에서 해당 파일을 인식 한 다음 다시 설정합니다.

그래도 문제가 해결되지 않으면 변경 사항을 숨기고 삭제하십시오.

$ git stash
$ git stash drop

Windows 용 Git을 사용하는 경우 이것이 문제 일 수 있습니다.

나는 똑같은 문제가 있었고 숨김, 하드 리셋, 청소 또는 심지어 모든 변경 사항이 여전히 남아 있습니다. 문제로 밝혀진 것은 git에 의해 올바르게 설정되지 않은 x 파일 모드였습니다. 이것은 Windows 용 git의 "알려진 문제"입니다. 로컬 변경 사항은 실제 파일 차이없이 gitk 및 git 상태에서 이전 모드 100755 새 모드 100644로 표시됩니다.

수정은 파일 모드를 무시하는 것입니다.

git config core.filemode false

더 많은 정보는 여기에

좋아, 나는 문제를 해결했다.

그것은 그 보였다 .gitattributes포함 파일 :

*.sln        eol=crlf
*.vcproj     eol=crlf
*.vcxproj*   eol=crlf

프로젝트 파일이 스테이지되지 않은 것처럼 보이게 만들었습니다. 나는 그것이 왜 그런지에 대한 단서가 없으며, git의 방법에 대해 누군가가 우리에게 좋은 설명을 해주길 정말로 바라고 있습니다.

내 수정이 파일을 제거하고, 추가했다 autocrlf = false아래 [core]에서 .git/config.

이것은 모든 개발자가 필요로하기 때문에 이전 구성과 정확히 같은 것은 아닙니다 autocrlf = false. 더 나은 수정을 찾고 싶습니다.

편집하다:

나는 유죄 판결을 내리고 주석을 풀고 효과가있었습니다. 뭐야 ... 나도 ...!

가능한 원인 # 1-라인 종료 정규화

이러한 상황이 발생할 수있는 상황 중 하나는 라인 엔딩에 대한 올바른 구성없이 해당 파일을 리포지토리에 체크인 한 경우 (1) 잘못된 라인 엔딩 또는 혼합 된 라인 엔딩으로 리포지토리에 파일을 생성 한 경우입니다. 확인하려면 git diff줄 끝의 변경 사항 만 표시 되는지 확인 git diff | cat -v하십시오 ( 기본적으로 표시되지 않을 수 있음 ^M). 캐리지 리턴을 리터럴 문자 로 보십시오 .

결과적으로 누군가가 줄 끝을 정규화하기 .gitattributes위해 core.autocrlf설정을 추가 하거나 수정했습니다 (2). .gitattributes또는 전역 구성을 기반으로 Git은 요청한 줄 끝 정규화를 적용하는 작업 복사본에 로컬 변경 사항을 적용했습니다. 불행히도, 어떤 이유로 git reset --hard이러한 라인 정규화 변경을 취소하지 않습니다.

해결책

로컬 줄 끝이 재설정되는 해결 방법으로는 문제가 해결되지 않습니다. 파일이 git에 의해 "보일"때마다, 정규화를 다시 시도하여 동일한 문제가 발생합니다.

최선의 선택은 자식이 일치하도록 REPO의 모든 라인 엔딩 정상화에 원하는 정상화를 적용 할 수 있도록하는 것입니다 .gitattributes참조 - 및 변경 사항을 커밋 자식 필터 - 분기 수정 라인 엔딩을 시도하지만, 운이없는 .

실제로 변경 사항을 수동으로 파일로 되돌리려 고하면 가장 쉬운 해결책은 수정 된 파일을 지우고 git에게 파일을 복원하도록 지시하는 것 같습니다.이 솔루션은 지속적으로 100 % 작동하지 않는 것으로 보입니다. 시간 ( 경고 : 수정 된 파일에 줄 끝 이외의 변경 사항이있는 경우 이것을 실행 하지 마십시오 !!)

    git status --porcelain | grep "^ M" | cut -c4- | xargs rm
    git checkout -- .

어떤 시점에서 저장소의 줄 끝을 정규화하지 않으면이 문제가 계속 발생합니다.

가능한 원인 # 2-대소 문자 구분

두 번째 가능한 원인은 Windows 또는 Mac OS / X에서 대소 문자를 구분하지 않기 때문입니다. 예를 들어, 저장소에 다음과 같은 경로가 있다고 가정하십시오.

/foo/bar

이제 Linux의 누군가가 /foo/Bar(아마도 빌드 도구 또는 해당 디렉토리를 만든 것으로 인해) 파일을 커밋 하고 푸시합니다. Linux에서 이것은 실제로 두 개의 별도 디렉토리입니다.

/foo/bar/fileA
/foo/Bar/fileA

변경 될 수 있습니다 Windows 또는 Mac에서 출력이 REPO 확인 fileA밖으로 윈도우 수표에 있기 때문에 각 리셋, 리셋 할 수없는, 자식 /foo/bar/fileA윈도우의 경우를 구분하고 있기 때문에, 내용 덮어 쓰기 fileA로를 /foo/Bar/fileA"수정"하고 그 결과.

다른 경우는 저장소에 존재하는 개별 파일 일 수 있으며, 대소 문자를 구분하지 않는 파일 시스템에서 체크 아웃하면 겹칩니다. 예를 들면 다음과 같습니다.

/foo/bar/fileA
/foo/bar/filea

이러한 문제를 일으킬 수있는 다른 유사한 상황이있을 수 있습니다.

대소 문자를 구분하지 않는 파일 시스템의 git 은 실제로이 상황을 감지하고 유용한 경고 메시지를 표시하지만 현재는 그렇지 않습니다 (향후 변경 될 수 있습니다 -git.git 메일 링리스트 에서이 토론 및 관련 제안 패치 참조 ).

해결책

해결책은 git 인덱스의 파일 케이스와 Windows 파일 시스템의 케이스를 정렬하는 것입니다. 이것은 실제 상황을 보여주는 Linux 또는 Windows에서 매우 유용한 오픈 소스 유틸리티 Git-Unite을 사용하여 수행 할 수 있습니다 . Git-Unite은 필요한 경우 변경 사항을 git 인덱스에 적용하여 리포지토리에 커밋 할 수 있습니다.

(1)이 어떤없이, Windows를 사용하는 사람이 대부분이었다 .gitattributes문제의 파일에 대한 정의 및 대한 기본 전역 설정을 사용하여 core.autocrlf인 false((2) 참조).

(2) http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/

다른 답변이 작동하지 않으면 파일을 추가하고 재설정을 시도하십시오.

$ git add -A
$ git reset --hard

내 경우에는 git이 추적하는 빈 파일이 많을 때 도움이되었습니다.

이에 대한 또 다른 원인은 대소 문자를 구분하지 않는 파일 시스템 일 수 있습니다. 같은 레벨에있는 레포에 여러 개의 폴더가 있다면 이름이 대소 문자 만 다릅니다. 웹 인터페이스 (예 : GitHub 또는 VSTS)를 사용하여 소스 저장소를 찾아보십시오.

자세한 정보 : https://stackoverflow.com/a/2016426/67824

stash변경 사항을 숨기고 숨겨 놓을 수 있습니다.

git stash
git stash drop

이 방법들 중 어느 것도 나를 위해 효과가 없었으며 유일한 해결책은 전체 저장소를 핵 복제하고 다시 복제하는 것이 었습니다. 여기에는 숨김, 재설정, 추가 및 재설정, clrf 설정, 대소 문자 구분 등이 포함됩니다.

clean 명령을 실행하십시오 .

# Remove all untracked files and directories. (`-f` is `force`, `-d` is `remove directories`)

git clean -fd

확인하십시오 .gitattributes.

내 경우에는 *.js text eol=lf그것에 있고 git 옵션 core.autocrlf은이었다 true.

git이 파일 줄 끝을 자동 변환하고 수정하지 못하게하고 git reset --hard HEAD아무것도하지 않은 상황에 처하게합니다 .

나는 *.js text eol=lf내 의견을 주석 으로 고치고 그 .gitattributes후에 주석 처리를 제거했습니다.

마법처럼 보이는 것 같습니다.

비슷한 문제가 발생 .gitattributes했지만 GitHub의 LFS와 관련이 있습니다. 이것이 OP의 시나리오는 아니지만 .gitattributes파일이 수행하는 작업과 파일이 "팬텀"차이의 형태로 비 단계적 변경을 야기 할 수있는 이유를 설명 할 수 있는 기회를 제공한다고 생각합니다 .

제 경우에는 파일이 이미 시작된 이후와 같이 이미 저장소에있었습니다. 최근의 커밋에서, 나는 git-lfs track너무 넓게 보이는 패턴을 사용하여 새로운 규칙을 추가 하고이 고대 파일과 일치하게되었습니다. 이 파일을 변경하고 싶지 않다는 것을 알고 있습니다. 파일을 변경하지 않았다는 것을 알았지 만 이제는 파일이 스테이지되지 않은 변경 사항에 있었으며 해당 파일의 체크 아웃이나 하드 리셋이 수정되지 않았습니다. 왜?

GitHub LFS 확장은 주로 파일 git을 통한 액세스를 제공 하는 후크를 활용하여 작동 .gitattributes합니다. 일반적으로 항목의 항목은 .gitattributes일치하는 파일을 처리하는 방법 을 지정합니다. OP의 경우에는 라인 엔딩 정규화와 관련이있었습니다. LFS가 파일 저장소를 처리하도록할지 여부는 내 것입니다. 두 경우 모두 gita를 계산할 때 표시 되는 실제 파일이 git diff파일을 검사 할 때 표시되는 파일과 일치하지 않습니다. 따라서 파일 .gitattributes과 일치 하는 패턴을 통해 파일이 처리되는 방식을 변경하면 실제로 파일이 변경되지 않은 경우에도 상태 보고서에서 비 단계적 변경으로 표시됩니다.

모든 질문에 대한 나의 대답은 .gitattributes파일 의 변경 이 당신이하고 싶은 일이라면 실제로 변경 사항을 추가하고 계속 진행해야한다는 것입니다. 그렇지 않다면, .gitattributes하고 싶은 것을 더 잘 표현 하기 위해 를 수정하십시오 .

참고 문헌

1. GitHub LFS 사양 - 객체 의 파일을 간단한 텍스트 파일로 해시 로 대체하기 위해 cleanand smudge함수 호출에 연결하는 방법에 대한 훌륭한 설명 git.

2. gitattributes Documentation-문서git 처리 방법을 사용자 정의하는 데 사용할 수있는 모든 세부 사항입니다 .

나는 같은 문제가 있었다. 나는 git reset --hard HEAD하지만 여전히 내가 할 때마다 git status일부 파일이 수정 된 것을보고있었습니다.

내 솔루션은 비교적 간단했습니다. 방금 IDE (여기서는 Xcode)를 닫고 명령 줄 (여기서는 Mac OS의 터미널 임)을 닫고 다시 시도해 보았습니다.

그러나 나는 문제의 원인을 찾지 못했습니다.

git이 Windows에서 무작위로 잘못된 줄 끝을 체크 아웃 할 때 문제가 있다고 생각하며 유일한 해결 방법은 다른 분기를 체크 아웃하고 git이 변경 사항을 무시하도록하는 것입니다. 그런 다음 실제로 작업하려는 지점을 확인하십시오.

git checkout master -f
git checkout <your branch>

이렇게하면 의도적으로 변경 한 내용이 삭제되므로 체크 아웃 직후에이 문제가 발생하는 경우에만 수행하십시오.

편집 : 나는 실제로 처음 운이 좋을 수도 있습니다. 지점을 전환 한 후 다시 조금 알게되었습니다. 브랜치 변경이 변경된 후 git 파일이 수정 된 것으로보고 된 것으로 나타났습니다. (git이 CRLF 줄 끝을 파일에 올바르게 적용하지 않았기 때문일 것입니다.)

Windows 용 최신 git으로 업데이트했으며 문제가 사라지기를 바랍니다.

비슷한 문제이지만 표면에만 확신합니다. 어쨌든, 그것은 누군가를 도울 수 있습니다 : 내가 한 일 (FWIW, SourceTree) : 커밋되지 않은 파일을 보관하고 하드 리셋을 수행했습니다.

다른 답변에서 지적했듯이 문제는 라인 엔드 자동 수정 때문입니다. * .svg 파일에서이 문제가 발생했습니다. 내 프로젝트에서 아이콘에 svg 파일을 사용했습니다.

이 문제를 해결하려면 git에 gitgittributes에 아래 줄을 추가하여 svg 파일을 텍스트 대신 이진 파일로 처리해야 함을 알립니다.

* .svg 바이너리

비슷한 상황에서. 한 줄에 여러 줄의 끝 (. asp , .js, .css ...이 아닌)을 다른 인코딩으로 채울 수있는 많은 프로그래머들과 함께 수년간 고통을 겪었습니다. 얼마 전에 .gitattributes를 거부했습니다. 리포지터리 설정 autorclf = true및 safecrlf = warn.

아카이브에서 서로 다른 라인 끝을 동기화 할 때 마지막 문제가 발생했습니다. 아카이브에서 복사 한 후 git 상태에서 많은 파일이 메모와 함께 변경됩니다

The line will have its original line endings in your working directory. warning: LF will be replaced by CRLF in ...

Git에서 작업 트리 라인 엔딩을 정규화하는 방법의 팁 ? 도움

git add -u

내가 겪은 또 다른 가능성은 저장소의 패키지 중 하나가 분리 된 HEAD로 끝날 수 있다는 것입니다. 여기에 대한 답변이 도움이되지 않고 이와 같은 자식 상태 메시지가 표시되면 동일한 문제가있을 수 있습니다.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   path/to/package (new commits)

로 가는데 path/to/package폴더 A를 git status다음과 같은 결과를 산출한다 :

HEAD detached at 7515f05

그런 다음 다음 명령으로 문제를 해결 master해야합니다. 여기서 로컬 지점으로 대체해야합니다.

git checkout master

그리고 당신은 당신의 로컬 브랜치가 원격 브랜치 뒤에 어떤 양의 커밋이 될 것이라는 메시지를 보게 될 것입니다. git pull그리고 당신은 숲에서 나와야합니다!

몇 가지 이유

git add .

작동하지 않았지만

$ git add -A

운동했다!