git status는 수정 사항을 표시하고 git checkout — <file>은 수정 사항을 제거하지 않습니다.

Question

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

Answer 1

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

라인 엔딩 정규화

나도 이런 종류의 문제가있었습니다. CRLF를 LF로 자동 변환하는 GIT로 내려갑니다. 이것은 일반적으로 단일 파일의 혼합 라인 엔딩으로 인해 발생합니다. 파일은 인덱스에서 정규화되지만 git이 다시 실행되면 작업 트리의 파일에 대해 다시 변형되면 결과가 다릅니다.

하지만 이것을 고치려면 비활성화해야합니다. core.autocrlf, 모든 라인 엔드를 LF로 변경 한 다음 다시 활성화하십시오. 또는 다음을 통해 완전히 비활성화 할 수 있습니다.

git config --global core.autocrlf false

대신에 core.autocrlf, 당신은 또한 사용을 고려할 수 있습니다 .gitattribute 파일. 이렇게하면 Repo를 사용하는 모든 사람이 동일한 정규화 규칙을 사용하여 혼합 라인 엔딩이 저장소에 들어가는 것을 방지 할 수 있습니다.

또한 설정을 고려하십시오 Core.safecrlf 반사적 인 정규화가 수행 될 때 GIT가 경고하기를 원한다면 경고합니다.

git 인공 이걸 말해보세요:

CRLF 변환은 데이터를 손상시킬 수있는 약간의 기회를 갖습니다. autocrlf = true는 Commit 동안 CRLF를 LF로, LF는 체크 아웃 중에 CRLF로 변환합니다. 커밋 전에 LF와 CRLF의 혼합물이 포함 된 파일은 GIT에 의해 재현 할 수 없습니다. 텍스트 파일의 경우 이것이 옳은 일입니다. 저장소에 LF 라인 엔딩 만 있도록 라인 엔딩을 수정합니다. 그러나 우연히 텍스트로 분류 된 이진 파일의 경우 변환이 데이터를 손상시킬 수 있습니다.

사례에 민감한 파일 시스템

사례에 민감한 파일 시스템에서 다른 케이싱이있는 동일한 파일 이름이 저장소에있을 때 GIT는 둘 다 점검하려고하지만 파일 시스템에서만 끝납니다. GIT가 두 번째를 비교하려고 할 때 잘못된 파일과 비교할 것입니다.

이 솔루션은 비 사례 둔감 파일 시스템으로 전환하고 있지만 대부분의 경우 다른 파일 시스템의 파일 중 하나를 실현 가능하거나 이름을 바꾸고 커밋하지 않습니다.

Answer 2

나는이 문제가 창에 문제가 있었지만 사용의 영향을 조사 할 준비가되어 있지 않았습니다. config --global core.autocrlf false 나는 또한 내 은신처에 다른 개인 지점과 음식을 버리고 신선한 클론으로 시작할 준비가되어 있지 않았습니다. 나는 단지 무언가를 끝내야합니다. 지금.

이것은 당신이 당신의 작업 디렉토리를 완전히 다시 작성하게한다는 아이디어에 대해 나에게 효과적이었습니다.

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

(그냥 실행하십시오 git reset --hard 충분하지도 않았고 평원도 아니 었습니다 rm 이전 파일에 reset 원래 질문에 대한 의견에서 제안 된 바와 같이)

Answer 3

텍스트 옵션 중 어느 것도 나에게 도움이되지 않았기 때문에 사람들에게 효과가있을 수있는 또 다른 솔루션은 다음과 같습니다.

1. 의 내용을 바꾸십시오 .gitattributes 한 줄로 : * binary. 이것은 Git에게 모든 파일을 할 수없는 이진 파일로 취급하도록 지시합니다.
2. 문제가 발생한 파일이 사라 졌는지 확인하십시오. 당신이 할 수 없다면 git checkout -- <files> 저장소 버전으로 복원합니다
3. git checkout -- .gitattributes 복원하기 위해 .gitattributes 초기 상태로 파일
4. 파일이 여전히 변경되지 않은지 확인하십시오.

Answer 4

이 문제가있는 미래의 사람들의 경우 : FileMode 변경 사항도 동일한 증상을 가질 수 있습니다. git config core.filemode false 그것을 고칠 것입니다.

Answer 5

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

문제의 출처 : GIT의 초기 설치는 Windows에서 자동 라인 변환이 없었습니다. 이로 인해 GLFW에 대한 최초의 커밋은 적절한 라인 결말이 없었습니다.

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

설정 : GLFW 프로젝트를 통한 Xubuntu 12.04 git repo

문제 : GLFW 파일을 재설정 할 수 없습니다. 그들은 내가 시도한 것에 상관없이 항상 수정 된 것으로 보입니다.

해결 :

edit .gitattributes

Comment out the line:    # text=auto

Save the file

restore .gitattributes:   git checkout .gitattributes

Answer 6

같은 문제가있는 .BAT 파일이있었습니다 (추적되지 않은 파일에서 제거 할 수 없었습니다). GIT 결제 - 작동하지 않았 으며이 페이지의 제안도하지 않았습니다. 나를 위해 일한 유일한 일은 다음과 같습니다.

git stash save --keep-index

그런 다음 은신처를 삭제합니다.

git stash drop

Answer 7

같은 문제가 두 번 받았습니다! 두 번의 변화를 숨길 때, 내가 만든 후 다시 튀어 나오려고했습니다. 변경된 파일이 많기 때문에 변경 사항을 터뜨릴 수는 없지만 그렇지 않습니다! 그들은 정확히 동일합니다.

나는 이제 위의 모든 솔루션을 성공하지 않고 시도했다고 생각합니다. 시도한 후

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

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

파일을 디프트 할 때 모든 줄을 삭제 한 다음 다시 추가했습니다.

일종의 방해. 나는 이제 미래에 숨겨진 것을 피할 것입니다 ..

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

Answer 8

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

나는 달렸다 git status 삭제 후 수정이 사라졌습니다. 그들은 .gitattributes가 다시 제자리에 놓인 후에도 돌아 오지 않았습니다.

Answer 9

시도해보십시오

git 체크 아웃 -f

현재 작업중인 지역 리포의 모든 변경 사항을 해결해야합니다.

Answer 10

일관된 라인 엔딩을 갖는 것이 좋습니다. 예를 들어 사소한 경우에도 불필요한 병합을 유발하지 않습니다. Visual Studio가 혼합 된 라인 엔딩이있는 파일을 만드는 것을 보았습니다.

또한 Bash (Linux의)와 같은 일부 프로그램은 .SH 파일이 종료되도록 요구합니다.

이런 일이 발생하기 위해 Gitattributes를 사용할 수 있습니다. AutcRLF의 값이 무엇이든 저장소 레벨에서 작동합니다.

예를 들어 다음과 같은 .gitattributes를 가질 수 있습니다.

귀하의 경우에 중요한 경우 파일 유형/확장자 당보다 구체적 일 수 있습니다.

그런 다음 autocrlf는 로컬에서 Windows 프로그램의 라인 엔딩을 변환 할 수 있습니다.

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

Answer 11

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

나는 할 수 없었다:

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 그리고 수행하다 git status 다시 말하지만 여전히 '추적되지 않음' 상태의 파일이 표시됩니다.

동료와 몇 번 시도한 끝에 우리는 그것이 Grunt에 의해 발생했다는 것을 알게 되었습니다!

다음과 같이 Grunt 이 켜져 있고 app.js가 몇 가지 다른 js 파일에서 생성되었기 때문에 js 파일(또한 이 app.js)을 사용한 각 작업 후에 grunt가 app.js를 다시 생성한다는 것을 알았습니다.

Answer 12

이 문제는 REPO의 기고자가 Linux 시스템에서 작동하거나 Cygwin이있는 Windows 및 파일 권한이 변경 될 때 발생할 수 있습니다. 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

Answer 13

여기에는 많은 솔루션이 있으며 내 자신을 생각해 내기 전에 이것들 중 일부를 시도했을 것입니다. 어쨌든 여기에 하나 더 ...

우리의 문제는 엔드 라인에 대한 집행이없고 저장소에는 DOS / UNIX가 혼합되어 있다는 것이 었습니다. 더 나쁜 것은 여전히이 위치에서 실제로 오픈 소스 리포였으며 우리가 포크 한 것이라는 것이었다. OS 저장소의 주요 소유권이있는 사람들이 모든 엔드 라인을 UNIX로 변경하기로 결정했으며 .gitattributes 라인 엔딩을 시행합니다.

불행히도 이것은 DOS-2- 유닉스가 완료되기 전에 코드가 병합 된 경우 여기에 설명 된 것과 매우 유사한 문제를 일으키는 것처럼 보였습니다.

이것에 대한 나의 연구 중에 나는 발견했다. https://help.github.com/articles/dealing-with-line-endings/ -이 문제에 다시 직면하면 먼저 시도해 볼 때 시작하겠습니다.

---

여기에 내가 한 일은 다음과 같습니다.

1. 나는 처음에 내가이 문제가 있다는 것을 깨닫기 전에 합병을했고 그것을 중단시켜야했다. git reset --hard HEAD (나는 합병 갈등을 일으켰다. 합병을 어떻게 중단 할 수 있습니까?)

2. vim에서 해당 파일을 열고 유닉스로 변경했습니다 (:set ff=unix). 같은 도구 dos2unix 물론 대신 사용할 수 있습니다

3. 헌신적인

4. 합병 master 에서 (마스터는 DOS-2- 유닉스 변경 사항이 있습니다)

   git checkout old-code-branch; git merge master

5. 해결 된 충돌과 파일은 다시 DOS였습니다. :set ff=unix vim에있을 때. (참고 설치했습니다 https://github.com/itchyny/lightline.vim VIM 상태 라인에 파일 형식이 무엇인지 볼 수있었습니다)

6. 헌신적인. 모든 분류!

Answer 14

나는 모든 변경 사항을 헌신 한 다음 커밋을 수행하고 취소했습니다. 이것은 나를 위해 효과가있었습니다

git 추가.

Git Commit -M "Random Commit"

git 리셋 -하드 헤드 ~ 1

Answer 15

저장소를 복제하고 즉시 계류중인 변경 사항을 보면 저장소는 일관되지 않은 상태입니다. 언급하지 마십시오 * 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의 소유자에게 병합 (또는 요청)하십시오.

Answer 16

제가 실행 한 문제는 Windows가 파일 이름 대문자에 관심이 없지만 GIT는 그렇습니다. 따라서 Git은 파일의 하단 및 대문자 버전을 저장했지만 파일 만 확인할 수 있습니다.

Answer 17

이 페이지의 다른 것은 작동하지 않았습니다. 이것은 마침내 나를 위해 효과가있었습니다. 추적되지 않은 파일을 표시하지 않거나 파일이 표시되지 않습니다.

git add -A
git reset --hard

Answer 18

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

git checkout <file>

Visual Studio를 닫은 후 명령은 작동했으며 마침내 스택에서 작업을 적용 할 수있었습니다. 따라서 Sourcetree, SmartGit, Notepad, Notepad ++ 및 기타 편집자와 같은 코드를 변경할 수있는 모든 응용 프로그램을 확인하십시오.

Answer 19

우리는 회사에서 비슷한 상황에 직면했습니다. 제안 된 방법 중 어느 것도 우리를 도와주지 않았습니다. 연구의 결과로 문제가 드러났다. 문제는 git에는 두 개의 파일이 있었는데, 그 이름은 기호 레지스터에서만 다르다는 것입니다. Unix-Systems는 그것들을 두 개의 다른 파일로 보았지만 Windows는 미쳤습니다. 문제를 해결하기 위해 서버의 파일 중 하나를 삭제했습니다. 그 후, Windows의 로컬 리포지토리에서 다음 몇 가지 명령 (다른 순서)을 도왔습니다.

git reset --hard
git pull origin
git merge

Answer 20

나는이 문제를 몇 번 전에 도망 쳤다. 현재 고용주가 제공 한 Windows 10 머신에서 개발 중입니다. 오늘날,이 특별한 git 행동은 "개발"지점에서 새로운 지점을 만들어 야했기 때문에 발생했습니다. 어떤 이유로, "개발"지점으로 다시 전환 한 후, 일부 임의의 파일은 "Git 상태"에서 "수정 된"것으로 나타났습니다.

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

이것이 내가 한 일입니다.

$ git log

나는 오늘 일찍 "개발"에서 만든 새로운 지점이 첫 번째 "커밋"메시지에서 보여 주었고, 끝에 참조되고있다 "헤드 -> 개발, 원산지/개발, 원산지/헤드, 브랜치 -I-I-earlier-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

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

Answer 21

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

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

그런 다음 .git / refs / heads / name_branch로 가서 마지막 커밋의 ID를 배치합니다.enter code here

Answer 22

나는 이것을 이런 식으로 해결했다 :

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

---

그것이 저를 위해 일한 것입니다.