자식 상태는 수정 사항을 보여줍니다, 자식 체크 아웃 — <파일>은 제거하지 않습니다

작업 사본의 모든 변경 사항을 제거하고 싶습니다.
Running 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")

이 동작을 일으킬 수있는 여러 가지 문제가 있습니다.

줄 끝 정규화

나도 이런 종류의 문제가 있었다. git은 crlf를 lf로 자동 변환합니다. 이것은 일반적으로 단일 파일에서 줄 끝이 혼합되어 발생합니다. 파일은 인덱스에서 정규화되지만 git은 다시 비정규 화하여 작업 트리의 파일과 비교하기 위해 다시 정규화하면 결과가 다릅니다.

그러나이 문제를 해결 하려면 core.autocrlf 를 비활성화하고 모든 줄 끝을 lf로 변경 한 다음 다시 활성화해야합니다. 또는 다음을 수행하여 완전히 비활성화 할 수 있습니다.

git config --global core.autocrlf false

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

되돌릴 수없는 정규화가 수행 될 때 git이 경고하도록하려면 core.safecrlf 를 경고하도록 설정 하십시오 .

자식 맨 페이지 는 다음과 같이 말합니다.

CRLF 변환은 데이터를 약간 손상시킬 수 있습니다. autocrlf = true는 커밋 중에 CRLF를 LF로 변환하고 체크 아웃 중에 LF를 CRLF로 변환합니다. 커밋 전에 LF와 CRLF가 혼합 된 파일은 git에서 다시 만들 수 없습니다. 텍스트 파일의 경우 이것이 올바른 일입니다. 저장소에 LF 줄 끝만 있도록 줄 끝을 수정합니다. 그러나 실수로 텍스트로 분류 된 이진 파일의 경우 변환시 데이터가 손상 될 수 있습니다.

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

대소 문자를 구분하지 않는 파일 시스템에서 다른 케이싱을 가진 동일한 파일 이름이 저장소에 있으면 git은 둘 다 체크 아웃하려고하지만 파일 시스템에서는 하나만 종료됩니다. git이 두 번째 것을 비교하려고하면 잘못된 파일과 비교합니다.

해결책은 대소 문자를 구분하지 않는 파일 시스템으로 전환하는 것이지만 대부분의 경우 다른 파일 시스템의 파일 중 하나를 바꾸거나 이름을 바꾸고 커밋 할 수 없습니다.

나는 Windows 에서이 문제를 겪고 있었지만 사용의 결과를 조사 할 config --global core.autocrlf false준비가되어 있지 않았으며 또한 내 개인의 다른 개인 지점과 케이크를 버리고 신선한 클론으로 시작할 준비가되지 않았습니다. 난 그냥 뭔가를해야합니다. 지금.

이것은 git이 작업 디렉토리를 완전히 다시 작성하게한다는 아이디어로 저에게 효과적이었습니다.

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

( 원래 질문에 대한 의견에서 제안 된 것처럼 실행 git reset --hard이 충분하지 않았거나 rm파일에 대한 평범하지 않았습니다. reset)

텍스트 옵션 중 어느 것도 나를 위해 작동하지 않았기 때문에 사람들에게 도움이되는 또 다른 솔루션 :

1. 의 내용을 .gitattributes한 줄로 바꾸십시오 : * binary. 이것은 git에게 모든 파일을 아무것도 할 수없는 이진 파일로 취급하도록 지시합니다.
2. 문제가있는 파일에 대한 메시지가 사라 졌는지 확인하십시오. 그렇지 않은 경우 git checkout -- <files>리포지토리 버전으로 복원 할 수 없습니다
3. git checkout -- .gitattributes.gitattributes파일을 초기 상태 로 복원
4. 파일이 여전히 변경된 것으로 표시되지 않았는지 확인하십시오.

미래에이 문제가있는 사람들을 위해 : 파일 모드 변경이 동일한 증상을 가질 수도 있습니다. git config core.filemode false그것을 고칠 것입니다.

이것은 나를 미치게 만들었습니다. 특히 온라인에서 찾은 솔루션 없이이 문제를 해결할 수 없었습니다. 내가 해결 한 방법은 다음과 같습니다. 이것은 동료의 작품이므로 여기에서 크레딧을 얻을 수 없습니다 :)

문제의 근원 : git의 초기 설치는 Windows에서 자동 라인 변환이 없었습니다. 이로 인해 GLFW에 대한 초기 커밋이 올바른 줄 끝없이 이루어졌습니다.

참고 : 이것은 로컬 솔루션 일뿐입니다. 레포를 복제하는 다음 사람은 여전히이 문제로 고착 될 것입니다. 영구적 인 해결책은 https://help.github.com/articles/dealing-with-line-endings/#re-normalizing-a-repository 에서 찾을 수 있습니다 .

설정 : Xubuntu 12.04 glfw 프로젝트와 Git 저장소

문제 : 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

이제 저장소의 거의 모든 파일이 수정되었습니다.

파일을 비교할 때 모든 줄을 삭제 한 다음 다시 추가한다고 말합니다.

방해의 종류. 나는 이제 앞으로 숨겨지지 않을 것입니다 ..

유일한 해결책은 새로운 저장소를 복제하고 다시 시작하는 것입니다. (마지막 시간)

시도해보십시오

자식 체크 아웃 -f

현재 작업중인 로컬 리포지토리의 모든 변경 내용이 지워 져야합니다.

내 repo의 .gitattributes 파일 ( * text=auto및 정의 됨 *.c text) 을 임시로 삭제 하여이 문제를 해결할 수있었습니다 .

git status삭제 후 실행 되었으며 수정 사항이 사라졌습니다. .gitattributes가 다시 설치 된 후에도 반환되지 않았습니다.

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

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

이런 일이 발생하도록 gitattributes를 사용할 수 있습니다. autcrlf의 값이 무엇이든 상관없이 저장소 레벨에서 작동합니다.

예를 들어 다음과 같이 .gitattributes를 가질 수 있습니다. * text = auto

경우에 따라 파일 유형 / 확장자별로 더 구체적 일 수도 있습니다.

그러면 autocrlf는 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하고 peform git status해도 여전히 파일을 '비 추적'으로 표시합니다.

우리는 동료와 몇 번의 시도 끝에 Grunt가 원인이라는 것을 알게되었습니다!

은 다음과 같이 Grunt설정하고 있으며, app.js 때문에 다른 JS 파일의 몇에서 생성 된 우리의 js 파일 (이 app.js)와 각 작업 후 꿀꿀 재 작성 다시 app.js 것을 알아 냈다.

이 문제는 Linux 시스템에서 저장소에 대한 기고자가 작동하거나 Cygwin 및 파일 권한이있는 창이 변경된 경우에도 발생할 수 있습니다. 힘내는 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가 혼합되어 있다는 것입니다. 더 나쁜 것은 여전히 ​​그것이 실제로이 입장에서 오픈 소스 레포지토리였으며 우리가 분기 한 것입니다. OS 리포지토리의 기본 소유권을 가진 사람들이 모든 최종 기한을 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물론 같은 도구를 사용할 수 있습니다

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. 커밋. 모든 분류!

내가 만난 문제는 Windows가 파일 이름 대문자를 신경 쓰지 않지만 git은 신경 쓰지 않는다는 것입니다. 따라서 git은 파일의 소문자 및 대문자 버전을 저장했지만 하나만 체크 아웃 할 수있었습니다.

모든 변경 사항을 커밋 한 다음 커밋을 실행 취소했습니다. 이것은 나를 위해 일했다

git add.

git commit -m "랜덤 커밋"

git reset --hard HEAD ~ 1

일반적으로, GIT에서 다음 두 명령 (일 아주 잘 작동합니다 모든 수정 및 새 파일을 지우려면 조심을 ,이 + 당신이 생성 한 폴더를 모든 새 파일을 삭제합니다 & 당신의 상태로 모든 수정 된 파일을 복원합니다 현재 커밋 ) :

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

아마도 더 나은 옵션은 때로는 다음과 같은 선택적 메시지로 "git stash push"를 수행하는 것입니다.

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

이렇게하면 새 파일과 수정 된 파일이 모두 지워지지 만 복원하려는 경우 파일이 모두 보관됩니다. GIT의 숨김은 지점마다 전달되므로 원하는 경우 다른 지점에서 복원 할 수 있습니다.

참고로, 새로 추가 된 파일을 이미 준비하고 제거하려는 경우이 트릭을 수행해야합니다.

$ git reset --hard

위의 모든 내용이 효과가 없다면 얼마 전에 저에게 도움이되었던 내용을 아래에서 읽으십시오.

몇 번 전에이 문제가 발생했습니다. 현재 고용주가 제공하는 Windows 10 컴퓨터에서 개발 중입니다. 오늘이 특정 git 동작은 "개발"분기에서 새 분기를 작성했기 때문에 발생했습니다. 어떤 이유로, "develop"브랜치로 다시 전환 한 후, 임의의 임의의 파일이 지속되어 "git status"에서 "modified"로 표시되었습니다.

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

이것이 내가 한 일입니다.

$ git log

오늘 초 "develop"에서 생성 한 새 브랜치가 "HEAD-> develop, origin / develop, origin / HEAD, The-branch-i-created "끝에서 참조되는 첫 번째 "커밋"메시지에 표시 되었습니다. -이전의 ".

실제로 필요하지 않았으므로 삭제했습니다.

$ 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

이것은 또한 효과가 있었을 수도 있습니다. 다음에이 문제가 발생할 때 시도해 볼 것입니다.

리포지토리를 복제하고 보류중인 변경 내용이 즉시 표시되면 리포지토리가 일관성이없는 상태입니다. 파일 * 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

그런 다음 지점을 리포지토리 소유자에게 병합 (또는 풀 요청)합니다.

이 페이지의 다른 기능은 없습니다. 이것은 마침내 나를 위해 일했습니다. 추적되지 않거나 커밋 된 파일을 표시하지 않습니다.

git add -A
git reset --hard

나에게 문제는 명령을 수행 할 때 Visual Studio가 열렸다는 것입니다.

git checkout <file>

Visual Studio를 닫은 후 명령이 작동하여 마침내 스택에서 내 작업을 적용 할 수있었습니다. 따라서 코드를 변경할 수있는 모든 응용 프로그램 (예 : SourceTree, SmartGit, NotePad, NotePad ++ 및 기타 편집기)을 확인하십시오.

우리 회사에서도 비슷한 상황에 직면했습니다. 제안 된 방법 중 어느 것도 우리에게 도움이되지 않았습니다. 연구 결과 문제가 드러났다. 문제는 Git에는 두 개의 파일이 있었고 그 이름은 심볼 레지스터에서만 다릅니다. 유닉스 시스템은 그것들을 두 개의 다른 파일로 보았지만 Windows는 열광했습니다. 이 문제를 해결하기 위해 서버에서 파일 중 하나를 삭제했습니다. 그 후 Windows의 로컬 리포지토리에서 다음 몇 가지 명령을 다른 순서로 도왔습니다.

git reset --hard
git pull origin
git merge

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

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

그런 다음 .git / refs / heads / name_branch로 이동하여 마지막 커밋의 ID를 배치합니다.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