git 상태는 수정 사항을 표시하고 git 체크아웃 - 제거하지 않습니다.

git 상태는 수정 사항을 표시하고 git 체크아웃 - 제거하지 않습니다.

작업 복사본의 변경 사항을 모두 제거하고 싶습니다.
중입니다.git status수정된 파일을 보여줍니다.
제가 하는 어떤 것도 이러한 수정 사항들을 제거하는 것 같지 않습니다.
항목:

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ 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:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout -- Rhino.Etl.Core/Enumerables/CachingEnumerable.cs

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ 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:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout `git ls-files -m`

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ 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:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git reset --hard HEAD
HEAD is now at 6c857e7 boo libraries updated to 2.0.9.2 and rhino.dsl.dll updated.

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ 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:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

이되어 .config --global core.autocrlf false저는 또한 제 창고에 있는 다른 개인 지점과 맛있는 것들을 버리고 새로운 복제품으로 시작할 준비가 되어 있지 않았습니다.저는 단지 뭔가를 해야만 합니다.지금이다.

이것은 당신이 git에게 당신의 작업 디렉토리를 완전히 다시 쓰게 했다는 생각에서 저에게 효과가 있었습니다.

git rm --cached -r .
git reset --hard

하세요.git reset --hard 것도 .rm.reset원래 질문에 대한 의견에 제시된 바와 같이)

이 동작을 유발할 수 있는 여러 가지 문제가 있습니다.

라인 끝 정규화

저도 이런 문제가 있었습니다.git는 crlf를 자동으로 tf로 변환합니다.이 문제는 일반적으로 단일 파일에서 줄 끝이 혼합되어 발생합니다.파일이 인덱스에서 정규화되지만 Git가 다시 정규화되지 않고 작업 트리의 파일과 차이가 나면 결과가 달라집니다.

그러나 이 문제를 해결하려면 코어를 비활성화해야 합니다.autocolf, 모든 줄 끝을 tolf로 변경한 다음 다시 활성화합니다.또는 다음을 수행하여 이 기능을 모두 사용하지 않도록 설정할 수 있습니다.

git config --global core.autocrlf false

코어 대신.autocolf, 파일 사용도 고려할 수 있습니다.이렇게 하면 리포지토리를 사용하는 모든 사람이 동일한 정규화 규칙을 사용하여 혼합 줄 끝이 리포지토리에 들어가지 않도록 할 수 있습니다.

또한 되돌릴 수 없는 정규화가 수행될 때 경고하도록 git을 설정하려면 core.safecrlf를 설정하는 것이 좋습니다.

Git manpages는 다음과 같이 말합니다.

CRLF 변환은 데이터가 손상될 가능성이 약간 있습니다.autocolf=true는 커밋 중에는 CRLF를 LF로, 체크아웃 중에는 LF를 CRLF로 변환합니다.커밋하기 전에 LF와 CRLF가 혼합된 파일을 git로 재생성할 수 없습니다.텍스트 파일의 경우 이것이 올바른 작업입니다. 즉, 저장소에 LF 줄 끝만 있도록 줄 끝을 수정합니다.그러나 실수로 텍스트로 분류된 이진 파일의 경우 변환으로 인해 데이터가 손상될 수 있습니다.

대소문자를 구분하지 않는 파일 시스템

대소문자를 구분하지 않는 파일 시스템에서 케이스가 다른 동일한 파일 이름이 저장소에 있는 경우 Git는 둘 다 체크아웃하려고 하지만 하나만 파일 시스템에 남게 됩니다.Git가 두 번째 파일을 비교하려고 할 때 잘못된 파일과 비교합니다.

솔루션은 대/소문자를 구분하지 않는 파일 시스템으로 전환하는 것이지만, 대부분의 경우 이를 실행할 수 없거나 다른 파일 시스템에서 파일 이름을 변경하고 커밋합니다.

텍스트 옵션 중 어떤 것도 나에게 효과가 없었기 때문에 사람들에게 효과가 있을 수 있는 또 다른 해결책:

1. 의 합니다..gitattributes로: 한 줄 로 시 표 줄한표:* binary이것은 git에게 모든 파일을 아무것도 할 수 없는 이진 파일로 취급하라고 말합니다.
2. 가 되는 "" " " " " " " 를 확인할 수 . 그렇지 않으면 할 수 있습니다.git checkout -- <files>
3. git checkout -- .gitattributes복기위해원을 .gitattributes로 유지합니다.
4. 파일이 여전히 변경된 것으로 표시되지 않는지 확인합니다.

파일 모드 변경: 증상이 수 .파일 모드를 변경해도 동일한 증상이 나타날 수 있습니다. git config core.filemode false고칠 겁니다

이것은 저를 미치게 만들었습니다. 특히 온라인에서 찾을 수 있는 해결책이 없이는 이 문제를 해결할 수 없었습니다.이것이 제가 해결한 방법입니다.이것은 동료의 일이기 때문에 여기서 학점을 받을 수 없습니다 :)

문제의 원인:제가 처음에 설치한 git은 윈도우에서 자동으로 변환되지 않았습니다.이로 인해 GLFW에 대한 저의 초기 커밋은 적절한 라인 종료 없이 끝났습니다.

참고: 이는 로컬 솔루션일 뿐입니다.레포를 복제하는 다음 사람은 여전히 이 문제에 시달릴 것입니다.영구 솔루션은 다음에서 찾을 수 있습니다. https://help.github.com/articles/dealing-with-line-endings/ # 저장소를 다시 정규화합니다.

설정: Xubuntu 12.04 Gitrepo with glfw project

문제:glfw 파일을 재설정할 수 없습니다.그들은 제가 시도한 것과 상관없이 항상 수정된 것으로 나타납니다.

해결됨:

edit .gitattributes

Comment out the line:    # text=auto

Save the file

restore .gitattributes:   git checkout .gitattributes

동일한 문제가 있는 .bat 파일이 있었습니다(추적되지 않은 파일에서 제거할 수 없었습니다).git checkout -- 효과가 없었고, 이 페이지의 어떤 제안도 효과가 없었습니다.제게 유일하게 효과가 있었던 것은:

git stash save --keep-index

그런 다음 저장소를 삭제하려면 다음을 수행합니다.

git stash drop

같은 문제가 두 번이나 발생했습니다!두 번 모두 변경 사항을 저장했다가 다시 팝업하려고 했습니다.변경된 파일이 많기 때문에 변경사항을 팝업할 수 없습니다. 하지만 변경사항이 없습니다!그들은 정확히 같습니다.

저는 이제 위의 모든 솔루션을 시도했지만 성공하지 못했다고 생각합니다.사용해 본 후

git rm --cached -r .
git reset --hard

이제 저장소에 있는 거의 모든 파일을 수정했습니다.

파일을 디파짓할 때, 내가 모든 라인을 삭제한 후 다시 추가한 것으로 표시됩니다.

좀 방해가 되는군요.나는 이제 앞으로 숨는 것을 피할 것입니다.

유일한 해결책은 새 저장소를 복제하고 다시 시작하는 것입니다. (지난번에 작성)

한 번 해보세요

git checkout -f

그러면 현재 작동 중인 로컬 레포의 모든 변경 사항이 삭제됩니다.

일반적으로 모든 수정 사항과 새 파일을 지우는 GIT에서는 다음 두 가지 명령이 매우 잘 작동해야 합니다(조심하십시오. 이렇게 하면 새로 생성한 파일과 폴더가 모두 삭제되고 수정된 파일이 현재 커밋 상태로 복원됩니다).

$ git clean --force -d
$ git checkout -- .

어쩌면 더 나은 선택은 때때로 다음과 같은 선택적 메시지와 함께 "git stash push"를 수행하는 것입니다.

$ git stash push -m "not sure if i will need this later"

이렇게 하면 새 파일과 수정된 파일도 모두 지워지지만 복원하려는 경우를 대비하여 모든 파일이 저장됩니다.GIT의 Stash는 지점 간에 전달되므로 원하는 경우 다른 지점에서 복원할 수 있습니다.

참고로, 새로 추가된 파일을 이미 준비한 후 제거하려는 경우에는 다음과 같은 작업을 수행해야 합니다.

$ git reset --hard

위의 모든 것이 당신에게 효과가 없다면, 얼마 전에 저에게 효과가 있었던 것을 아래에서 읽어보십시오.

저는 전에 이 문제에 몇 번 부딪힌 적이 있습니다.저는 현재 고용주가 제공하는 윈도우 10 기계로 개발 중입니다.오늘 이 특별한 기트 동작은 제가 "개발" 지점에서 새 지점을 만들었기 때문에 발생했습니다.어떤 이유에서인지 "develop" 지점으로 다시 전환한 후 일부 무작위 파일이 지속되어 "git status"에 "수정"으로 표시되었습니다.

또한 그 시점에서 다른 지점을 확인할 수 없었기 때문에 "개발" 지점에 갇혀 있었습니다.

제가 한 일은 이렇습니다.

$ git log

오늘 초에 "develop"에서 만든 새 분기가 첫 번째 "commit" 메시지에 "HEAD -> developy, origin/developy, origin/HEAD, The-branch-i-created-lear-today" 끝에 참조되어 있음을 알게 되었습니다.

별로 필요하지 않아서 삭제했습니다.

$ git branch -d The-branch-i-created-earlier-today

변경된 파일이 계속 표시되므로 다음 작업을 수행했습니다.

$ git stash

이것으로 문제가 해결되었습니다.

$ git status
On branch develop
Your branch is up to date with 'origin/develop'.

nothing to commit, working tree clean

이죠.$ git stash list숨겨진 변화를 보여줄 것이고, 나는 나의 스타킹이 거의 없었고 필요하지 않았기 때문에, 나는 그것을 했습니다.$ git stash clear모든 스택을 삭제합니다.

참고: 이전에 누군가가 제안한 작업을 수행해 본 적이 없습니다.

$ git rm --cached -r .
$ git reset --hard

이것도 효과가 있었을 수도 있어요, 다음에 이런 문제가 생기면 꼭 시도해 보겠습니다.

는 내 속성 된 .git 속성 파일)을 하여 이 할 수 .* text=auto그리고.*.c text).

도망친git status삭제 후 수정 사항이 사라졌습니다...git 특성이 다시 제자리에 배치된 후에도 그들은 돌아오지 않았습니다.

저는 줄 끝이 다른 오래된 중복 브랜치를 가지고 있었습니다.이것으로 바꾸자 힘을 가하기 전까지 저는 약간 꼼짝할 수 없었습니다.

git checkout mainbranch --force

그 뒤에 빠른 것이 있습니다.git branch -D brokenbranch.

일관된 줄 끝이 있는 것은 좋은 일입니다.예를 들어, 사소한 경우에도 불필요한 병합을 트리거하지 않습니다.Visual Studio에서 줄 끝이 혼합된 파일을 만드는 것을 보았습니다.

또한 bash(리눅스의 경우)와 같은 일부 프로그램에서는 .sh 파일을 LF 종료해야 합니다.

이렇게 하려면 git 특성을 사용할 수 있습니다.autcrlf 값에 관계없이 저장소 수준에서 작동합니다.

예를 들어 다음과 같은 .git 특성을 가질 수 있습니다. * text=auto

또한 파일 형식/확장자별로 파일 형식/확장자별로 더 구체적으로 지정할 수 있습니다.

그런 다음 autocolf는 Windows 프로그램의 줄 끝을 로컬로 변환할 수 있습니다.

혼합된 C#/C++/Java/Ruby/R, Windows/Linux 프로젝트에서 이는 잘 작동합니다.아직까지는 문제가 없습니다.

저도 같은 증상이 있었는데 다른 증상으로 인해 발생했습니다.

다음을 수행할 수 없었습니다.

git checkout app.js //did nothing
git rm app.js //did nothing
rm -rf app.js //did nothing

에 있어서도git rm --cached app.js삭제된 것으로 표시되고 추적되지 않은 파일에서 app.js를 볼 수 있었습니다.하지만 내가 노력했을 때rm -rf app.js 수행 수행및행formgit status여전히 '추적되지 않음' 파일이 표시됩니다.

동료와 몇 번 시도한 후에 우리는 그것이 그룬트에 의해 야기되었다는 것을 알게 되었습니다!

Grunt가 켜져 있고, app.js가 다른 몇 개의 js 파일에서 생성되었기 때문에, js 파일(또한 이 app.js)을 사용한 각 작업 후 app.js를 다시 생성하는 것을 확인했습니다.

이 문제는 repo에 대한 기여자가 Linux 시스템에서 작업하거나 Cygwin 및 파일 사용 권한이 있는 창이 변경된 경우에도 발생할 수 있습니다.Git은 755와 644만 알고 있습니다.

이 문제의 예 및 확인 방법:

git diff styleguide/filename

diff --git a/filename b/filename
old mode 100644
new mode 100755

이 문제를 방지하려면 다음을 사용하여 git을 올바르게 설정해야 합니다.

git config --global core.filemode false

여기에는 많은 해결책이 있습니다. 저는 제 자신의 해결책을 생각해내기 전에 이것들 중 몇 가지를 시도했어야 했습니다.어쨌든 여기 하나 더 있습니다...

문제는 엔드라인에 대한 적용이 없고 저장소에 DOS/Unix가 혼합되어 있다는 것입니다.더 나쁜 것은 그것이 실제로 이 위치에 있는 오픈 소스 레포였고, 우리가 분기했다는 것입니다.이 모든 했으며, 이 은 운영 체제를 되었습니다..gitattributes줄 끝을 적용합니다.

불행히도 이것은 DOS-2-UNIX가 완료되기 전의 코드 병합이 완료되면 파일이 영원히 변경된 것으로 표시되어 되돌릴 수 없는 여기서 설명된 것과 같은 문제를 일으키는 것처럼 보였습니다.

이 문제를 연구하는 동안 우연히 https://help.github.com/articles/dealing-with-line-endings/ 을 발견했습니다. 만약 제가 이 문제에 다시 직면한다면, 저는 먼저 이것을 시도하는 것부터 시작할 것입니다.

---

제가 한 일은 다음과 같습니다.

1. 처음에 합병을 했는데 문제가 있다는 걸 깨달았어요 그리고 중단해야 했습니다.git reset --hard HEAD(합병 충돌이 발생했습니다. 병합을 중단하려면 어떻게 해야 합니까?)

2. (VIM 로문파열일고을니다습변경였하서제의에로▁unix▁()로 변경하였습니다.:set ff=unix) )과 같은 dos2unix'' 에 'course'를 .

3. 헌신적인

4. 를 했습니다.master 변경 사항이 (DOS-2-유닉스 변경 사항 있음)

   git checkout old-code-branch; git merge master

5. 에 어쩔 수 "DOS"가 되었습니다.:set ff=unixVIM에 있을 때.(참고: https://github.com/itchyny/lightline.vim 을 설치하여 VIM 상태 줄에서 파일 형식을 확인할 수 있습니다.)

6. 헌신적인.모두 정렬됨!

제가 마주친 문제는 윈도우가 파일 이름 대문자화에 관심이 없지만 Git는 관심이 있다는 것입니다.Sogit는 파일의 낮은 버전과 대문자 버전을 저장했지만 하나만 체크아웃할 수 있었습니다.

모든 변경 사항을 커밋한 다음 커밋을 실행했다가 실행 취소했습니다.이것은 나에게 효과가 있었습니다.

git add

git commit -m "임의 커밋"

git reset --hard HEAD~1

리포지토리를 복제하고 보류 중인 변경 사항을 즉시 확인하면 리포지토리가 일관되지 않은 상태가 됩니다.코멘트 아웃하지 마십시오.* text=auto.gitattributes파일. 저장소의 소유자가 모든 파일을 LF 줄 끝과 일관되게 저장하기를 원하기 때문에 이 파일을 저장했습니다.

HankCa에 따르면 https://help.github.com/articles/dealing-with-line-endings/ 의 지침을 따르는 것이 문제를 해결하는 방법입니다.쉬운 단추:

git clone git@host:repo-name
git checkout -b normalize-line-endings
git add .
git commit -m "Normalize line endings"
git push
git push -u origin normalize-line-endings

그런 다음 분기를 repo의 소유자에게 병합(또는 요청 꺼내기)합니다.

이 페이지의 다른 것은 작동하지 않았습니다.이것은 마침내 저에게 효과가 있었습니다.추적되지 않거나 커밋된 파일을 표시하지 않습니다.

git add -A
git reset --hard

저에게 문제는 명령을 수행할 때 Visual Studio가 열린다는 것이었습니다.

git checkout <file>

Visual Studio를 닫은 후 명령이 작동하여 스택에서 작업을 적용할 수 있었습니다.따라서 소스 트리, SmartGit, NotePad, NotePad++ 및 기타 편집기와 같이 코드를 변경할 수 있는 모든 응용 프로그램을 확인합니다.

우리 회사도 비슷한 상황에 직면했습니다.제안된 방법 중 어떤 것도 우리에게 도움이 되지 않았습니다.연구 결과, 문제점이 드러났습니다.중요한 것은 Git에는 두 개의 파일이 있었는데, 그 파일의 이름은 단지 기호 레지스터에서만 다르다는 것입니다. 유닉스 시스템은 그것들을 두 개의 다른 파일로 보았지만, 윈도우는 미쳐가고 있었습니다.문제를 해결하기 위해 서버에 있는 파일 중 하나를 삭제했습니다.그 후 Windows의 로컬 저장소에서 다음 몇 가지 명령을 지원했습니다(다른 순서로).

git reset --hard
git pull origin
git merge

.git / config를 편집하고 다음을 추가하여 해결했습니다.

[branch "name_branch"]
    remote = origin
    merge = refs/heads/name_branch

.git // heads / 합니다.enter code here

저는 이렇게 해결했습니다.

1. 원하는 코드의 내용을 복사합니다.
2. 문제의 원인이 되는 파일(복귀할 수 없는 파일)을 디스크에서 삭제합니다.이제 삭제된 것으로 표시된 동일한 파일의 두 버전을 모두 찾아야 합니다.
3. 파일 삭제를 커밋합니다.
4. 동일한 이름으로 파일을 다시 만들고 1단계에서 복사한 올바른 코드로 붙여넣습니다.
5. 새 파일의 생성을 커밋합니다.

---

그것이 저에게 효과가 있었습니다.

여기서 제안된 솔루션 중 하나가 작동하지 않았습니다. 파일이 실제로 일부 특수 문자에 대한 링크라는 것을 알게 되었습니다.

% ls -l StoreLogo.png
lrwxrwxrwx 1 janus janus 8 Feb 21 10:37 StoreLogo.png -> ''$'\211''PNG'$'\r\n\032\n'

% git status    
Changes not staged for commit:
    modified:   StoreLogo.png

% git rm --cached -r StoreLogo.png
rm 'src/GWallet.Frontend.XF.UWP/Assets/StoreLogo.png'

% git reset StoreLogo.png         
Unstaged changes after reset:
M   src/GWallet.Frontend.XF.UWP/Assets/StoreLogo.png

% git status                      
Changes not staged for commit:
    modified:   StoreLogo.png

언급URL : https://stackoverflow.com/questions/2016404/git-status-shows-modifications-git-checkout-file-doesnt-remove-them